支援技術のテスト

このモジュールでは、ユーザー補助技術（AT）によるユーザー補助テストに焦点を当てます。障がいのある人は、AT を使用して、タスクを実行する能力を高めたり、維持したり、改善したりできます。

デジタル空間では、AT は次のようなものがあります。

• なしまたは低技術: 頭や口のスティック、手持ちの拡大鏡、大きなボタンのデバイス
• ハイテク: 音声起動デバイス、アイトラッキング デバイス、適応型キーボードとマウス
• ハードウェア: 切り替えボタン、人間工学に基づくキーボード、自動更新型点字デバイス
• ソフトウェア: テキスト読み上げプログラム、ライブ字幕、スクリーン リーダー

全体的なテスト ワークフローで複数のタイプの AT を使用することをおすすめします。

スクリーン リーダーのテストの基本

このモジュールでは、最も一般的なデジタル AT の 1 つであるスクリーン リーダーについて説明します。スクリーン リーダーは、ウェブサイトまたはアプリの基盤となるコードを読み取り、その情報を音声または点字出力に変換するソフトウェアです。

スクリーン リーダーは目の不自由な人にとって不可欠ですが、ロービジョン、読字障害、認知障がいのある人にとってもメリットがあります。

ブラウザの互換性

利用できるスクリーン リーダーは複数あります。最も一般的なスクリーン リーダーは、デスクトップ パソコン用の 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>

すべてを正しく更新した場合、視覚的な変化はありませんが、スクリーン リーダーの利便性が大幅に向上します。

修正しましょう。

アクセスできない要素の中には、サイトを見ただけでは確認できないものもあります。コンテンツ構造モジュールで、見出しレベルとセマンティック 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 に 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 で確認できます。

学んだことを基に、ご自身のウェブサイトやアプリのユーザー補助を確認しましょう。

これらのユーザー補助機能テストの目的は、ユーザーが遭遇する可能性のある問題をできるだけ多く解決することです。ただし、終了後にウェブサイトまたはアプリに完全にアクセスできるわけではありません。ウェブサイトやアプリの設計プロセス全体でユーザー補助機能を考慮し、これらのテストを他のリリース前テストに組み込むことで、最も効果的にテストできます。

理解度を確認する

ユーザー補助機能の自動テストに関する知識をテストする