アクセシビリティテストとは何ですか? （例）

アクセシビリティテストとは何ですか?

アクセシビリティテスト これは、視覚、聴覚、運動機能、認知機能、加齢に伴う障害を持つユーザーを含む、障害のある人々がアプリケーションを使用できることを確認するために実行されるソフトウェアテストの一種です。これは、 ユーザビリティテスト そして、その製品がこれらのユーザーが日々頼りにしている支援技術と連携して動作することを確認します。

支援技術は、障害のある人がソフトウェア製品を操作するのに役立ちます。一般的な例としては、以下のようなものがあります。

• 音声認識ソフトウェア ― 話された言葉を、コンピュータへの入力となるテキストに変換する。
• スクリーンリーダーソフトウェア 画面に表示されているテキストとインターフェース要素を読み上げます。
• 画面拡大ソフトウェア ・モニターの一部を拡大表示することで、視覚障害のあるユーザーが読みやすくします。
• 専用キーボード – 運動制御に困難を抱えるユーザー向けに設計されており、ping 容易になります。
• スイッチと目tracキングデバイス ・重度の運動障害を持つユーザーが、インターフェース要素を操作および選択できるようにする。

アクセシビリティテストを行う理由

理由1障害のあるユーザー層をターゲットにする。

世界保健機関によると、世界中で約1.3億人、つまりおよそ6人に1人が重度の障害を抱えて生活している。

• 10人に1人が重度の障害を抱えている。
• 65歳以上の人の2人に1人は、能力が低下している。

障害には、視覚障害、聴覚障害、運動機能障害、認知障害、その他の長期的な健康問題などが含まれます。アクセシビリティを考慮して設計された製品は、こうした大きな市場にリーチすることができ、アクセシビリティテストを通常のソフトウェアテストライフサイクルに組み込むことで、ほとんどのアクセシビリティ上の欠陥を未然に防ぐことができます。

理由2アクセシビリティ関連法規を遵守する。

世界各国の政府は、IT製品が障害のある人々にとって利用しやすいものであることを義務付ける法律を制定している。主な例としては以下の通りである。

• アメリカ合衆国：アメリカ障害者法（ADA、1990年）およびリハビリテーション法第508条。
• 英国：2010年平等法（1995年障害者差別禁止法に代わるもの）。
• 欧州連合：2025年6月に多くの製品やサービスに適用開始された欧州アクセシビリティ法、および規格EN 301 549。
• オーストラリア：障害者差別禁止法1992年。
• アイルランド：障害者法2005年。
• カナダ：2019年カナダアクセシビリティ法

アクセシビリティテストは、製品が販売されるすべての市場において、法令遵守を確保するために不可欠です。

理由3訴訟リスクを回避する。

大手企業は、デジタル製品のアクセシビリティが不十分であるとして、繰り返し訴訟を起こされてきた。代表的な事例としては以下のようなものがある。

• 全米盲人連盟（NFB）対 Target （2006年設立、2008年解決）
• NFB対AOL訴訟の和解（1999年）。
• Robles v. Domino's Pizza (2019) では、米国が Suprem裁判所は、ADA（アメリカ障害者法）がウェブサイトやモバイルアプリにも適用されるという判決を維持した。
• Gil v. Winn-Dixie (2017) は、アクセスできないウェブサイトを修正するよう命じた米国初の裁判判決である。

米国におけるウェブアクセシビリティ訴訟は年々増加しており、2022年以降、毎年4,000件以上のADA（米国障害者法）第3条に基づくデジタル訴訟が提起されている。最初からアクセシビリティに配慮した製品を開発することで、こうした訴訟コストを回避し、ブランドイメージを守ることができる。

どの障害をサポートすべきか?

申請書は、以下のような障害を持つ人々を支援するものでなければなりません。

障害の種類	身体障害 Descriptexpression CMS
視覚障害	完全失明、色覚異常、または弱視。 視覚的なストロボ効果や点滅効果に対する感受性。
身体障害	片手でマウスやキーボードを使用できない。 手の動きが制限されたり、筋肉の動きが鈍かったりするなど、運動能力が低下している。
認知障害	学習障害、記憶力の低下、または複雑な状況を理解するのが困難である。
読み書き能力の障害	読字障害（ディスレクシアなど）
聴覚障害	聴覚に関する問題（難聴や聴覚障害を含む）。 音が聞こえない、または音がはっきりと聞こえない。

アクセシビリティ基準とガイドライン

アクセシビリティテストプログラムは、広く採用されている少数の標準規格に基づいています。テスト計画を作成する前に、まず自社の市場に適用される標準規格を理解することが第一歩となります。

