このモジュールでは、ユーザー補助技術（AT）によるユーザー補助テストに焦点を当てます。障がいのある人は、AT を使用して、タスクを実行する能力を高めたり、維持したり、改善したりできます。
デジタル空間では、AT は次のようなものがあります。
- なしまたは低技術: 頭や口のスティック、手持ちの拡大鏡、大きなボタンのデバイス
- ハイテク: 音声起動デバイス、アイトラッキング デバイス、適応型キーボードとマウス
- ハードウェア: スイッチボタン、人間工学に基づいたキーボード、自動更新点字デバイス
- ソフトウェア: テキスト読み上げプログラム、ライブ字幕、スクリーン リーダー
全体的なテスト ワークフローで複数のタイプの AT を使用することをおすすめします。
スクリーン リーダーのテストの基本
このモジュールでは、最も一般的なデジタル AT の 1 つであるスクリーン リーダーについて説明します。スクリーン リーダーは、ウェブサイトまたはアプリの基盤となるコードを読み取り、その情報を音声または点字出力に変換するソフトウェアです。
スクリーン リーダーは、目の不自由な方やろうあ者にとって不可欠ですが、ロービジョン、読み取り障害、認知障がいのある方にも役立ちます。
ブラウザの互換性
利用可能なスクリーン リーダーは複数あります。最も一般的なスクリーン リーダーは、デスクトップ パソコン用の JAWS、NVDA、VoiceOver、モバイル デバイス用の VoiceOver と TalkBack です。
オペレーティング システム（OS）、お気に入りのブラウザ、使用しているデバイスによっては、1 つのスクリーン リーダーが最適な選択肢となる場合があります。ほとんどのスクリーン リーダーは、特定のハードウェアとウェブブラウザを念頭に置いて構築されています。画面読み取り装置を、その装置でキャリブレーションされていないブラウザで使用すると、さらに多くの「バグ」や予期しない動作が発生する可能性があります。スクリーン リーダーは、次の組み合わせで使用すると最適に機能します。
| スクリーン リーダー | OS | ブラウザの互換性 |
|---|---|---|
| Job Access With Speech（JAWS） | Windows | Chrome、Firefox、Edge |
| Non-Visual Desktop Access（NVDA） | Windows | Chrome と Firefox |
| ナレーター | Windows | Edge |
| VoiceOver | macOS | Safari |
| Orca | Linux | Firefox |
| TalkBack | Android | Chrome と Firefox |
| VoiceOver（モバイル用） | iOS | Safari |
| ChromeVox | ChromeOS | Chrome |
スクリーン リーダーのコマンド
パソコンまたはモバイル デバイスのスクリーン リーダー ソフトウェアを適切に設定したら、スクリーン リーダーのドキュメント（上の表にリンクされています）を確認し、スクリーン リーダーの基本的なコマンドをいくつか試して、技術に慣れ親しんでください。これまでスクリーン リーダーを使用していた場合は、新しいスクリーン リーダーをお試しください。
ユーザー補助テストにスクリーン リーダーを使用する場合、スクリーン リーダー ユーザーのエクスペリエンスをエミュレートするのではなく、ウェブサイトやアプリの使用を妨げるコードの問題を検出することが目的です。そのため、基本的な知識、いくつかのスクリーン リーダー コマンド、少し（またはたくさん）の練習があれば、できることはたくさんあります。
画面読み上げツールやその他の AT を使用しているユーザーのユーザー エクスペリエンスを詳しく把握する必要がある場合は、多くの組織や個人と連携して、この貴重な分析情報を入手できます。AT を使用して一連のルールに照らし合わせてコードをテストし、ユーザーにエクスペリエンスについて尋ねると、多くの場合、異なる結果が得られます。どちらも、完全に包括的なプロダクトを作成するために重要な要素です。
パソコンのスクリーン リーダーのキーコマンド
| 要素 | NVDA（Windows） | VoiceOver（macOS） |
|---|---|---|
| 一般的なコマンドキー | 挿入 | Ctrl+Option |
| 音声の停止 | 管理 | 管理 |
| 次/前のページを読む | ↓ または ↑ | Ctrl+Option+→ または ← |
| 読み上げを開始 | 挿入↓ | Ctrl+Option+A |
| 要素リスト/ローター | NVDA + F7 | Ctrl+Option+U |
| ランドマーク | D | Ctrl+Option+U |
| 見出し | H | Ctrl+Option+Command+H |
| リンク | K | Ctrl+Option+Command+L |
| フォーム コントロール | F | control+option+command+J |
| テーブル | T | Ctrl+OptionCommand+T |
| 表内 | 挿入 Alt+↓ ↑ ← → | Ctrl+Option+↓ ↑ ← → |
モバイル スクリーン リーダーの主なコマンド
| 要素 | TalkBack（Android） | VoiceOver（iOS） |
|---|---|---|
| 探索 | 1 本の指で画面上をドラッグする | 1 本の指で画面上をドラッグする |
| 選択または有効化 | ダブルタップ | ダブルタップ |
| 上下に移動 | 2 本の指で上または下にスワイプします | 3 本の指で上または下にスワイプします |
| ページの切り替え | 2 本の指で左または右にスワイプします | 3 本の指で左または右にスワイプします |
| 次/前 | 1 本の指で左右にスワイプする | 1 本の指で左右にスワイプする |
スクリーン リーダーのテストのデモ
デモをテストするために、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 ラベルが元のリンクテキストをオーバーライドする場合があります。その場合は、その情報を更新に含めてください。
<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>
前述の装飾画像の例と同様に、HTML に bullet クラスの role="presentation" を追加して、スクリーン リーダーから非表示にできます。同様に、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 で確認できます。
学んだことを基に、ご自身のウェブサイトやアプリのユーザー補助を確認しましょう。
これらのユーザー補助機能テストの目的は、ユーザーが遭遇する可能性のある問題をできるだけ多く解決することです。ただし、完了したウェブサイトやアプリが完全にアクセス可能になるわけではありません。ウェブサイトやアプリの設計プロセス全体でユーザー補助機能を考慮し、これらのテストを他のリリース前テストに組み込むことで、最も効果的にテストできます。
理解度を確認する
ユーザー補助機能の自動テストに関する知識をテストする。
ユーザー補助機能のテストに最適なスクリーン リーダーは何ですか？
支援技術を使用したテストの目的は何ですか？