ウェブサイトやアプリがアクセシブルかどうかを判断するのは、大変な作業に思えるかもしれません。ユーザー補助に初めて取り組む場合、トピックの広範さから、どこから始めればよいか迷うことがあります。結局のところ、さまざまな能力に対応して働くということは、それに対応してさまざまな問題を考慮する必要があるということです。
この記事では、既存のサイトのユーザー補助に関する問題を、論理的な手順に分けて説明します。
キーボードから始める
マウスを使用できない、または使用しないことを選択しているユーザーにとって、画面上のすべての要素にアクセスするための主な手段はキーボード ナビゲーションです。この対象には、反復性ストレス障害（RSI）や麻痺などの運動機能障がいのあるユーザーや、スクリーン リーダーを使用するユーザーが含まれます。
キーボード操作が快適になるように、論理的なタブ順序と明確に区別できるフォーカス スタイルを設定します。
まず、サイトをタブで移動します。要素がフォーカスされる順序は DOM 順にする必要があります。フォーカスを設定すべき要素が不明な場合は、ユーザー補助機能の学習コースのフォーカスに関するモジュールをご覧ください。ユーザーが操作したり入力したりできるコントロールは、フォーカス可能にして、フォーカス インジケーター（フォーカス リングなど）を表示することをおすすめします。
カスタムのインタラクティブ コントロールはフォーカス可能である必要があります。JavaScript を使用して
<div>を凝ったプルダウンに変換しても、タブ順序に自動的に挿入されることはありません。カスタム コントロールにフォーカスを設定するには、tabindex="0"を指定します。tabindexの値が 0 より大きいとタブ順序が変更され、スクリーン リーダーを使用するユーザーにとって混乱を招く可能性があります。フォーカス可能なコンテンツはインタラクティブなコンテンツのみにします。見出しなどのインタラクティブでない要素に
tabindexを追加すると、画面を見ることができるキーボード ユーザーの操作が遅くなります。また、スクリーン リーダーはすでに読み上げを認識しているため、スクリーン リーダーのユーザーには役に立ちません。ページに新しいコンテンツを追加する場合は、ユーザーがそのコンテンツに対してアクションを実行できるように、まずそのコンテンツにフォーカスを合わせます。例については、ページレベルでフォーカスを管理するをご覧ください。
ユーザーがいつでも次の要素にフォーカスを移動できるようにサイトを設計します。オートコンプリート ウィジェットや、キーボードのフォーカスをトラップする可能性があるその他のコンテキストに注意してください。ページの他の部分ではなく、モーダルでユーザーが操作できるようにする場合は、フォーカスを一時的にトラップできますが、常にキーボードでアクセスできる方法でモーダルを終了できるようにする必要があります。例については、モーダルとキーボード トラップをご覧ください。
フォーカス コントロールを使えるようにする
カスタム コントロールを作成した場合は、ユーザーがキーボードのみを使用してその機能のすべてにアクセスできるようにします。キーボードでのアクセスを改善する手法については、コンポーネントでのフォーカスの管理をご覧ください。
画面外コンテンツを管理する
多くのサイトでは、DOM 内には存在しているのに画面には表示されないオフスクリーン コンテンツがあります。レスポンシブ ドロワー メニュー内のリンクや、まだ表示されていないモーダル ウィンドウ内のボタンなどが該当します。こうした要素が DOM 内に残っていると、特にオフスクリーン コンテンツをページの一部であるかのように読み上げるスクリーン リーダーの場合は、キーボード操作が複雑になる可能性があります。
これらの要素に対処する方法については、オフスクリーン コンテンツの処理をご覧ください。
スクリーン リーダーでテストする
一般的なキーボード サポートを改善すると、次のステップの準備が整います。次のステップでは、ページに適切なラベルとセマンティクスが設定されているか、スクリーン リーダーのナビゲーションの妨げになるものがないかを確認します。
セマンティック マークアップが支援技術によって解釈される仕組みについて詳しくは、コンテンツ構造をご覧ください。
- すべての画像で
altテキストが正しいことを確認します。この方法の例外は、画像が主にプレゼンテーション目的であり、コンテンツの重要な部分ではない場合です。スクリーン リーダーが画像をスキップすることを示すには、値を空の文字列alt=""に設定します。 - ラベルのすべてのコントロールを確認します。カスタム コントロールの場合は、
aria-labelまたはaria-labelledbyの使用が必要になる場合があります。例については、ARIA ラベルと関係をご覧ください。 - すべてのカスタム コントロールで、適切な
roleと、状態を伝える必要な ARIA 属性を確認します。たとえば、カスタム チェックボックスは、状態を適切に伝えるためにrole="checkbox"とaria-checked="true|false"が必要です。ARIA を使用してカスタム コントロールに不足しているセマンティクスを提供する方法の概要については、ARIA の概要をご覧ください。 - ページ内の情報の流れを合理的にします。スクリーン リーダーは DOM の順序でページを移動するため、CSS を使用して視覚的に位置を変更した要素は、意味不明な順序で読み上げられます。ページの上の方に表示する必要がある場合は、DOM 内で物理的に上に移動します。
- ページ上のすべてのコンテンツでスクリーン リーダーによるナビゲーションをサポートすることを目標としてください。サイトのどのセクションも、スクリーン リーダーによるアクセスから完全に非表示またはブロックされていないことを確認します。
- スクリーン リーダーからコンテンツを非表示にする必要がある場合（画面外にある場合や、表示専用の場合など）は、そのコンテンツを
aria-hidden="true"に設定します。詳しくは、コンテンツの非表示をご覧ください。
- スクリーン リーダーからコンテンツを非表示にする必要がある場合（画面外にある場合や、表示専用の場合など）は、そのコンテンツを
スクリーン リーダーについて理解を深める
スクリーン リーダーの習得は大変そうに見えますが、実はユーザー フレンドリーです。一般的に、ほとんどのデベロッパーはいくつかの単純なキーコマンドだけで対応しています。
Mac をお使いの場合は、Mac OS に付属のスクリーン リーダーである VoiceOver に関するこちらの動画をご覧ください。パソコンをお使いの場合は、寄付によって支えられている Windows 用オープンソース スクリーン リーダーである NVDA に関するこちらの動画をご覧ください。
aria-hidden でキーボードのフォーカスが妨げられない
ARIA は要素のセマンティクスにのみ影響し、要素の動作には影響しないことを理解することが重要です。aria-hidden="true" を使用して要素をスクリーン リーダーに非表示にできますが、その要素のフォーカス動作は変更されません。画面外のインタラクティブ コンテンツの場合は、inert 属性を使用して、キーボード フローから完全に削除されるようにします。古いブラウザの場合は、aria-hidden="true" と tabindex="-1" を組み合わせます。
インタラクティブな要素には、その目的と状態を示す必要があります
コントロールの機能に関する視覚的なヒント（アフォーダンス）を提供することによって、さまざまなデバイスを使用しているさまざまなユーザーがサイトを操作して移動しやすくなります。
- リンクやボタンなどのインタラクティブな要素は、インタラクティブでない要素と区別できる必要があります。要素がクリック可能かどうかがわからないと、ユーザーはサイトやアプリを操作しにくくなります。インタラクティブな要素を示す方法はたくさんあります。一般的な方法として、リンクを下線を引いて周囲のテキストと区別する方法があります。
- フォーカスの要件と同様に、リンクやボタンなどのインタラクティブな要素には、マウス ユーザーにポインタがクリック可能な要素の上に置かれていることを伝える
hover状態が必要です。ただし、これらの要素を他の入力方法でアクセスできるようにするには、hover状態なしで区別できるようにする必要があります。
見出しとランドマークを活用する
見出しとランドマーク要素はページのセマンティック構造を形成し、支援技術を使用しているユーザーのナビゲーション効率を大幅に高めます。多くのスクリーン リーダー ユーザーは、初めて見慣れないページにアクセスしたときに、通常は見出しで移動しようとすると報告しています。
同様に、スクリーン リーダーには、<main> や <nav> などの重要なランドマークにジャンプする機能もあります。そのため、ページの構造をどのように使用してユーザー エクスペリエンスをガイドするかを検討することが重要です。
h1-h6階層を使用します。見出しは、ページのアウトラインを作成するツールと考えてください。見出しの組み込みスタイルに依存しないでください。代わりに、すべて同じサイズであるかのように扱い、プライマリ コンテンツ、セカンダリ コンテンツ、ターシャリ コンテンツに意味的に適切なレベルを使用します。次に、CSS を使用してヘッダーをデザインに合わせて調整します。- ランドマーク要素とロールを使用して、ユーザーが繰り返しのコンテンツをスキップできるようにします。多くの支援技術には、
<main>要素や<nav>要素で定義されているような、ページの特定の部分に移動するためのショートカットが用意されています。これらの要素には、暗黙的なランドマークのロールがあります。ARIArole属性を使用して、<div role="search">のようにページ上の領域を明示的に定義することもできます。その他の例については、セマンティクスとコンテンツのナビゲーションをご覧ください。 role="application"は、使用経験がない限り使用しないでください。applicationランドマーク ロールは、ショートカットを無効にして、すべてのキー入力をページに渡すように支援技術に指示します。つまり、スクリーン リーダーのユーザーが通常ページの移動に使用するキーが機能しなくなり、キーボードの処理をすべて自分で実装する必要があります。
スクリーン リーダーで見出しとランドマークを確認する
VoiceOver や NVDA などのスクリーン リーダーには、ページ上の重要な領域にスキップするためのコンテキスト メニューがあります。ユーザー補助をテストするときに、これらのメニューを使用してページの概要を把握し、ヘッダーレベルが適切かどうか、どのランドマークが使用されているかを判断できます。
詳しくは、VoiceOver と NVDA の基本に関するこちらの動画をご覧ください。
プロセスを自動化する
サイトのユーザー補助を手動でテストするのは、面倒でミスが発生しがちです。できるだけテストを自動化することをおすすめします。ブラウザ拡張機能とコマンドライン ユーザー補助テストスイートを使用できます。
- ページは、aXe または WAVE のブラウザ拡張機能のすべてのテストに合格していますか？他にも利用可能なオプションがありますが、これらの拡張機能は、コントラスト比の不合格や ARIA 属性の欠落など、微妙な問題を検出できるため、手動テスト プロセスに追加すると便利です。
- コマンドラインで作業する場合は、axe-cli を使用します。これは aXe ブラウザ拡張機能と同じ機能を備えていますが、ターミナルから実行できます。
- 特に継続的インテグレーション環境でリグレッションを回避するには、axe-core などのライブラリを自動テスト スイートに組み込みます。axe-core は、aXe Chrome 拡張機能と同じエンジンですが、コマンドライン ユーティリティです。
- フレームワークまたはライブラリを使用している場合、独自のユーザー補助ツールを提供していますか？たとえば、Angular の protractor-accessibility-plugin などです。可能な限り、利用可能なツールを活用します。
Lighthouse を使用して PWA をテストする
Lighthouse は、プログレッシブ ウェブアプリ（PWA）のパフォーマンスを測定するツールです。また、axe-core ライブラリを使用してユーザー補助機能テストを実施します。
Lighthouse をすでに使用している場合は、レポートで不合格となったユーザー補助テストを探します。エラーを修正して、サイトの全体的なユーザー エクスペリエンスを改善します。