アクセシブル・リッチ・インターネット・アプリケーション（WAI-ARIA）1.0

1.1. スコープ

この仕様の目的としては、以下の点が挙げられる。

• 開発者が制御できる情報を定義すること。
• 電話、PDA、テレビといった新しい機器において、機器に依存しない状況をサポートすること。
• スクリプトによって生成される動的なコンテンツのアクセシビリティを向上すること。
• 支援技術との相互運用性を実現すること。

このドラフトでは、現在、ロール（role）の2つの側面を取り上げている。ユーザーインターフェースの機能と構造的な関係だ。インタラクティブコンテンツをアクセシブルにするためのロール（role）の使用方法については、WAI-ARIA入門書 [ARIA-PRIMER] を参照してほしい。

ロール（role）タクソノミーの目的の1つは、プラットフォームのアクセシビリティAPIで一般的に使われるロール（role）をサポートすることにある。動的なウェブコンテンツがこのタクソノミー内のロール（role）を参照することによって、支援技術との相互運用性をサポートすることができる。

この標準をサポートするスキーマは拡張可能なように作られており、基本のロール（role）を拡張することによって、カスタムロールが作成できるようになっている。この結果、ユーザーエージェントは、少なくとも基本のロール（role）をサポートし、さらにカスタムロールをサポートするユーザーエージェントは、高いレベルのアクセシビリティを実現できるようになる。これらのほとんどは、XMLスキーマ [XSD] で正式化できるだろう。しかし、baseConceptsとより記述的な定義のように、ロール（role）間の類似性を定義する機能は、XSDでは利用できない。この拡張性は可能ではあるが、この仕様の現在のバージョンでは、この拡張の達成方法を定義していない。

WAI-ARIAは、一連の情報リソースによってサポートされている。WAI-ARIAのためのロードマップ [ARIA-ROADMAP] のほかに、WAI-ARIA入門書 [ARIA-PRIMER] では、ARIAの背景にある概念や理由についての基本的な説明を提供し、またWAI-ARIAベストプラクティス [ARIA-PRACTICES] では、ウェブコンテンツ開発者向けの推奨使用パターンを説明している。さらに、WAI-ARIAユーザーエージェント実装ガイド [ARIA-IMPLEMENTATION] では、ユーザーエージェントがどのようにしてARIAの機能をプラットフォームのアクセシビリティAPIに開示すべきかを説明している。これらの文書は、WAI-ARIAの実践的なプラクティスを学びたいと考えている開発者のために作られている。

1.2. 使用事例

キーボードで操作可能なコンテンツは、代替入力機器を使っている人にとって有益だ。この新しいセマンティクスを、WAI-ARIAベストプラクティス [ARIA-PRACTICES] で提供されている推奨キーボードインタラクションと併せて使うことにより、代替入力ソリューションを介したコマンドやコントロールの使い勝手を向上することができる。

ARIAでは、タクソノミーとXHTMLロール（role）ランドマークの両方を通じたナビゲーションランドマークを導入する。これにより、キーボードナビゲーションが向上し、巧緻性や視覚に障害のある人に役立つだろう。ARIAはまた、認知障がい、学習障がいのある人の支援にも使える。セマンティクスを付加することによって、開発者は、必要に応じて代替コンテンツを再構成および代用できるようになる。

支援技術は、ウィジェットの現在の値を取得し設定することによって、代替入力をサポートする必要がある。支援技術はまた、どのオブジェクトが選択されているかを判断し、リストボックスやグリッドのように複数選択を許可するウィジェットを管理する必要がある。

ARIAは、ネイティブ言語のセマンティクスに取って代わるものではなく、補足するものとして使うことを意図している。ホスト言語がARIAの機能に相当する機能を提供している場合は、ホスト言語の機能を使用し、ARIAは、ホスト言語に必要なロール（role）、ステート（state）、またはプロパティの指示がない場合のみ使用すべきである。まず、ARIAの機能にできるだけ近いホスト言語の機能を使用し、その後でARIAを追加してその意味を細かく指定する。例えば、複数選択が可能なグリッドは、テーブルとして実装し、その後でARIAを使って、これが単なるテーブルではなくグリッドであることを明確にする。これにより、ユーザーエージェントがARIAをサポートしていない場合でも、可能なかぎり最善の道を用意し、同時にホスト言語のセマンティクスの完全性を維持できるようになる。

2.1. WAI-ARIAのロール（role）

ARIAのロール（role）は、XHTMLRole属性モジュール [XHTML-ROLES] で定義されているrole属性に似たrole属性を使って、要素に設定される。

<li role="menuitem">Open file…</li>

この仕様で定義されているロール（role）には、一連の文書ランドマークとARIAのロール（role）タクソノミーが含まれている。

このタクソノミー内のロール（role）は、各ロール（role）に期待される動作を文書化するためにRDF/OWL [OWL] を用いてモデル化されている。ロール（role）タクソノミーの機能は、各ロール（role）について、次の情報を提供している。

• そのロール（role）についての説明
• 関連するロール（role）についての階層情報（例えば、directoryはlistの1タイプである）
• ロール（role）の文脈（例えば、listitemはlist内に置かれるべきである）
• 他の仕様で説明されている関連する概念の参照
• セマンティクスの継承を可能にする階層構造（クラスの階層構造に似ている）のタイプを提供するためのOWLの使用
• 各ロール（role）について、サポートされたステート（state）とプロパティ（例えば、checkboxはaria-checked属性を介してチェックされた状態をサポートする）

