名前 (name) 及び役割 (role) を取得し、利用者が設定可能なプロパティを直接設定可能にし、変化を通知するためにユーザエージェントが動作する、プラットフォームのアクセシビリティ API 機能をサポートするウェブコンテンツ技術を用いて、コンポーネントを作成する

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

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

適用 (対象)

アクセシビリティ API と連動するようにプログラムされた標準のコンポーネントがあるプログラミング技術

これは達成基準 4.1.2: 名前 (name)・役割 (role)・値 (value) (より具体的な手法を用いる十分な達成方法) に関する達成方法である。

解説

この達成方法の目的は、支援技術がウェブコンテンツを理解し、代替のユーザインタフェースを介して、利用者に等価の情報を伝えられるようにすることである。

コンテンツのなかには、マークアップ言語ではなく、プログラミング言語又はツールを用いて制作されているものがある。これらのウェブコンテンツ技術には、多くの場合、あらかじめプログラムされたインタフェースコンポーネントがあって、アクセシビリティ API とのインタフェースとなる。コンテンツ制作者がこれらのコンポーネントを使ってプロパティ (名前 (name) など) を埋めると、その結果として生成されるコンテンツのユーザインタフェースコンポーネントは、支援技術にとってアクセシブルなものとなる。

しかし、コンテンツ制作者が新しいユーザインタフェースコンポーネントを作成したいと考え、標準のコンポーネントを使うことができない場合は、自分でアクセシビリティ機能を確実に追加し、アクセシビリティ API と互換性があるように実装する必要がある。

そういったカスタムコンポーネントでは、完成後、アクセシビリティ サポーテッドの検証を行うべきである。

事例

検証

手順

  1. アクセシブルなユーザエージェントを用いてコンテンツをレンダリングする。
  2. 各ユーザインタフェースコンポーネントを検証するために、ユーザエージェントのアクセシビリティ API 用に設計されたアクセシビリティツールを使用する。
  3. 各ユーザインタフェースコンポーネントに対する名前 (name) 及び役割 (role) が、ツールによって検出されることを確認する。
  4. コンポーネントの値を変更する。
  5. アクセシビリティツールにその変更が通知されることを確認する。
  6. コンポーネントが支援技術で動作することを確認する。

期待される結果

  • 各ユーザインタフェースコンポーネントに対して、#3、#5 及び #6 の結果が真である。