• WCAG 2.2 2023年10月にW3Cによって公開されたWebコンテンツアクセシビリティガイドライン2.2は、現在の世界的なベンチマークです。このガイドラインでは、A（基本）、AA（ほとんどの国における法的最低基準）、AAA（最高）の3つの適合レベルが定義されています。
• WCAG 3.0 – 成果ベースの採点モデルを導入するW3Cワーキングドラフト。現在も開発中で、WCAG 2.2に取って代わるものではありません。
• セクション508 – 米国の連邦政府調達規則で、連邦政府機関が購入する電子情報技術はWCAG 2.0レベルAAの基準を満たす必要があると規定している。
• 301 549 – 欧州のICTアクセシビリティに関する統一規格。欧州アクセシビリティ法への準拠を示すために使用される。
• ADAタイトルIII – 米国の公民権法は、公共施設のウェブサイトやモバイルアプリにも適用されます。裁判所は一般的に、WCAG 2.1または2.2 AAを基準として使用します。

ほとんどのチームは WCAG 2.2 レベル AA それは、共通の法的基準であると同時に、実用的な工学的目標でもあるため、彼らの作業目標として採用されている。

アクセシビリティテストを行うにはどうすればよいですか?

アクセシビリティテストは、次の2つの方法で実施できます。

1. マニュアル
2. 自動化

アクセシビリティテストは、障害についてよく知らないテスターに​​とっては難しい場合があります。障害のあるユーザーや、実際の課題を説明できるアクセシビリティ専門家をテストに関与させるのが最善の方法です。以下の手法は、主要な障害の種類を網羅しています。

1) 視覚障害

視覚が全くない状態でXYZウェブサイトを利用する必要があると想像してみてください。唯一現実的な選択肢はスクリーンリーダーです。スクリーンリーダーとは、ウェブページのテキスト、リンク、ラジオボタン、画像、動画などのコンテンツを読み上げるソフトウェアで、視覚障害のあるユーザーがインターフェースを認識できるようにします。代表的なスクリーンリーダーには以下のようなものがあります。 JAWS, NVDAApple VoiceOver、 Android トークバック。

JAWSを起動してブラウザを開くと、JAWSはページタイトルを読み上げます。アドレスバーにフォーカスを移動すると、JAWSは「アドレスバー」と読み上げ、入力した文字を1文字ずつ読み上げます。例えば、typing google.com は次のようなアナウンスを表示します。

Address Bar, w, w, w, period, g, o, o, g, l, e, period, c, o, m.
When the page finishes loading, JAWS announces "Google.com home page".
When focus reaches the search field, JAWS announces "Google search, edit".

スクリーンリーダーは、テキストフィールド内の単語を一つずつ読み上げ、リンクを「リンク」、ボタンを「ボタン」と読み上げることで、視覚障害のあるユーザーが各コントロールを識別できるようにします。ウェブサイトの構築が不十分な場合、スクリーンリーダーが要素を誤認識する可能性があります。例えば、プレーンテキストとしてスタイル設定されたリンクがコンテンツとして読み上げられ、ユーザーにとって重要な操作が隠されてしまうことがあります。これは企業にとって、実際の収益損失という形で損失につながります。

2) 色覚異常

色覚異常とは、特定の色を正しく認識できない状態を指します。最も一般的なのは赤緑色覚異常です。ウェブサイトが意味を伝えるために赤色を多用している場合、赤緑色覚異常のユーザーはメッセージを正しく理解できない可能性があります。

デザインチームは、情報を伝える際に色だけを使うべきではありません。赤いエラーボタンは、枠線で囲み、アイコンを付け、説明文を添えることで、より分かりやすくなります。黒と白は依然として最も安全な普遍的な配色であり、Starkプラグインやブラウザの色覚異常シミュレーターなどのツールは、問題を早期に発見するのに役立ちます。

3) 弱視

視覚障害やその他の網膜疾患のあるユーザーは、サイトを利用する際に特別なサポートが必要です。

1. 極端に小さな文字は避けてください。WCAGは、ズームせずに快適に拡大縮小できるデフォルトの本文サイズを推奨しています。
2. テキストを最大200%まで拡大した場合でも、レイアウトが適切に再配置されることを確認してください（WCAG 2.2達成基準）。行が途切れたり、コンテンツが重なったりしないようにしてください。
3. 通常のテキストでは最低4.5:1、大きなテキストでは最低3:1のコントラスト比を維持してください。

4) 運動機能障害およびその他の障害

アクセシビリティに関する重要な要件の一つは、サイト全体がマウスを使わずに操作できることです。すべてのリンク、ボタン、ラジオボタン、チェックボックス、ポップアップ、ドロップダウン、およびコントロールは、キーボードのみでアクセスおよび操作できる必要があります。

例えば、手の動きに制限のあるユーザーは、マウスを使用できない場合があります。タブキーでチェックボックスやリンクにアクセスできない場合、ユーザーはそれらの機能を利用できなくなります。

Alternative text should be provided for every image, audio file, and video so that screen readers can convey their meaning. Keyboard shortcuts should be available for important actions, and skip-to-content links should let keyboard users bypass repeated navigation.

フォーカスは常に視覚的に確認できる必要があります。ユーザーがTabキーを押したとき、ハイライトされたコントロールがはっきりと目立つようにしてください。視覚的にフォーカスが確認できることで、視覚障害や色覚異常のあるユーザーもページの流れを理解しやすくなり、誰にとってもナビゲーションが予測しやすくなります。