ロール（role）を付けることによって、支援技術は、各要素をどのように処理すべきかについての情報が得られるようになる。

2.2. WAI-ARIAのステート（state）とプロパティ

ARIAでは、様々なOSプラットフォーム上のプラットフォームのアクセシビリティAPIをサポートするのに使われる、アクセシビリティのステート（state）とプロパティの一式を提供している。支援技術は、開示されたユーザーエージェントのDOMを介して、あるいはプラットフォームのアクセシビリティAPIへのマッピングを介して、この情報にアクセスできる。これをロール（role）と合わせることによって、ユーザーエージェントは、どのようなインスタンスにおいてもタイミング良くユーザーに対して情報をレンダリングするための情報を、支援技術に提供できるようになる。そして、ステート（state）またはプロパティに変化があれば、支援技術に通知し、これを受けて支援技術は、変更をユーザーに通知することができる。

以下の例では、チェック可能なメニュー項目を作るのにリスト項目（html:li）が使われていて、JavaScriptのイベントがマウスとキーボードのイベントをとらえることにより、aria-checkedの値が切り替わるようになっている。また、この単純なウィジェットの動作をユーザーエージェントに知らせるために、ロール（role）が使われている。ユーザーアクションを受けて変わる属性（aria-checkedなど）については、ステート（state）とプロパティのセクションで定義する。

<li role="menuitemcheckbox" aria-checked="true">Sort by Last Modified</li>

アクセシビリティのステート（state）のなかには、ユーザーエージェントによって制御されるものもあり、これらは管理されたステート（state）と呼ばれている。管理されたステート（state）の例としては、キーボードフォーカスと選択がある。多くの場合、管理されたステート（state）は、対応するCSSの擬似クラス（:focusや::selectionなど）があって、これが表示スタイルの変更を定義している。反対に、この仕様で説明されるステート（state）は、一般に開発者によって制御されていて、管理されていないステート（state）と呼ばれている。ステート（state）のなかには、ユーザーエージェントによって管理されているが、開発者が上書きできるものもある。例えば、aria-posinsetやaria-setsizeがこれに該当する。開発者は、DOMが完全でなく、ユーザーエージェントの計算が不正確になる場合のみ、これらのステート（state）を上書きすべきである。管理されたステート（state）も管理されていないステート（state）も、ユーザーエージェントによって、プラットフォームのアクセシビリティAPIにマッピングされる。

最近のユーザーエージェントのほとんどは、CSS属性セレクタ（[CSS] 、セクション5.8）をサポートしていて、ARIAの属性情報に基づいたUIの変更を開発者が作成することで、等価な機能を作るのに必要となるスクリプトの量を減らしている。以下の例では、aria-checked属性の値に基づいたCSSセレクタを用いて、チェックマークの画像が表示されているのかどうかを示している。

[aria-checked="true"]:before { background-image: url(checked.gif); }

注：この文書の執筆時点で、このCSSの例は、技術的には正しいものの、一部のブラウザでは、属性の値が動的に変更されると、表示スタイルが適切に変更されない。クラス名をトグルで切り替えるか、さもなければブラウザに適切な表示スタイル変更を強制する必要があるかもしれない。

2.3. フォーカスの管理

application（role）は、その使用中には、フォーカスの置かれた要素を常に持っているべきだ。アプリケーションでは、ユーザ入力を提供する場所をユーザが保持している必要があるからである。そして、このフォーカスが置かれた要素は、破壊されたり隠されたり、スクリーン外にスクロールすべきではない。また、あらゆるインタラクティブ要素は、フォーカス可能になっているべきである。キーボードを使っているユーザーのために、見つけやすい明らかな方法、例えばタブ送り（Tabキー操作）やその他の標準的なナビゲーション方法を提供して、インタラクティブな要素すべてに移動できるようにする必要がある。詳しくは、ユーザーエージェント・アクセシビリティ・ガイドラインのガイドライン9（[UAAG] 、ガイドライン9）で参照できる。

アプリケーション開発者は、標準的な（X）HTMLと基本的なWAI-ARIAのウィジェットを使って、単純にタブ順序（Tabキーでフォーカスが移動する順序）を制御するか、文書内の要素に対してキーボードショートカットを作成するためのスクリプトを使用することができる。より複雑なウィジェットを使うには、開発者がそのウィジェット内でフォーカスを管理する必要がある。

WAI-ARIAには、多数の「管理コンテナ」ウィジェット（「コンポジット」ウィジェットとして知られていることもある）が含まれている。一般にコンテナとは、アクティブとされていた最後の子孫（デフォルトではたいていがコンテナ内の最初の項目となっている）を把握する責任を負うものである。以前にフォーカスの置かれていたコンテナに再びフォーカスが置かれる場合は、新しくアクティブになる子孫が、最後にそのコンテナにフォーカスが置かれていた時にアクティブだった子孫と同じ要素であるべきだ。例えば、ユーザーがTabキーを使ってツリーグループから外に出た時点で、そのツリーグループの2つ目の項目がアクティブだったのであれば、このツリーグループに再びフォーカスが置かれる際は、この2つ目の項目がアクティブな子孫となる。また、ユーザーが、コンテナ内の子孫のいずれかをクリックすることによって、そのコンテナをアクティブとすることもできる。

