ウェブサイトやアプリケーションにアクセスできるかどうかの判断は、 大変な作業です。ユーザー補助に初めて取り組む場合、 どこから手を付けたらよいかわからなくなるでしょう。結局のところ、 幅広い能力に対応する取り組みでは、 検討すべき問題も多種多様です
この投稿では、こうした問題を、Google のエンタープライズ向け 既存のサイトのアクセシビリティを審査しています
キーボードで開始
マウスを使用できない、または使用しないユーザーのために、キーボード ナビゲーションは 画面上のあらゆる要素にリーチする主な手段ですこのオーディエンスに該当するのは 反復性ストレスけが（RSI）などの運動機能障がいのあるユーザー スクリーン リーダーを使用するユーザーをサポートします。
優れたキーボード エクスペリエンスを実現するには、論理的なタブオーダーにすることを目標とし、 フォーカス スタイル。
まず、サイト内でタブ移動します。要素がフォーカスされる順序 必要があります。どの要素が受信するかわからない場合は、 フォーカスに関する「ユーザー補助について学ぶ」コースのモジュールをご覧ください。最高の ユーザーが操作または入力できるコントロールは フォーカス可能で、フォーカス インジケーター（フォーカス リングなど）が表示される必要があります。
カスタム インタラクティブ コントロールはフォーカス可能である必要があります。JavaScript を使用して
<div>をプルダウンに入力しても、 タブオーダーですカスタム コントロールをフォーカス可能にするには、tabindex="0"を指定します。tabindexの値が 0 より大きいとタブの順序が変わるため、混乱を招く可能性があります 使用できます。インタラクティブなコンテンツのみをフォーカス可能にする。
tabindexを 見出しなどのインタラクティブな要素を使用すると、 また、スクリーン リーダーのユーザーには役立ちます。これは、 知らせる必要がありますページに新しいコンテンツを追加すると、そのコンテンツにユーザーの注意が向くようになります。 アクションを起こせるようにします詳しくは、 ページ単位でフォーカスを管理する をご覧ください。
サイトを設計する際は、ユーザーが常に次の要素に注目できるようにしましょう。 選択します。予測入力ウィジェットなど、閉じ込められる可能性があるコンテキストに注意 キーボード フォーカス。ユーザーに注意してほしい場合、一時的にフォーカスをトラップできます。 ページの残りの部分は操作できませんが、 キーボードでモーダルをエスケープする方法を提供します。詳しくは、 モーダルとキーボードのトラップ 例です。
フォーカス コントロールを使いやすくする
カスタム コントロールを作成した場合は、コントロールのすべての機能をユーザーが利用できるようにする 使用できます。読む コンポーネントでのフォーカスの管理 キーボード アクセスを改善するための手法を紹介します。
画面外のコンテンツを管理する
多くのサイトには、DOM には存在するが、画面には表示されないオフスクリーン コンテンツがあります。 レスポンシブ ドロワー メニュー内のリンクやモーダル ウィンドウ内のボタンなど、 まだ表示されません。これらの要素を DOM に残しておくと、 特にスクリーン リーダーにとっては、キーボード操作が混乱しがちです。 画面外のコンテンツがページの一部であるかのように読み上げられます。
画面外のコンテンツの処理をご覧ください。 をご覧ください。
スクリーン リーダーを使用してテストする
一般的なキーボードのサポートを改善することは、次のステップに向けた ページの適切なラベル付けとセマンティクス、 スクリーン リーダーのナビゲーションです。
アシストによるセマンティック マークアップの解釈に不慣れな場合は、 コンテンツ構造をご覧ください。
- すべての画像に適切な
altテキストがあるか確認してください。この手法の例外として 画像は主にプレゼンテーション用であり、Google Chat の 説明します。スクリーン リーダーが画像をスキップすることを指定するには、 値を空の文字列alt=""に変更します。 - ラベルのすべてのコントロールのチェックボックスをオンにします。カスタム コントロールの場合、
aria-labelまたはaria-labelledbyの使用。詳しくは、 ARIA ラベルと関係 をご覧ください。 - すべてのカスタム コントロールで、適切な
roleと必要な ARIA を確認します 状態を伝えることができます。たとえば、カスタム チェックボックスを使用するには、role="checkbox"とaria-checked="true|false"を使用して、 あります。一般的な情報については、ARIA の概要をご覧ください。 ARIA がカスタム コントロールの欠落しているセマンティクスを提供する仕組みの概要。 - ページ内での情報の流れを合理的なものにします。なぜなら 読者は DOM 順でページを移動し CSS を使って無意味な順番で視覚的に再配置するといったことが可能になります。機能 これを DOM の早い段階で物理的に移動したい場合、
- ページ上のすべてのコンテンツで、スクリーン リーダーのナビゲーションをサポートすることを目指します。必ず
サイトのセクションが完全に非表示になったり、画面に表示されないようにしたりしていない
できます。
- コンテンツをスクリーン リーダーで非表示にする必要がある場合（たとえば、
プレゼンテーションだけの場合は、そのコンテンツを
aria-hidden="true"に設定します。 詳しくは、 コンテンツの非表示。
- コンテンツをスクリーン リーダーで非表示にする必要がある場合（たとえば、
プレゼンテーションだけの場合は、そのコンテンツを
スクリーン リーダーについての理解を深める
スクリーン リーダーは一見難しそうに見えますが、実は 構築します。一般的に、ほとんどのデベロッパーは、 使用できます。
Mac をお使いの場合は VoiceOver スクリーン リーダーです。パソコンをお使いの場合は、 NVDA に関する動画 寄付によって支えられている Windows 用オープンソース スクリーン リーダーです。
aria-hidden はキーボードのフォーカスを維持しません
ARIA は、データセットのセマンティクスにのみ影響することを理解することが重要です。
element;要素の動作には作用しません。独自の
aria-hidden="true" によりスクリーン リーダーに対して非表示になる要素ですが、
その要素のフォーカス動作を変更できます。画面外のインタラクティブなコンテンツの場合
画面外のインタラクティブなコンテンツの場合は、inert 属性を使用します。
確実にキーボードのフローから
削除されるようにします古いブラウザでは
aria-hidden="true" を tabindex="-1" と組み合わせる。
インタラクティブ要素は、その目的と状態を示す必要がある
コントロールの働きについて視覚的なヒント（アフォーダンス）を提供すると、 さまざまなデバイスで多様なユーザーが サイトをご覧ください。
- リンクやボタンなどのインタラクティブな要素は、 非対話型要素です。ユーザーがサイトやアプリを操作しにくい 要素がクリック可能かどうかを判断できません。多くの有効な方法で インタラクティブな要素を示します。よく使われるのは、 周囲のテキストと区別できるようにします。
- フォーカス要件と同様に、リンクやボタンなどのインタラクティブな要素
ポインタが何か上にあることをマウスユーザーに知らせるために
hover状態を要求する クリック可能にします。ただし、これらの要素を他の入力方法からアクセスできるようにするには、hover状態なしで識別可能である必要があります。
見出しとランドマークを活用する
見出しとランドマーク要素は、ページのセマンティック構造を提供します。 支援技術を利用するユーザーの操作効率が大幅に向上します。多数 スクリーン リーダーのユーザーから、見たことのないページに初めてアクセスしたときに、 攻撃者は、通常、このような 見出し間を移動できます。
同様に、スクリーン リーダーでも重要なランドマークにジャンプできます。
<main>、<nav> など。これらの理由から、
ページの構造に基づいて、ユーザーの利便性を高めることができます。
h1-h6階層を使用します。見出しは、文書の概要を作成するためのツールと できます。組み込みの見出しスタイルに依存しないでください。代わりに すべて同じサイズであるかのように扱って、意味的に適切なレベル 3 次的なコンテンツを作成します次に、CSS を使用して、 見出しがデザインに合っていることを確認します- ランドマークの要素とロールを使用して、ユーザーが繰り返しのコンテンツをバイパスできるようにします。多数
ページの特定部分へのショートカットや
<main>要素や<nav>要素で定義された要素などが該当します。これらの要素は 暗黙的ランドマーク ロール。また、ARIArole属性を使用して以下を行うこともできます。<div role="search">のように、ページの地域を明示的に定義します。詳しくは、 詳しくは、セマンティクスとコンテンツのナビゲーションをご覧ください。 説明します。 - 使用経験がない限り、
role="application"は使用しないでください。applicationランドマーク ロールは、支援技術にその機能を無効にするよう指示します。 ショートカットを作成し、キーが押されたキーをすべて通過してページに到達します。つまり、鍵は ページ内の移動に通常使うスクリーン リーダーが機能しなくなる キーボードの処理をすべて自分で実装する必要があります。
スクリーン リーダーで見出しやランドマークを確認する
VoiceOver や NVDA などのスクリーン リーダーでは、コンテキスト メニューを使用して ページ上の重要な領域ですユーザー補助機能をテストする場合は、 ページの概要を確認し、見出しが 使われているランドマークを確認できます。
詳細については、このモジュールで紹介した VoiceOver および NVDA。
プロセスを自動化する
サイトのアクセシビリティを手動でテストするのは面倒で、間違いが起こりがちです。 次のようにテストを自動化すると、 必要があります。ブラウザ拡張機能とコマンドライン アクセシビリティ テストスイートを使用します。
- そのページは
aXe
または WAVE
ブラウザ拡張機能他のオプションもありますが、これらの拡張機能は
手動テストプロセスに追加すると便利な場合があります。
コントラスト比の不具合や ARIA の欠落といった
属性です。
- コマンドラインで作業したい場合は axe-cli で使用できる機能は同じです。 として使用できるが、ターミナルから実行することもできる
- 特に継続的インテグレーション環境で回帰を回避するには、 axe-core などのライブラリを組み込む テストスイートに投入しますコアとなるエンジンは コマンドラインユーティリティを使用します。
- フレームワークやライブラリを使用している場合、それに独自のユーザー補助機能が用意されているか ツールか？たとえば、 protractor-accessibility-plugin 使用できます可能な限り、利用可能なツールを活用します。
Lighthouse を使用して PWA をテストする
Lighthouse は、 プログレッシブ ウェブアプリ（PWA）のパフォーマンスを測定します。 また、axe-core ライブラリを使用してユーザー補助機能テストを強化しています。
すでに Lighthouse を使用している場合は、ユーザー補助の不具合がないか探してください 追加できますエラーを修正して、全体的なユーザー エクスペリエンスを向上させる できます。