このモジュールでは、ユーザー補助機能のテストにおける支援技術（AT）の使用に焦点を当てます。障がいのある人は、運動能力の向上、維持、向上に役立つ AT を利用できます。
デジタル空間では、AT とは次のようなものです。
- なし/ローテク: ヘッド/口スティック、手持ちの拡大鏡、大きなボタンを備えたデバイス
- ハイテク: 音声認識デバイス、視線追跡デバイス、適応型キーボード/マウス
- ハードウェア: 切り替えボタン、人間工学に基づくキーボード、自動更新型点字デバイス
- ソフトウェア: テキスト読み上げプログラム、自動字幕起こし、スクリーン リーダー
テスト ワークフロー全体で複数のタイプの AT を使用することをおすすめします。
スクリーン リーダーのテストの基本
このモジュールでは、特に人気の高いデジタル AT であるスクリーン リーダーについて説明します。スクリーン リーダーは、ウェブサイトやアプリの基礎となるコードを読み上げるソフトウェアです。その情報を音声または点字出力に変換して、ユーザーに提供します。
スクリーン リーダーは、目の不自由な方や聴覚障がいのある方にとって不可欠な機能ですが、ロービジョン、読字障害、認知障がいのある方にとってもメリットとなる可能性があります。
ブラウザの互換性
利用可能なスクリーン リーダーは複数あります。現在広く使用されているスクリーン リーダーは、デスクトップ パソコン向けの JAWS、NVDA、VoiceOver と、モバイル デバイス向けの VoiceOver と Talkback です。
オペレーティング システム（OS）、お好みのブラウザ、デバイスによっては、1 つのスクリーン リーダーが最適な選択肢として見つかる場合があります。ほとんどのスクリーン リーダーは、特定のハードウェアとウェブブラウザ向けに構築されています。スクリーン リーダーが調整されていないブラウザでスクリーン リーダーを使用すると、より多くの「バグ」が発生することがあります保護します。スクリーン リーダーは、次の組み合わせで使用すると最適に機能します。
スクリーン リーダーのコマンド
パソコンまたはモバイル デバイス用のスクリーン リーダー ソフトウェアを適切に設定したら、スクリーン リーダーのドキュメント（上の表にリンク）を参照し、スクリーン リーダーの基本的なコマンドをいくつか実行して、このテクノロジーについて理解を深めます。スクリーン リーダーを使用したことがある場合は、新しいスクリーン リーダーをぜひお試しください。
ユーザー補助機能のテストにスクリーン リーダーを使用する場合の目標は、ウェブサイトやアプリの使用を妨げるコード内の問題を検出することであり、スクリーン リーダーのユーザーをエミュレートすることではありません。そのため、ある程度の基礎知識、いくつかのスクリーン リーダーのコマンド、そして少し、あるいは多くの練習をすれば、さまざまなことができます。
スクリーン リーダーやその他の AT を使用するユーザーのユーザー エクスペリエンスについて理解を深める必要がある場合は、多くの組織や個人と連携することで、この貴重なインサイトを得ることができます。AT を使用して一連のルールに照らしてコードをテストし、ユーザーに経験について尋ねると、異なる結果が得られることがよくあります。どちらも、包括的なプロダクトを構築するための重要な側面です。
パソコンのスクリーン リーダーの主なコマンド
モバイル スクリーン リーダーの主なコマンド
スクリーン リーダーのテストデモ
このデモをテストするために、macOS を搭載したノートパソコンで Safari を使用して音声をキャプチャしました。以下の手順はどのスクリーン リーダーを使用しても実施できますが、エラーの解決方法がこのモジュールの説明と異なる場合があります。
ステップ 1
更新された CodePen にアクセスします。 ユーザー補助の自動更新と 手動更新がすべて適用されています
デバッグモードで表示して、次の手順に進んでください。
説明します。これを囲む <iframe> が削除されるため、これは重要です。
使用すると、一部のテストツールに影響する可能性があります。詳細:
CodePen のデバッグモード。
ステップ 2
任意のスクリーン リーダーを有効にしてデモページに移動します。特定の問題に焦点を当てる前に、ページ全体を上から下に移動することをおすすめします。
デモに修正を適用する前と後で、問題ごとにスクリーン リーダーを記録しました。ご自身のスクリーン リーダーを使用して、デモを実行することをおすすめします。
問題 1: コンテンツの構造
見出しやランドマークは、スクリーン リーダーを使用して移動する主要な手段の一つです。これらがない場合、スクリーン リーダーのユーザーは、コンテキストを理解するためにページ全体を読む必要があります。これには多くの時間がかかり、不満が生じる。このデモでどちらかの要素に移動しようとすると、その要素が存在しないことがすぐにわかります。
- ランドマークの例:
<div class="main">...</div> - 見出しの例:
<p class="h1">Join the Club</p>
すべてを正しく更新していれば、見た目は変わりませんが、スクリーン リーダーのエクスペリエンスは大幅に向上します。
<ph type="x-smartling-placeholder">
修正しましょう。
アクセスできない要素の中には、単にサイトを見るだけでは確認できないものもあります。見出しレベルとセマンティック HTML の重要性については、コンテンツ構造モジュールですでに説明しました。コンテンツは見出しのように見える場合もありますが、実際には、コンテンツは定型化された <div> で囲まれています。
見出しやランドマークの問題を解決するには、まずそのようにマークアップする必要がある要素を特定し、関連する HTML を更新する必要があります。関連する CSS も必ず更新してください。
ランドマークの例: <main>...</main>
見出しの例: <h1>Join the Club</h1>
すべてを正しく更新していれば、見た目は変わりませんが、スクリーン リーダーのエクスペリエンスは大幅に向上します。
<ph type="x-smartling-placeholder">問題 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: 装飾画像
自動テスト モジュールでは、Lighthouse ではデモページのメインのスプラッシュ画像として機能するインライン SVG を検出できませんでしたが、スクリーン リーダーはこの SVG を見つけて「画像」と読み上げます。追加情報なしで取得できますこれは、SVG に role="img" 属性を明示的に追加しなくても当てはまります。
<div class="section-right">
<svg>...</svg>
</div>
この問題を解決するには、まず画像が情報提供的か装飾的かを判断する必要があります。この判断に基づき、適切な画像の代替テキスト（情報提供画像）を追加するか、スクリーン リーダーのユーザーに対して画像を非表示にする（装飾用）必要があります。
画像の最適な分類方法の長所と短所を検討し、装飾的なものであると判断しました。つまり、画像を非表示にするためにコードを追加または変更したいと考えています。簡単な方法は、role="presentation" を SVG 画像に直接追加することです。これにより、この画像をスキップして画像グループに含めないようにするシグナルがスクリーン リーダーに送信されます。
<div class="section-right">
<svg role="presentation">...</svg>
</div>
問題 4: 箇条書き
お気づきかもしれませんが、スクリーン リーダーは 希少疾患のセクションもあります従来の画像形式ではありませんが 画像モジュールで説明したように、既存の環境を中断させるため、 スクリーン リーダーのユーザーの注意をそらしたり、混乱させたりするおそれがあります。
<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 で確認できます。
学習した内容を活用して、ご自身の アクセスします。
このユーザー補助機能テストの目標は、できるだけ多くの ユーザーが直面する可能性のある問題です。そのウェブサイトまたはアプリが 完了したら完全にアクセスできます。最適な方法を見つけるには プロセス全体でユーザー補助を考慮したウェブサイトやアプリを設計する。 それらのテストを他のリリース前テストに組み込む
理解度をチェックする
ユーザー補助機能の自動テストに関する知識をテストする
ユーザー補助機能のテストに使用するのに最適なスクリーン リーダーはどれですか。
支援技術を使ったテストの目的は何ですか。