このモジュールでは、ユーザー補助機能のテストにおける支援技術（AT）の使用に焦点を当てます。障がいのある人は、AT を使用することで、作業の実行能力を高めたり、維持したり、改善したりできます。
デジタル空間では、AT には次のような特徴があります。
- ノーテク / ローテク: ヘッド スティック、マウス スティック、手持ち拡大鏡、大きなボタンを備えたデバイス
- ハイテク: 音声起動デバイス、視線追跡デバイス、アダプティブ キーボード/マウス
- ハードウェア: スイッチボタン、人間工学に基づくキーボード、自動更新点字デバイス
- ソフトウェア: テキスト読み上げプログラム、自動字幕起こし、スクリーン リーダー
テストのワークフロー全体では、複数の種類のアートトラックを使用することをおすすめします。
スクリーン リーダーのテストの基本
このモジュールでは、特によく利用されているデジタル AT であるスクリーン リーダーに焦点を当てます。スクリーン リーダーとは、ウェブサイトやアプリの基盤となるコードを読み取り、その情報を音声または点字出力に変換するソフトウェアです。
スクリーン リーダーは目の見えない方や目の見えない方にとって不可欠ですが、ロービジョンの方、読書障がい、認知障がいのある方にとっても有益です。
ブラウザの互換性
スクリーン リーダーには複数のオプションが用意されています。現在よく使われているスクリーン リーダーは、デスクトップ パソコン向けの JAWS、NVDA、VoiceOver、モバイル デバイス向けの VoiceOver と TalkBack です。
ご使用のオペレーティング システム（OS）、お気に入りのブラウザ、使用するデバイスによっては、1 つのスクリーン リーダーを使用するのが最適なオプションとなる場合もあります。ほとんどのスクリーン リーダーは、特定のハードウェアとウェブブラウザを想定して作られています。キャリブレーションされていないブラウザでスクリーン リーダーを使用すると、より多くの「バグ」や予期しない動作が発生することがあります。スクリーン リーダーは、次の組み合わせで使用すると特に効果的です。
スクリーン リーダーのコマンド
お使いのパソコンまたはモバイル デバイス用のスクリーン リーダー ソフトウェアを正しく設定したら、スクリーン リーダーのドキュメント（上記の表からリンク）を参照して、スクリーン リーダーの重要なコマンドを実行して、スクリーン リーダーの技術についてよく理解してください。以前にスクリーン リーダーを使ったことがある場合は、新しいスクリーン リーダーを試してみることをおすすめします。
スクリーン リーダーをユーザー補助機能のテストに使用する場合の目的は、スクリーン リーダーのユーザー エクスペリエンスを模倣することではなく、ウェブサイトまたはアプリの使用を妨げるコード内の問題を検出することです。そのため、一定の基礎知識、いくつかのスクリーン リーダーのコマンド、少し（または多くの）練習を行うことで、多くのことを行えるようになります。
スクリーン リーダーなどのデバイスを使用するユーザーのユーザー エクスペリエンスについてさらに詳しく理解する必要がある場合は、多くの組織や個人と連携して、この貴重な分析情報を得ることができます。AT を使用して一連のルールに照らしてコードをテストし、ユーザー エクスペリエンスについてユーザーに質問すると、多くの場合、異なる結果が得られることに留意してください。どちらもインクルーシブなプロダクトを生み出すうえで重要な側面です。
デスクトップ スクリーン リーダー用の主要なコマンド
モバイル スクリーン リーダーの主なコマンド
スクリーン リーダーのテストのデモ
このデモをテストするため、MacOS を搭載したノートパソコンで Safari を使用し、音声をキャプチャしました。この手順はどのスクリーン リーダーを使用しても行うことができますが、エラーの発生方法はこのモジュールの説明とは異なる場合があります。
ステップ 1
更新された CodePen にアクセスします。自動と手動のユーザー補助アップデートがすべて適用されています。
テストをデバッグモードで表示して、次のテストに進みます。デモ ウェブページを囲む <iframe> が削除され、これが一部のテストツールを妨げる可能性があるため、この点は重要です。CodePen のデバッグモードの詳細を確認してください。
ステップ 2
任意のスクリーン リーダーを有効にして、デモページに移動します。特定の問題に焦点を当てる前に、ページ全体を上から下に移動することをおすすめします。
デモに修正を適用する前と後の問題ごとに、スクリーン リーダーを記録しました。ご自分のスクリーン リーダーを使用して、デモを行うことをおすすめします。
問題 1: コンテンツ構造
見出しとランドマークは、ユーザーがスクリーン リーダーを使用して移動する主な方法の一つです。これらが存在しない場合、スクリーン リーダーのユーザーはページ全体を読んでコンテキストを理解する必要があります。これには時間がかかり、不満の原因となる可能性があります。デモのいずれかの要素を移動しようとすると、存在しないことにすぐに気づくはずです。
- ランドマークの例:
<div class="main">...</div> - 見出しの例:
<p class="h1">Join the Club</p>
すべてを正しく更新していれば表示は変わりませんが、スクリーン リーダーの操作性は大幅に向上します。
修正しましょう。
アクセスできない要素は、サイトを見るだけでは確認できないものもあります。見出しレベルとセマンティック HTML の重要性については、コンテンツ構造モジュールで学習しました。コンテンツは見出しのように見えても、実際には定型化された <div> でラップされています。
見出しとランドマークの問題を解決するには、まず、マークアップする各要素を特定し、関連する HTML を更新する必要があります。関連する CSS も必ず更新してください。
ランドマークの例: <main>...</main>
見出しの例: <h1>Join the Club</h1>
すべてを正しく更新していれば表示は変わりませんが、スクリーン リーダーの操作性は大幅に向上します。
問題 2: リンクのコンテキスト
スクリーン リーダーのユーザーに、リンクの目的や、リンク先がウェブサイトやアプリ外の新しい場所にリダイレクトされるかどうかについてのコンテンツを提供することが重要です。
このデモでは、アクティブ画像の代替テキストを更新したときにほとんどのリンクが修正されましたが、さまざまな希少疾患に関するリンクがいくつかあります。これらのリンクは、特に新しい場所にリダイレクトされるため、追加のコンテキストが役立つ可能性があります。
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
スクリーン リーダーのユーザーに対しては、この問題を修正するために、ビジュアル要素に影響を与えずに情報を追加するようにコードを更新します。または、読字障害や認知障害を持つ人など、さらに多くの人々に役立つように、代わりに視覚的なテキストを追加することも考えられます。
リンク情報を追加する場合、さまざまなパターンが考えられます。1 つの言語のみをサポートするシンプルな環境であることから、この状況では ARIA ラベルがわかりやすいオプションとなります。ARIA ラベルが元のリンクテキストより優先されるため、更新内容には必ず ARIA ラベルの情報を含めてください。
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
Maple syrup urine disease (MSUD)
</a>
問題 3: 装飾的な画像
自動テスト モジュールでは、デモページのメイン スプラッシュ画像として機能するインライン SVG を Lighthouse で確認できませんでしたが、スクリーン リーダーはそれを検出し、追加情報なしで「画像」として通知します。SVG に role="img" 属性を明示的に追加しなくても、これは当てはまります。
<div class="section-right">
<svg>...</svg>
</div>
この問題を解決するには、まず画像が情報豊富か装飾的かを判断する必要があります。この決定に基づいて、適切な画像代替テキスト（説明画像）を追加するか、スクリーン リーダーのユーザーに画像を非表示にする（装飾的）必要があります。
画像の最適な分類方法の長所と短所を比較検討し、装飾的であると判断しました。つまり、画像を非表示にするには、コードを追加または変更します。簡単な方法は、SVG 画像に role="presentation" を直接追加することです。すると、スクリーン リーダーにシグナルが送信され、その画像をスキップして画像グループには追加されないようにします。
<div class="section-right">
<svg role="presentation">...</svg>
</div>
問題 4: 箇条書き
スクリーン リーダーが「希少疾患」セクションの下にある CSS 箇条書き画像を読み上げていることに気付いたかもしれません。画像モジュールで説明した従来のタイプの画像ではありませんが、コンテンツの流れを妨げ、スクリーン リーダーのユーザーの注意をそらしたり混乱させたりする可能性があるため、画像を修正する必要があります。
<p class="bullet">...</p>
前述の装飾画像の例と同様に、箇条書きクラスを使用して role="presentation" を HTML に追加し、スクリーン リーダーから非表示にすることができます。同様に、role="none" も機能します。ただし、aria-hidden: true は使用しないでください。使用すると、スクリーン リーダーのユーザーにすべての段落情報が見えなくなります。
<p class="bullet" role="none">...</p>
問題 5: フォーム フィールド
フォームのモジュールでは、すべてのフォーム フィールドに視覚的かつプログラマティックなラベルも設定する必要があることを学習しました。このラベルは常に表示する必要があります。
このデモでは、ニュースレター登録メールのフィールドに、ビジュアルとプログラマティックの両方のラベルがありません。テキスト プレースホルダ要素がありますが、これは視覚的に永続的ではなく、すべてのスクリーン リーダーと完全には互換性がないため、ラベルに代わるものではありません。
<form>
<div class="form-group">
<input type="email" placeholder="Enter your e-mail address" required>
<button type="submit">Subscribe</button>
</div>
</form>
この問題を解決するには、テキスト プレースホルダを類似のラベル要素に置き換えます。このラベル要素はプログラムによってフォーム項目に接続され、項目にコンテンツが追加された場合でもラベルが表示され続けるよう、JavaScript で移動が追加されています。
<form>
<div class="form-group">
<input type="email" required id="youremail" name="youremail" type="text">
<label for="youremail">Enter your e-mail address</label>
<button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
</div>
</form>
まとめ
これで完了です。このデモのテストをすべて完了しました。これらの変更はすべて、このデモ用に更新された Codepen で確認できます。
ここで、学習した内容を活用してご自身のウェブサイトやアプリのユーザー補助機能を確認しましょう。
このユーザー補助機能テストの目的は、ユーザーが遭遇する可能性のある問題をできるだけ多く解決することです。ただし、作業の完了後にそのウェブサイトやアプリに完全にアクセスできるとは限りません。プロセス全体を通じてユーザー補助を考慮してウェブサイトまたはアプリを設計し、それらのテストを他のリリース前テストに組み込むことで、最大限の成果を引き出すことができます。
理解度チェック
自動化されたユーザー補助テストに関する知識をテストする
ユーザー補助機能のテストに最適なスクリーン リーダーはどれですか。
支援技術を使用したテストの目的は何ですか。