ウェブサイトまたはアプリがアクセス可能かどうかの判断は、骨の折れる作業のように思えるかもしれません。ユーザー補助に初めて取り組む場合は、トピックが広範であるため、どこから手をつければよいかわからなくなるかもしれません。多様な能力に対応できるようにするということは、それに応じて多様な問題を考慮しなければならないことを意味します。
この投稿では、こうした問題を、既存のサイトのユーザー補助機能を審査する論理的で詳細なプロセスに分けて説明します。
キーボードを使用する場合
マウスを使用できない、または使用しないことを選択しているユーザーにとって、画面上のすべてのものにアクセスする主な手段はキーボード ナビゲーションです。これには、反復性ストレス損傷（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 に関する動画をご覧ください。PC をお使いの場合は、NVDA に関するこちらの動画をご覧ください。NVDA は、寄付によってサポートされている Windows 用オープンソース スクリーン リーダーです。
aria-hidden でキーボードのフォーカスが妨げられない
ARIA は要素のセマンティクスにのみ影響し、要素の動作には影響しないことを理解することが重要です。aria-hidden="true" を使用すると、スクリーン リーダーに対して要素を非表示にできますが、その要素のフォーカス動作は変更されません。画面外インタラクティブ コンテンツの場合、画面外インタラクティブ コンテンツの場合は、inert 属性を使用して、キーボード フローから確実に削除されるようにします。古いブラウザの場合は、aria-hidden="true" と tabindex="-1" を組み合わせます。
インタラクティブな要素では、その目的と状態を示す必要がある
コントロールの動作に関する視覚的なヒント、つまりアフォーダンスを提供することで、さまざまなデバイスを使用する多様なユーザーにとって、サイトの操作やナビゲーションに役立ちます。
- リンクやボタンなどのインタラクティブな要素は、非対話型の要素と区別できるようにする必要があります。要素がクリック可能かどうかわからない場合、ユーザーはサイトやアプリのナビゲーションを難しくします。インタラクティブ要素を示すには多くの有効な方法があります。一般的な手法として、リンクに下線を引いて周囲のテキストと区別できます。
- フォーカス要件と同様に、リンクやボタンなどのインタラクティブな要素では、ポインタがクリック可能なものの上に重なったことをマウスユーザーに通知するために、
hover状態が必要です。ただし、これらの要素を他の入力方法からアクセスできるようにするには、hover状態なしで区別できるようにする必要があります。
見出しやランドマークを活用する
見出しとランドマークの要素によってページにセマンティック構造がもたらされ、支援技術ユーザーのナビゲーション効率が大幅に向上します。多くのスクリーン リーダー ユーザーは、見慣れないページにアクセスしたときに、見出しを使って移動しようとすることが多いと報告しています。
同様に、スクリーン リーダーには <main> や <nav> などの重要なランドマークにジャンプする機能もあります。このような理由から、ページの構造をどのようにしてユーザー エクスペリエンスをガイドするかを検討することが重要です。
h1-h6階層を使用します。見出しは、ページの概要を作成するためのツールだと考えてください。組み込みの見出しスタイルに依存しないでください。代わりに、それらがすべて同じサイズであるかのように扱い、プライマリ、セカンダリ、ターシャリ コンテンツに意味的に適切なレベルを使用します。CSS を使って見出しをデザインします- ユーザーが繰り返しコンテンツを回避できるように、ランドマークの要素と役割を使用します。多くの支援技術には、
<main>要素や<nav>要素で定義されたものなど、ページの特定の部分に移動するためのショートカットが用意されています。これらの要素には、暗黙的なランドマークの役割があります。<div role="search">のように、ARIArole属性を使用してページ上の領域を明示的に定義することもできます。その他の例については、セマンティクスとコンテンツのナビゲーションをご覧ください。 - 使用経験がない限り、
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 を使用している場合は、失敗したユーザー補助機能テストのレポートがないか探します。エラーを修正すると、サイトの全体的なユーザー エクスペリエンスが向上します。