達成基準 4.1.2 の失敗例 - プログラムによる解釈が可能ではない、又は変更の通知が利用可能ではないようなユーザインタフェース コンポーネントのフォーカス状態

達成方法に関する重要な情報

この達成方法 (参考) の使用法と、この達成方法が WCAG 2.1 達成基準 (規定) とどのように関係するのかに関する重要な情報については、WCAG 達成基準の達成方法を理解するを参照のこと。適用 (対象) のセクションは、その達成方法の範囲について説明しており、特定の技術に関する達成方法の存在は、その技術があらゆる状況で WCAG 2.1 を満たすコンテンツを作成するために使用できることを意味するものではない。

適用 (対象)

全てのウェブコンテンツ技術

これは達成基準 4.1.2: 名前 (name)・役割 (role)・値 (value) (失敗例) に関する達成方法である。

解説

あるユーザインタフェースコンポーネントにフォーカスがあるかどうかは、そのコンポーネントの状態 (state) の特に重要な一面である。多くの種類の支援技術が、キーボードフォーカスの現在位置を追跡することに依存している。スクリーンリーダーは、利用者の注視点をフォーカスの当たっているユーザインタフェースコンポーネントに移動させ、画面拡大ソフトはフォーカスが当たっているコンポーネントを見ることができるようにコンテンツの表示を変えていく。新しいコンポーネントにフォーカスが遷移した時に、支援技術に通知されなければ、利用者は意図と異なるコンポーネントとやりとりをしようとして混乱することになる。

通常ユーザエージェントが標準的なコンポーネントに対してこの機能で処理を行う一方、スクリプトで独自に記述されたユーザインタフェースコンポーネントは、アクセシビリティ API を用いてユーザエージェントがフォーカスについての情報及び通知を利用できるようにしなければならない。

事例

カスタムメニューがメニュー項目を明確に描画して表示している。マウス及びキーイベントを直接制御し、現在選択されているメニュー項目は反転表示となっている。プログラマーがフォーカスを持ったメニュー項目をアクセシビリティ API 経由で引き渡さないようにしたため、支援技術は、フォーカスがメニューの中のどこかにあることまでしか分からず、どのメニュー項目にフォーカスが当たっているのか決定できない。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. ウェブコンテンツ技術に対してアクセシビリティチェッカーを用い (又は、利用できない場合は、コードを検査する、又は支援技術で検証する)、コントロールがアクセシビリティ API を経由してフォーカスの状態 (state) を公開しているかどうかを確認する。
  2. ウェブコンテンツ技術に対してアクセシビリティチェッカーを用い (又は、利用できない場合は、コードを検査する、又は支援技術で検証する)、フォーカスがあるコントロールから別のコントロールに遷移したとき、支援技術に通知されるかどうかを確認する。

期待される結果

  • 1. 又は 2. の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。