コンテナ内の何かにフォーカスが置かれていれば、ユーザーは、矢印キーなどの付加的なキーを押すことでコンテナをナビゲートして、現在の項目から相対的に移動できる。メインのナビゲーションキー（一般にはTabキー）をさらに押せば、コンテナの外に出て、次のウィジェットへと移動できるだろう。

例えば、gridを用いたスプレッドシートに数千というgridcell要素が含まれていて、ただしそれら全部が一度には見えないようになっているとしよう。この場合、フォーカスは、管理コンテナ要素上のaria-activedescendant属性を使ったコンテナによって管理するか、その子要素のtabindexを管理して適切な子にフォーカスを置いているコンテナによって管理しなければならなくなる。詳しくは、WAI-ARIAベストプラクティスの「キーボードフォーカスの提供」（[ARIA-PRACTICES] 、セクション3.2）を参照してほしい。

この方法でフォーカスを管理するコンテナには、以下のものがある。

• combobox
• grid
• listbox
• menu
• menubar
• tree
• treegrid
• tablist
• toolbar

フォーカスの管理についての詳しい情報は、WAI-ARIAベストプラクティス [ARIA-PRACTICES] の「ウィジェット間のフォーカス管理のためのtabindexの使用」のセクションを参照してほしい。

2.4. WAI-ARIAを使ったアクセシブルなアプリケーションの構築

このセクションでは、ARIAを使ってアプリケーションをアクセシブルにする方法について、その導入部分を簡単に説明する。ロール（role）をどのように選び、使用するかは、複雑で、文脈によっても異なる可能性がある。可能性のあるARIAの使用事例すべてについて実装方法を説明するのは、この文書のスコープを超えているが、ARIAベストプラクティス [ARIA-PRACTICES] では、ARIAの実装方法に関する詳細な手引き、およびサンプルコードのリファレンスを提供している。

アプリケーションをアクセシブルにする最初のステップは次の通りである。

1. 要素またはウィジェットのそれぞれに正しい完全なセマンティクスがあり、そのセマンティクスが（要素名とロール（role）を使用して）動作を十分に記述している。
2. 要素とグループの間の関係が定義されている。
3. ステート（state)、プロパティ、コンテナの関係が各要素の動作に対して有効で、かつ文書オブジェクトモデル [DOM] とプラットフォームのアクセシビリティAPIを介してアクセスできるようになっている。
4. キーボードフォーカスは、ユーザーがアプリケーションを閲覧・操作している間中、保持されるべきである。
5. すべてのインタラクティブなコンポーネントが、キーボードで操作可能であるべきである。

ARIAでは、ウェブアプリケーションの様々な要素をセマンティクス的にリッチにする方法を、開発者に提供している。ユーザーエージェントは、ロール（role）のセマンティクスを使って、各要素をどのように扱うべきかを理解する。支援技術がアプリケーション内の要素の動作を予期するにあたって必要とする付加情報、例えば、対応するARIAのステート（state）とプロパティをどのようにユーザーに提示するかといった情報を、ロール（role）は提供する。ユーザーエージェントは、ホスト言語からのアクセシビリティ・セマンティクスとARIAのアクセシビリティ・セマンティクスを使用して（後者が前者を補足または上書きすることがある）、文書オブジェクトモデルまたはプラットフォームのアクセシビリティAPIを介して支援技術にセマンティクスを提供する。ユーザーエージェントは、ウェブページ内の各要素をアクセシブルな方法で提示し、それらの要素のセマンティクスが変更されれば、適切なアクセシビリティAPIを使って、支援技術にそれを伝える。

以下のステップは、コンテンツに対してARIAを適用する際に推奨されるステップである。

1. 可能なかぎりネイティブのマークアップを使用する

   ホストマークアップ言語で定義されたセマンティクス要素を使用する。例えば、HTMLまたはXHTMLでは、checkboxのロール（role）が付いたdiv要素を使うよりも、ネイティブのチェックボックスを使うほうが好ましい。これらがすでに、ブラウザを介してアクセシブルになっていると予想できるためだ。また、ホスト言語にすでに存在する要素をARIAが補足できるケースもあるかもしれない。例えば、gridとgridcellの要素は、テーブルにかかっていれば、その機能を再使用できる。ARIAのロール（role）、ステート（state）、およびプロパティは、マークアップ言語が必要なすべてのセマンティクスをサポートしていない場合にのみ使うのがベストだ。role属性が要素に追加されると、その要素のセマンティクスと動作は、roleの動作によって上書きされる。

2. 適切なロール（role）を適用する

   予期可能なように要素が動作し、要素の動作がネイティブのマークアップ言語で完全に記述されていなければ、各要素のアプリケーション内での動作を正確に記述するように、ロール（role）を設定する。インタラクティブな要素のロール（role）は、その要素が使う可能性のある属性をすべてサポートしているべきである。一度設定したrole属性は、変更すべきではない。role属性を変更すれば、エンドユーザーを混乱させる可能性があるためだ。これには、role属性が設定されている要素を削除することも含まれる。要素においては、ステート（state）とプロパティ（「aria-*」の属性）のみが変更されるべきである。

