このページの内容:

プログラムが解釈可能な識別名・役割及び設定可能な値:
達成基準 4.1.2 を理解する

4.1.2 プログラムが解釈可能な識別名・役割及び設定可能な値: すべてのユーザインタフェース・コンポーネント（フォーム、リンク、そしてスクリプトが生成するコンポーネントなどを含む）では、識別名及び役割は、プログラムが解釈可能である。また、利用者が設定可能なステータス、プロパティ、そして値はプログラムが設定可能である。そして、支援技術を含むユーザエージェントがこれらの項目が変更された通知を受け取ることができる。 (レベルA)
注記： この達成基準は、主に独自のユーザインタフェース要素を開発したりスクリプトを書いたりするコンテンツ制作者に向けたものである。例えば、標準的な HTML のコントロールは、仕様に準じていればそれで既にこの達成基準を満たしていることになる。

この達成基準の意図

この達成基準の意図は、支援技術がコンテンツにあるユーザーインタフェース・コントロールのステータスに関する情報を収集する、選択された状態にする（又は設定する）、そして常に最新の状態を把握できるようにすることである。

アクセシブルなウェブコンテンツ技術の標準的なコントロールを使用している際は、このプロセスはごく簡単である。ユーザーインタフェース要素を仕様に準じて使用していれば、この達成基準には適合したことになる（以下にある、達成基準 4.1.2 の事例を参照のこと）

しかし、独自のコントロールを作成する場合、又はインタフェース要素に通常とは異なる役割、及び/又は機能を持たせるように（ソースコード又はスクリプト内に）プログラムする場合には、コントロールが重要な情報を支援技術へ提供し、支援技術がそのコントロールを制御できるようにする手段を追加する必要がある。

ユーザーインタフェース・コントロールの特に重要なステータスは、フォーカスがあるかどうかである。コントロールにフォーカスがあるステータスは、プログラムで判断することが可能であり、フォーカスの変化に関する通知がユーザーエージェント及び支援技術に送られる。ユーザーインタフェース・コントロールのステータスのその他の例としては、チェックボックス又はラジオボタンが選択されているかどうか、又は折り畳み可能なツリーあるいはリストが展開されているか折り畳まれているか、というのが挙げられる。

注記： 達成基準 4.1.2 は、すべてのユーザーインタフェース・コンポーネントに対して、プログラムで判断可能な識別名を要求している。識別名は、視覚的に認識できたり、できなかったりする。識別名が視覚的に認識できなければならないときがある。それは、識別名がラベルの役割も果たすような場合である。より詳しい情報については、用語集にある識別名及びラベルの定義を参照のこと。

達成基準 4.1.2 の具体的なメリット

すべてのユーザーインタフェース・コンポーネントに、役割、ステータス、及び値の情報を持たせることによって、例えば、スクリーンリーダー、画面拡大ソフト、及び音声認識ソフトウェアなどのように、障害のある利用者が使用している支援技術との互換性を保つことができるようになる。

達成基準4.1.2 の事例

アクセシブル API
Java アプレットは、その言語で定義されたアクセシビリティ API を用いている。IBM Guidelines for Writing Accessible Applications Using 100% Pure Java を参照のこと。

達成基準4.1.2 の実装方法及び不適合事例 - プログラムが解釈可能な識別名・役割及び設定可能な値

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされている場合にのみ、次に挙げる実装方法により、この達成基準を満たすことができる。

達成基準を満たすことのできる実装方法

使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の実装方法（又は、実装方法の組合せ）がある。

状況 A：マークアップ言語（例： HTML）で標準的なユーザーインタフェース・コンポーネントを使用している場合：

以下に挙げる技術特有の方法でG108: マークアップを用いて、名前及び役割をUAに提供し、利用者が設定可能なプロパティを直接設定可能にし、変化を通知する:

状況 B：スクリプト又はコードを用いて、マークアップ言語の標準的なユーザーインタフェース・コンポーネント再定義する場合：

以下のいずれかの方法を用いて、名前及び役割をユーザーエージェントに提供し、利用者が設定可能なプロパティを直接設定可能にし、変化を通知する:
- SCR21: DOM（ドキュメント・オブジェクト・モデル）を用いて、ページにコンテンツを追加する (Scripting)

状況 C：プログラミング技術で標準的なユーザーインタフェース・コンポーネントを用いる場合：

G135: ウェブコンテンツ技術のアクセシビリティAPIを用いて、名前及び役割をUAに提供し、利用者が設定可能なプロパティを直接設定可能にし、変化を通知する

