支援技術のテスト

このモジュールでは、アクセシビリティ テストでの支援技術（AT）の使用に焦点を当てます。障がいのある人は、AT を使用してタスクを実行する能力を高めたり、維持したり、改善したりできます。

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

• ローテクまたはハイテクではない: 頭や口で操作するスティック、手持ちの拡大鏡、大きなボタンを備えたデバイス
• ハイテク: 音声起動デバイス、アイトラッキング デバイス、アダプティブ キーボードとマウス
• ハードウェア: スイッチ ボタン、エルゴノミクス キーボード、自動更新式点字デバイス
• ソフトウェア: テキスト読み上げプログラム、自動字幕起こし、スクリーン リーダー

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

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

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

スクリーン リーダーは、視覚障がいや聴覚障がいのある人にとって不可欠なツールですが、ロービジョン、読字障がい、認知障がいのある人にも役立ちます。

ブラウザの互換性

複数のスクリーン リーダー オプションを利用できます。最も一般的なスクリーン リーダーは、パソコンでは JAWS、NVDA、VoiceOver、モバイル デバイスでは VoiceOver と Talkback です。

オペレーティング システム（OS）、お気に入りのブラウザ、使用しているデバイスによっては、最適なスクリーン リーダーが 1 つに絞られることがあります。ほとんどのスクリーン リーダーは、特定のハードウェアとウェブブラウザを念頭に置いて構築されています。調整されていないブラウザでスクリーン リーダーを使用すると、バグや予期しない動作が発生する可能性が高くなります。スクリーン リーダーは、次の組み合わせで使用すると最適に動作します。

スクリーン リーダーのコマンド

パソコンやモバイル デバイスのスクリーン リーダー ソフトウェアを適切に設定したら、スクリーン リーダーのドキュメント（上記の表にリンク）を参照し、スクリーン リーダーの基本的なコマンドをいくつか実行して、このテクノロジーに慣れてください。スクリーン リーダーを以前に使用したことがある場合は、新しいスクリーン リーダーを試してみることをおすすめします。

ユーザー補助機能のテストでスクリーン リーダーを使用する場合、スクリーン リーダー ユーザーの操作をエミュレートするのではなく、ウェブサイトやアプリの使用を妨げるコードの問題を検出することが目的です。そのため、基礎的な知識、いくつかのスクリーン リーダー コマンド、少し（または多くの）練習があれば、さまざまな操作を行うことができます。

スクリーン リーダーやその他の支援技術を使用しているユーザーのユーザー エクスペリエンスをさらに理解する必要がある場合は、多くの組織や個人と協力して、貴重な分析情報を入手できます。AT を使用して一連のルールに照らしてコードをテストする場合と、ユーザーにエクスペリエンスについて尋ねる場合とでは、結果が異なることがよくあります。どちらも、完全にインクルーシブなプロダクトを作成するうえで重要な側面です。

パソコンのスクリーン リーダーのキーコマンド

モバイル スクリーン リーダーのキーコマンド

スクリーン リーダーのテストのデモ

デモをテストするために、macOS を実行しているノートパソコンで Safari を使用して音声をキャプチャしました。これらの手順は、任意のスクリーン リーダーを使用して実行できますが、一部のエラーの発生方法がこのモジュールで説明されている方法と異なる場合があります。

ステップ 1

更新された CodePen をご覧ください。自動と手動の両方のアクセシビリティ更新が適用されています。

デバッグモードで確認して、次のテストに進みます。これは、デモのウェブページを囲む <iframe> を削除するため、重要です。この <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 で確認できます。

学んだことを活かして、ご自身のウェブサイトやアプリのアクセシビリティを確認してみましょう。

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