3. セマンティクスの構造を守る

   構造情報は、障がいのある人に文脈を提供するうえで非常に重要である。構造要素内およびウィジェット内ではDOMの階層構造を守り、ユーザインターフェースウィジェット内ではgroup内のtreeitem要素のような論理グループを形成する。具体的には、ページ内のグループを見つけたうえで、その利用目的を最も的確に記述するロール（role）を使って、そのグループをマークする。例えば、Ajaxアプリケーションを介して変更される可能性が高い要素のグループを含んだページのリージョンは、aria-live属性を使用してライブリージョンと指定することができる。また、文書ランドマークを使用して、キーボードナビゲーションを容易にする。フルキーボードアクセスと文書セマンティクスを提供すれば、視覚や巧緻性に障がいのあるユーザー、さらには認知障がい、学習障がいのあるユーザーも含み、すべての人に役立つ。

4. 関係を構築する

   要素間の関係を見極めたうえで、最も適切なプロパティまたは属性を使って、その要素をマークする。例えば、あるページに検索フォームと検索結果のリージョンが両方含まれていれば、各コンテナをregionとマークしたうえで、検索フォームが検索結果を参照するように、検索フォームのaria-controls属性を設定する。詳しくは、WAI-ARIAの「関係」のセクションを参照してほしい。

   関係のなかには、ホスト言語から自動的に決定されるものもある。例えば、HTMLのinput要素に関連付けられたlabel要素がこれに該当する。

5. イベントへの応答としてプロパティを設定する

   要素のロール（role）を設定後、その要素のライフサイクル中の変化に適切なように、ステート（state）とプロパティを変化させる。これは通常、ユーザーの入力イベントへの応答として行われる。選択したロール（role）または要素にサポートされている属性だけを使用しなければならない。

   ステート（state）に変化があれば、ユーザーエージェントが支援技術に通知すべきである。一方、支援技術によるプロパティ変更の通知は、支援技術がユーザーエージェントと通信するのに使う方法によって異なってくる。例えば、aria-multiline属性（プロパティ）は頻繁に変わるものではないが、aria-checked属性（ステート（state））はユーザー入力への応答として頻繁に変更される。

6. 使いやすい完全なキーボードナビゲーションをサポートする

   リッチ・インターネット・アプリケーションにおける使いやすいキーボードナビゲーションとは、静的な文書をタブ送り（Tabキー操作）でナビゲートすることとは異なる。リッチ・インターネット・アプリケーションは、むしろデスクトップ・アプリケーションに似た動作をし、ユーザーは、大きなウィジェットを選ぶのにTabキーを使い、メニューやスプレッドシートなど、複雑なウィジェット内をナビゲートするのには矢印キーを使う。ARIAがキーボードナビゲーションに導入する変更によって、この高度なアクセシビリティが可能となる。文書内でTabキーが押された場合は、論理ナビゲーション構造に従うべきである。矢印キーのナビゲーションを実装する開発者は、可能なかぎり、WAI-ARIAベストプラクティス [ARIA-PRACTICES] で説明されている設計パターンに従うべきである。これらの機能を使う際は、常にキーボードナビゲーションが論理的になっていることを確認することが重要である。

7. 視覚的なインタフェースとアクセシブルなインタフェースを同期化する

   これにより、ユーザーと支援技術にとってUIのステート（state）が知覚可能となる。例えば、開発者は、フォーム要素が必須となっている（aria-requiredを使用する）場合や、グリッドセルが選択されている（aria-selectedを使用する）場合に応答する関連セレクタを持っているべきである。開発者は、これらのインタフェース要素の視覚的な同期化を達成するために、スクリプトまたはCSS属性セレクタを使うことができる。文書のアクセシブルなステート（state）にUIを同期化する適切な方法については、WAI-ARIAベストプラクティス [ARIA-PRACTICES] を参照してほしい。

2.5. 事例：ツリーウィジェットの構築

基本的なツリービューでは、ユーザーが様々なリスト項目から選択したり、子ノードのあるリストの展開と折り畳みを行ったりすることができる。ツリーのナビゲーションには矢印キーが使われ、左矢印と右矢印を使えばサブツリーの折り畳みと展開が操作できる。また、マウスでダブルクリックしても、展開のトグル変更が可能だ。

この機能をアクセシブルにするためには、次のことをする必要である。

• 各要素のロール（role）を支援技術に知らせる。
• ツリー項目間の関係を支援技術に知らせる。
• 障がいのあるユーザーを混乱させないよう、明確にキーボードのフォーカスを提示する。
• 変化するツリー項目のステート（state）（展開されている、折り畳まれている）を開示する。

その手順は次の通りである。

1. ネイティブマークアップ言語を見る

   標準的なリストのふるまいは、HTMLにネイティブのul要素およびli要素でサポートされているが、リストの展開や選択をサポートするネイティブの要素はない。このため、ロール（role）を使う必要がある。