状況 D：プログラミング言語で独自のインタフェース・コンポーネントを作成する場合：

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

達成基準 4.1.2 でさらに対応が望まれる実装方法（参考）

適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能、または効果的であるとは限らない。

暗黙のラベルを持たないすべてのフォーム・コントロールにラベルを付加する（リンク追加予定）

達成基準 4.1.2 のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準 4.1.2 に適合していないとみなした、よくある不適合事例である。

重要な用語

プログラムが解釈（プログラムが解釈可能）

コンテンツ制作者が提供したデータからソフトウェアが解釈できること。またそのときに、支援技術を含む様々なユーザエージェントが、この情報を抽出して利用者に様々な感覚モダリティで提示できること。

事例 1： マークアップ言語では、一般に入手可能な支援技術が、要素および属性に直接アクセスすることにより解釈できる。

事例 2： 非マークアップ言語では、ウェブコンテンツ技術特有のデータ構造から、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。

プログラムが設定

支援技術を含むユーザエージェントがサポートしている手法を用いてソフトウェアが設定する。

ユーザインターフェース・コンポーネント

特定の機能を果たすための単一のコントロールとして利用者が知覚する、コンテンツの一部分。

注記 1： 複数のユーザインターフェース・コンポーネントが、単一のプログラムで実装されることがある。ここでいうコンポーネントは、プログラムに関するものではなく、別々のコントロールとして利用者が知覚するものを指す。

注記 2： ユーザインターフェース・コンポーネントには、スクリプトで生成されるコンポーネントやフォーム要素、リンクが含まれる。

事例： アプレットには、コンテンツ内を行ごと、ウェブページごと、又はランダム・アクセスを行うために用いられる「コントロール」がある。これらには、いずれも識別名を割り当て、個別に設定できるようにする必要があるため、それぞれが「ユーザインターフェース・コンポーネント」となる。

ユーザエージェント

ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。

事例： ウェブブラウザ、メディアプレーヤ、プラグイン、及びその他のプログラム。その他のプログラムには、ウェブコンテンの取得、レンダリング、利用（インタラクション）を支援する支援技術を含む。

役割

ウェブコンテンツに含まれるコンポーネントの機能を、ソフトウェアが識別するために用いることができるテキスト又は数字。

事例： 画像が、ハイパーリンク、コマンドボタン、又はチェックボックスのどれなのかを示している数字。

識別名

ソフトウェアがこれを用いて、ウェブコンテンツのコンポーネントを利用者に識別させることができるテキスト

注記 1： 識別名は隠されていて、支援技術に対してだけ明らかにされる場合もあるが、ラベルはすべての利用者に提示される。多くの場合（すべてではないが）、ラベルと識別名は同じである。

注記 2： これは、HTML の name 属性とは関係がない。

（この文書で用いられている）支援技術

ユーザエージェントとして機能する、又は主流のユーザエージェントと一緒に機能するハードウェア及び/あるいはソフトウェアで、主流のユーザエージェントで提供されている機能以上の機能を、障害のある利用者の要求を満たすために提供するもの。

注記 1： 支援技術が提供する機能としては、代替のプレゼンテーション（例：合成音声や拡大表示したコンテンツ）、代替入力手法（例：音声認識）、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換（例：テーブルをよりアクセシブルにするもの）などを挙げることができる。

注記 2： 支援技術は、API を用いて監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。

注記 3： 主流のユーザエージェントと支援技術とを区別するのに、絶対的な基準などはない。多くの主流のユーザエージェントは、障害者を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者のニーズにより特化した適切なものである。主流のユーザエージェントは、プログラムのオブジェクトからウェブコンテンツを取り出したり、マークアップを識別可能な構造に解釈したりするような、重要な機能を支援技術に対して提供する場合がある。

事例： この文書の文脈において重要な支援技術としては、以下のものが挙げられる：

画面拡大ソフトおよびその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、および読書困難などの障害のある人が、レンダリング後のテキストおよび画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
音声変換ソフトウェア。認知障害、言語障害、および学習障害のある人が、テキストを合成音声に変換するために使用している。
音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
代替キーボード。特定の身体障害のある人がキーボードを擬似操作するのに使用している（ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、およびその他の特別な入力デバイスを使った代替キーボードを含む）。
代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンを擬似操作するのに使用している。

プログラムが解釈可能な識別名・役割及び設定可能な値:達成基準 4.1.2 を理解する