聴覚障害のあるユーザー 聴覚障害のあるユーザーは、ウェブサイトの視覚コンテンツは通常問題なく閲覧できますが、音声や動画には問題があります。すべての動画には字幕を、すべての音声ファイルには文字起こしまたは説明文を必ず含める必要があります。例えば、航空券の予約方法に関するチュートリアル動画には、聴覚障害のあるユーザーが内容を理解しやすいように、正確な字幕を付けるべきです。

アクセシビリティテストのサンプルテストケース

以下のチェックリストは、一般的なWebアプリケーションのアクセシビリティテストの承認に使用されます。これを出発点として、製品に関連するWCAG 2.2の達成基準を追加して拡張してください。

1. マウス操作やダイアログすべてに、キーボード操作の対応項目が用意されていますか？
2. ユーザー向けドキュメントには、支援技術を使用してアプリケーションを操作する方法が記載されていますか？
3. タブの順序は論理的で、自然なナビゲーションが可能になっていますか？
4. メインメニューへのショートカットキーはありますか？
5. このアプリケーションは、対象となるすべてのオペレーティングシステムとスクリーンリーダーに対応していますか？
6. 各画面やページの応答時間は明確に表示され、ユーザーがどれくらい待つ必要があるかを把握できるようになっていますか？
7. すべてのラベルは正しく記述され、プログラムによって対応するコントロールにリンクされていますか？
8. 色の選択肢は柔軟で、色覚異常シミュレーターを用いたテストが行​​われていますか？
9. 画像、アイコン、絵文字は、エンドユーザーが理解できる方法で使用されていますか？
10. このアプリケーションは、必要な場面で音声アラートを提供していますか？
11. ユーザーは音声や映像のコントロールを調整したり、ミュートしたりできますか？
12. ユーザーは印刷用および画面表示用のデフォルトフォントを上書きできますか？
13. ユーザーは、点滅、回転、または移動するディスプレイを調整または無効にできますか？
14. 色は情報を伝える唯一の手段として決して使用されないことを必ず確認してください。
15. システムカラーを反転させた場合でも、ハイライト表示は表示されますか？コントラスト比を変更してテストしてください。
16. 聴覚に障がいのあるユーザー向けに、音声や動画の文字起こし、または字幕は提供されていますか？
17. 障がいのあるユーザーがアプリケーションに慣れるためのトレーニングは提供されていますか？
18. すべてのインタラクティブなコントロールは、キーボードのみを使用してアクセス、操作、および閉じることができますか？

AIがアクセシビリティテストをどのように変えているか

AIはreshaですping アクセシビリティ テストは、3 つの実用的な方法で実施できます。まず、機械学習スキャナーがレンダリングされた DOM をコンピュータ ビジョン モデルと連携して読み取り、ルール ベースのツールでは見逃してしまう問題（不適切な代替テキストや実際のレイアウトで機能しない色の組み合わせなど）を検出します。次に、生成型 AI が、より適切な代替テキスト、より明確なエラー メッセージ、カスタム コンポーネントの ARIA 属性など、人間が読みやすい修正案を提案します。さらに、AI はユーザーへの影響に基づいて検出結果の優先順位を付けるため、チームは最も重要な問題に予算を投入できます。Deque axe AI、Evinced、UserWay、Siteimprove などのツールには、AI 機能が搭載されています。AI は、手動のスクリーン リーダー テストや障害のあるユーザーとのユーザー リサーチに取って代わるものではありませんが、手動によるトリアージ作業を大幅に削減し、アクセシビリティを開発サイクルの早い段階で考慮に入れるのに役立ちます。

アクセシビリティ テストの神話

アクセシビリティテストに関するよくある誤解と、それに対する事実を以下に示します。

神話： アクセシブルなウェブサイトを作成するには費用がかかります。

事実： そうではありません。設計段階でアクセシビリティを考慮し、基本的なテストを実施することで、後付け改修に比べて費用を節約でき、高額な手戻り作業を減らすことができます。

神話： アクセスできないウェブサイトをアクセス可能なウェブサイトに変更するには、時間と費用がかかりすぎる。

事実： すべての修正を一度に適用する必要はありません。まずは、障がいのあるユーザーに最も大きな影響を与える変更から始め、残りは今後のリリースで順次適用してください。

神話： アクセシビリティは、ありきたりで退屈だ。

事実： ページは視覚的に豊かで、tracWCAG 2.2 ガイドラインを満たしつつ、インタラクティブな表現を実現する。W3C は、テキストのみのバージョンは推奨せず、すべての人にとってアクセスしやすい単一のエクスペリエンスを推奨している。

神話： アクセシビリティ機能は、視覚障害者および身体障害者の方のみを対象としています。

事実： アクセシビリティガイドラインに従うことで、全体的な使いやすさが向上し、モバイルデバイスを使用しているユーザー、明るい日光の下や騒がしい環境にいるユーザーなど、すべてのユーザーにメリットがあります。

よくあるご質問