2. 正しいロール（role）を見つける

   HTMLにはネイティブのツリー要素がないため、このタクソノミーから必要なステート（state）とプロパティをサポートするロール（role）を追加する必要がある。ツリー動作をサポートするロール（role）には、以下のものがある。

   • tree：ツリーは、WAIが提唱するツリーを作る主なコンテナ要素である。これはselectの一種で、ツリー項目のサブレベルグループの折り畳みと展開ができる。
   • treeitem：ツリー項目は、ツリーのオプション項目である。これはツリー内の要素で、ツリー項目のサブレベルグループの折り畳みと展開ができる。
   • group：グループは、サブレベルのツリー項目のセットを囲い込む。

3. グループを見つけ、関係を構築する

   ツリーの関係は、DOMとページの論理構造だけで作ることができる。ツリー要素は、ツリー内の他のすべての要素にかかる主なコンテナとなり、選択できるツリー内の項目は、それぞれがツリー項目となる。

   ツリー項目に子ノードのあるリストが含まれる場合は、それらがすべて1つのグループとして組み込まれる。グループは、そのツリー項目内に置かれ、ツリー項目が親項目となる。

   <h1 id="treelabel">ARIA Tree Example</h1>
   <ul role="tree" aria-labelledby="treelabel" aria-activedescendant="example_id" tabindex="0">
     <li role="treeitem" aria-expanded="true">Animals
       <ul role="group">
         <li role="treeitem">Birds</li>
         <li role="treeitem" aria-expanded="false">Cats
           <ul role="group">
             <li role="treeitem">Siamese</li>
             <li role="treeitem">Tabby</li>
           </ul>
         </li>
         <li role="treeitem" aria-expanded="true">Dogs
           <ul role="group">
             <li role="treeitem" aria-expanded="true">Small Breeds
               <ul role="group">
                 <li role="treeitem">Chihuahua</li>
                 <li role="treeitem" id="example_id">Italian Greyhound</li>
                 <li role="treeitem">Japanese Chin</li>
               </ul>
             </li>
             <li role="treeitem" aria-expanded="false">Medium Breeds
               <ul role="group">
                 <li role="treeitem">Beagle</li>
                 <li role="treeitem">Cocker Spaniel</li>
                 <li role="treeitem">Pit Bull</li>
               </ul>
             </li>
             <li role="treeitem" aria-expanded="false">Large Breeds
               <ul role="group">
                 <li role="treeitem">Afghan</li>
                 <li role="treeitem">Great Dane</li>
                 <li role="treeitem">Mastiff</li>
               </ul>
             </li>
           </ul>
         </li>
       </ul>
     </li>
     <li role="treeitem" aria-expanded="true">Minerals
       <ul role="group">
         <li role="treeitem">Zinc</li>
         <li role="treeitem" aria-expanded="false">Gold
           <ul role="group">
             <li role="treeitem">Yellow Gold</li>
             <li role="treeitem">White Gold</li>
           </ul>
         </li>
         <li role="treeitem">Silver</li>
       </ul>
     </li>
     <li role="treeitem" aria-expanded="true">Vegetables
       <ul role="group">
         <li role="treeitem">Carrot</li>
         <li role="treeitem">Tomato</li>
         <li role="treeitem">Lettuce</li>
       </ul>
     </li>
   </ul>

   aria-expandedの使用は、画面上で展開表示されているものと合致すべきである。このため、開発者は、CSS属性セレクタを使い、ARIAのステート（state）またはプロパティの値に基づいて、項目の展開表示や表示スタイルを切り替えたいと考えることがあるかもしれない。以下の例では、折り畳まれたツリーノードのサブレベルグループは、非表示となる。

   [aria-expanded="false"] [role="group"] { display: none; }

   注：この文書の執筆時点で、このCSSの例は、技術的には正しいものの、一部のブラウザでは、属性の値が動的に変更されると、表示スタイルが適切に変更されない。クラス名をトグルで切り替えるか、さもなければブラウザに適切な表示スタイル変更を強制する必要があるかもしれない。

   ツリー構造は、DOMおよびページの論理構造で明示されていないこともある。その場合は、ステート（state）とプロパティを使って関係を明示しなければならない。以下の例では、「external_listitem」のidを持ったdivが、DOMでは子とされていないにもかかわらず、このプロパティを持ったul要素の子と見なされなければならないことを、aria-owns属性が示している。

   <h3 id="header">Vegetables</h3>
   <ul role="list" aria-labelledby="header" aria-owns="external_listitem">
     <li role="listitem">Carrot</li>
     <li role="listitem">Tomato</li>
     <li role="listitem">Lettuce</li>
   </ul>
   …
   <div role="listitem" id="external_listitem">Asparagus</div>

   DOM内でツリーが常時完全に表現されていない場合は、構造化の手法もaria-ownsの手法も使うべきではない。代わりに、aria-level、aria-posinset、aria-setsizeを使用する。

4. イベントへの応答としてプロパティを設定する

   キーボードやマウスを介したユーザー入力イベントに対する応答として、要素の動作を制御する。例えば、ツリーコントロールは、展開と折り畳みのトリガ上のクリックイベントに対して、および現在アクティブとなっている子孫上のキーイベントに対して、応答する必要がある。機器に依存せずJavaScriptをサポートするイベントを使用して、ユーザーのインタラクションに対応する。

4.1. 概念の間の関係

ロール（role）タクソノミーでは、ARIAのロール（role）間同士、およびHTMLやXFormsといった他の仕様で使われている概念との関係を示すため、以下の関係を使用している。

4.2. ロール（role）の特性

ロール（role）を定義し、説明するのが、特性だ。特性とは、ロール（role）の構造機能を定義するもので、例えば、そのロール（role）が何であるか、背後にどのような概念があるか、ロール（role）のどのインスタンスを含むことができるか、また含まなければならないかなどを示す。ウィジェットの場合は、HTMLフォームやXFormsへのマッピングに基づいてユーザーエージェントとの間でどのように動作するかも、特性に含まれている。さらに、特性には、そのロール（role）がサポートするWAI-ARIAのステート（state）とプロパティも含まれている。

ロール（role）タクソノミーで定義する特性は、以下のとおりである。これらの特性は、OWLクラスのプロパティとしてRDFに実装され、そのロール（role）を記述している。

4.3. ロール（role）の分類

現在のユーザーシナリオをサポートするため、この仕様では、ユーザーインタフェースウィジェット（スライダー、ツリーコントロールなど）を定義するロール（role）とページ構造（セクション、ナビゲーションなど）を定義するロール（role）を分類している。

ロール（role）データモデルで記述された関係のクラス図

クラス図を拡大して見る

ロール（role）は、以下のように分類されている。

1. 基本タイプ
2. ユーザー入力ウィジェット
3. ユーザーインタフェース要素
4. 文書構造
5. 特別なリージョン
6. ランドマークのロール（role）

4.4. ロール（role）の定義

以下は、リッチ・インターネット・アプリケーションの開発者が用いるべきARIAのロール（role）をアルファベット順に示したものである。

注：抽象のロール（role）は、オントロジーに使われる。開発者は、コンテンツ内で抽象のロール（role）を使用すべきではない。

alert

重要な情報を伴ったメッセージ。通常は、タイムリーな提示が必要とされる情報を伴う。alertdialogおよびstatusも参照。

alertdialog

アラートメッセージを伴ったダイアログの一種。初期のフォーカスは、このダイアログまたはダイアログ内の要素に置かれる。alertおよびdialogも参照。

application

ウェブのdocumentではなく、ウェブアプリケーションとして宣言されたリージョン。

article

文書、ページ、またはサイト内の独立した個所を形成するページのセクション

banner

大見出し（標題）またはウェブサイトのタイトルを含むリージョン。

button

クリックされたり押されたりした際に、ユーザが起こしたアクションを可能にする入力。

checkbox

「true」「false」「mixed」の3つの値を持つ可能性があるチェック可能な入力。

columnheader

列の見出し情報を含んだセル。

combobox

selectの表現の1つ。あるいは任意のテキストをリスト内の新しい項目として入力できるtextboxに似ている。

complementary

メインのコンテンツから切り離しても意味を持つ、文書の補足的なセクション。

composite（抽象のロール（role））

ナビゲーションできる子孫または所有された子を含む可能性があるウィジェット。

contentinfo

親の文書に適用されるメタデータ。

definition

用語または概念の定義。

dialog

ダイアログはアプリケーションウィンドウで、アプリケーションが処理中にそれを中断してユーザーに情報入力または応答を促すためのもの。Alertdialogも参照。

directory

静的な目次のように、1つのグループ内の複数のメンバーに対するリファレンスのリスト。

document

関連する情報を含み、ウェブのapplicationではなく、文書コンテンツとして宣言されているリージョン。

grid

グリッドには、テーブルと同様に、行と列に配列された表形式のデータセルが含まれる。

gridcell

グリッドまたはツリーグリッド内のセル。

group

ユーザーインタフェースオブジェクトの1セットで、支援技術によってページサマリまたは目次に含まれることがないセクション。

heading

ページ内の1セクションに対する見出し。

img

1つの画像を形成する複数の要素のためのコンテナ。

input（抽象のロール（role））

ユーザー入力を許可するウィジェットの一般的なタイプ。

landmark（抽象のロール（role））

ナビゲーションランドマークとして意図されたページのリージョン。

link

内部または外部のリソースに対するインタラクティブなリファレンス。

list

非インタラクティブなリスト項目のグループ。

listbox

ユーザーが選択肢のリストから1つまたは複数の項目を選ぶのを許可するウィジェット。

listitem

リスト、リストボックス、またはディレクトリ内の1項目。

log

新しい情報が意味のある順番に追加され、また古い情報が消されることもあるライブリージョンのタイプ。marqueeも参照。

main

文書内のメインのコンテンツ。

marquee

重要でない情報が頻繁に変更されるライブリージョンのタイプ。logも参照。

math

数学表現のための要素。

menu

ユーザーに選択肢のリストを示すウィジェットのタイプ。

menubar

通常は常に表示され、また横方向に提示されるmenuの表現。

menuitem

menuまたはmenubarに収められた複数の選択肢のうちの1オプション。

menuitemcheckbox

「true」「false」「mixed」の3つの値を持つ可能性があるチェック可能なメニュー項目。

menuitemradio

menuitemradioというロール（role）のグループにあるチェック可能なメニュー項目で、一度に1項目だけがチェックできる。

navigation

文書または関連する文書をナビゲートするためのナビゲーション要素（通常はリンク）の集合。

note

そのリソースのメインのコンテンツに対して挿入的または付随的なコンテンツのセクション。

option

selectのリスト内にある選択可能な1項目。

presentation

表現的なロール（role）を持ち、アクセシビリティAPIにマッピングする必要がない要素。

progressbar

長時間かかるタスクの進行状況を表示する要素。

radio

radioというロール（role）のグループにあるチェック可能な入力で、一度に1つだけがチェックできる。

radiogroup

ラジオボタンのグループ。

range（抽象のロール（role））

ユーザーが設定可能な値の範囲を表現する入力。

region

ウェブページまたは文書のなかで知覚可能な大きいセクションで、開発者がページ機能のサマリに含むべきではないかと思うセクション。

roletype（抽象のロール（role））

タクソノミーに含まれる他のすべてのロール（role）が継承する基本のロール（role）。

row

グリッド内のセルの行。

rowheader

グリッド内の行の見出し情報を含んだセル。

search

ウェブ文書の検索ツール。

section（抽象のロール（role））

文書またはアプリケーション内にある、レンダリング可能で構造的なコンテナの単位。

sectionhead（抽象のロール（role））

関連するセクションのトピックにラベルを付ける、またはトピックを要約する構造。

select（抽象のロール（role））

ユーザーが複数の選択肢から選ぶのを許可するフォームウィジェット。

separator

コンテンツのセクションまたはメニュー項目のグループを区切って区別するための仕切り。

slider

与えられた範囲内でユーザーが値を選ぶユーザー入力。

spinbutton

個別の選択肢のなかからユーザーが選べるようになっているrangeのフォーム・コントロール。

status

ユーザーへの助言情報だが、アラートとするほど重要ではないコンテンツを含んだコンテナ。Alertも参照。

structure（抽象のロール（role））

文書構造の要素。

tab

tabpanelの見出し。

tablist

タブパネル要素へのリファレンスとなっているタブ要素のリスト。

tabpanel

tabに関連付けられたリソースのコンテナ。

textbox

自由記述形式のテキストを値として認める入力。

timer

開始時からの経過時間、または終了時までの残り時間を示す数値カウンタ。

toolbar

よく使われる複数の機能のボタンをコンパクトな見た目で示したもの。

tooltip

要素がマウスオーバーやキーボードでフォーカスされたステート（state）にある際に、その要素の説明を表示するコンテキスト・ポップアップ。ユーザーエージェントの通常のツールチップ処理を補完する。

tree

サブレベルに入れ子になったグループを持ち、展開や折り畳みができるlistの一種。

treegrid

treeと同様に展開または折り畳むことができる行を持ったgrid。

treeitem

treeのオプション項目。これはツリー内の要素で、treeitemのサブレベルグループを含んでいれば、展開や折り畳みができる。

widget（抽象のロール（role））

グラフィカルユーザーインタフェース（GUI）のインタラクティブなコンポーネント。

window（抽象のロール（role））

ブラウザまたはアプリケーションのウィンドウ。

<div role="img" aria-labelledby="caption">
  <img src="example.png" role="presentation" alt="">
  <p id="caption">A visible text caption labeling the image.</p>
</div>

<ul role="tree">
  <li role="presentation">
    <a role="treeitem" aria-expanded="true">An expanded tree node</a> 
  </li> 
  … 
</ul>

5.1. ステート（state）とプロパティの違い

このセクションは、参考情報である。

「ステート（state）」と「プロパティ」という用語は、似たような機能を指している。いずれもオブジェクトに関する特定の情報を提供し、またロール（role）の性質の定義の一部を成すものである。この文書では、ステート（state）とプロパティの両方を、「aria-」の接頭辞を持ったマークアップ属性として扱っている。しかし、その意味の微妙な違いを明確にするため、概念的に区別している。大きな違いの1つは、（aria-checkedなどのような）ステート（state）の 値と比べると、プロパティ（aria-labelledbyなど）の値のほうが、アプリケーションのライフサイクル中に変更される可能性が低いことである。ステート（state）の値は、ユーザーのインタラクションに伴って、頻繁に変わる可能性がある。詳しくは、ステート（state）とプロパティの定義を参照してほしい。

5.2. ステート（state）とプロパティの特性

ステート（state）とプロパティには、以下の特性がある。

5.3. ステート（state）とプロパティの値

多くのステート（state）とプロパティが、特定のトークンのセットを値として受け付ける。認められた値とその意味の説明は、特性テーブルの下に示されている。デフォルト値が定義されている場合は、強調フォントで示されている。

5.4. グローバルなステート（state）とプロパティ

ステート（state）とプロパティのなかには、ロール（role）が適用されているかどうかにかかわらず、すべてのホスト言語要素に適用できるものがある。以下のグローバルなステート（state）とプロパティは、すべてのロール（role）、およびすべての基本マークアップ要素によってサポートされている。

• aria-atomic
• aria-busy（ステート（state））
• aria-controls
• aria-describedby
• aria-disabled（ステート（state））
• aria-dropeffect（ステート（state））
• aria-flowto
• aria-grabbed（ステート（state））
• aria-haspopup
• aria-hidden（ステート（state））
• aria-invalid（ステート（state））
• aria-label
• aria-labelledby
• aria-live
• aria-owns
• aria-relevant
• aria-required

グローバルなステート（state）とプロパティは、roletypeのロール（role）に適用され、これは基本のロール（role）であるため、すべてのロール（role）に継承される。この仕様では読みやすさを優先するため、グローバルなステート（state）とプロパティを、サポートされたステート（state）とプロパティ、および継承されたステート（state）とプロパティのいずれとしても明示していない。代わりとして、その継承をこのセクションへのリンクで示している。

5.5. ARIAにおけるステート（state）とプロパティのタクソノミー

ステート（state）とプロパティは、以下のように分類されている。

1. ウィジェット属性
2. ライブリージョン属性
3. ドラッグ＆ドロップ属性
4. 関係属性

5.6. ステート（state）とプロパティの定義（すべての「aria-*」属性）

以下は、リッチ・インターネット・アプリケーションの開発者によって使われるべきARIAのステート（state）とプロパティをアルファベット順に示したものである。それぞれのARIAのステート（state）とプロパティについての定義は、以下の要約リストの後に詳述する。

aria-activedescendant

コンポジットウィジェットの現時点でアクティブな子孫を特定する。

aria-atomic

リージョンが更新された場合に、変更されたリージョンの全部または一部を支援技術がユーザーに提示すべきかどうかを示す。aria-relevantも参照。

aria-autocomplete

ユーザー入力を補完する提案が提供されるかどうかを示す。

aria-busy（ステート（state））

ライブリージョンの更新が終了したかどうかを示す。

aria-checked（ステート（state））

チェックボックス、ラジオボタン、その他のウィジェットが現在チェックされたステート（state）になっているかどうかを示す。aria-pressedおよびaria-selectedも参照。

aria-controls

現在の要素によってコンテンツまたは存在が制御されている要素を特定する。aria-ownsも参照。

aria-describedby

そのオブジェクトを記述する要素を特定する。aria-labelledbyも参照。

aria-disabled（ステート（state））

要素が知覚可能ではあるが無効とされていて、結果として編集可能または操作可能ではないことを示す。aria-hiddenおよびaria-readonlyも参照。

aria-dropeffect（ステート（state））

ドラッグ＆ドロップの操作で、ドラッグされたオブジェクトがドロップターゲット上でリリースされた時の結果を示す。

aria-expanded（ステート（state））

展開または折り畳み可能な要素のグループが、現在展開されているか、折り畳まれているかを示す。

aria-flowto

コンテンツの推奨すべき読み上げ順序で次に来る要素を特定し、文書のソース順序に読み上げる一般的なデフォルトの読み上げ順序を上書きする。

aria-grabbed（ステート（state））

ドラッグ＆ドロップの操作で、要素がグラブされた（つかまれた）ステート（state）であることを示す。

aria-haspopup

その要素がポップアップのコンテキストメニューまたはサブレベルメニューを持っていることを示す。

aria-hidden（ステート（state））

要素がユーザーに対して可視または知覚可能となっていないことを示す。aria-disabledも参照。

aria-invalid（ステート（state））

入力された値が、アプリケーションが求めているフォーマットに従っていないことを示す。

aria-label

現在の要素をラベル付けする文字列の値を定義する。aria-labelledbyも参照。

aria-labelledby

現在の要素をラベル付けする要素を特定する。aria-labelおよびaria-describedbyも参照。

aria-level

ある構造内における要素の階層構造のレベルを定義する。

aria-live

要素が更新されることを示し、また、このライブリージョンからユーザーエージェント、支援技術、およびユーザーが期待できる更新のタイプを記述する。

aria-multiline

テキストボックスが1行だけを受け付けるか、複数行を受け付けるかを示す。

aria-multiselectable

ユーザーが現在の選択可能な子孫から複数の項目を選択できることを示す。

aria-owns

DOMの階層を使って親子の関係を表現することができないDOMの要素間で、視覚的または機能的な親子関係の文脈を定義するために、要素を特定する。

aria-posinset

リスト項目またはツリー項目の現在のセットにおける要素の番号または位置を定義する。DOMによって推測される場合は、必須ではない。aria-setsizeも参照。

aria-pressed（ステート（state））

トグルボタンが現在押されたステート（state）であることを示す。aria-checkedおよびaria-selectedも参照。

aria-readonly

その要素が編集不可能だが、編集以外は操作可能であることを示す。aria-disabledも参照。

aria-relevant

ライブリージョン内の変更の性質を示す。aria-atomicも参照。

aria-required

フォームを送信する前に、その要素へのユーザー入力が必須であることを示す。

aria-selected（ステート（state））

様々なウィジェットが現在選択されたステート（state）であることを示す。aria-checkedおよびaria-pressedも参照。

aria-setsize

リスト項目またはツリー項目の現在のセットに含まれている項目数を定義する。DOMによって推測される場合は、必須ではない。aria-posinsetも参照。

aria-sort

テーブルまたはグリッド内の項目が昇順または降順のどちらでソートされているかを示す。

aria-valuemax

ウィジェットの範囲に対して許可されている最大値を定義する。

aria-valuemin

ウィジェットの範囲に対して許可されている最小値を定義する。

aria-valuenow

ウィジェットの範囲に対する現在の値を定義する。aria-valuetextも参照。

aria-valuetext

ウィジェットの範囲のaria-valuenowに対して人間が読むことのできるテキスト等価物を定義する。

[aria-hidden="true"] { visibility: hidden; }