WAI-ARIA 1.0　ユーザーエージェント実装ガイド

1.1. アクセシビリティAPI

この文書でカバーしているアクセシビリティAPIは以下の通り。

• LinuxのATK/AT-SPI
• WindowsのMSAA/IAccessible2

ARIAを、Mac OS X Accessibility ProtocolやUI Automation、または他のアクセシビリティAPIにエクスポーズする最良の方法に関する情報はまだない。しかし、この文書中の情報に対する何らかのフィードバックがあれば歓迎する。他のアクセシビリティAPIに対してエクスポーズさせたい場合は、支援技術の開発者と密接に連携し合うことを推奨する

1.2. アクセシブルツリーとDOM ツリー - これらの関係について

アクセシブルツリーとDOMツリーは、並列構造である。おおまかに言うと、アクセシブルツリーは、DOMツリーのサブセットである。アクセシブルなオブジェクトは、アクセシブルなイベントを起動するため、または引き渡される必要のあるプロパティ、リレーションシップ、あるいは機能があるため、のいずれかの理由により、支援技術に引き渡されるべき個々のDOM要素に対して、アクセシブルなツリー内に生成される。一般的に言って、もし何か手を加えるとすればパフォーマンスの向上や簡潔さのためであろう。例えば、スタイルの変更のみでセマンティクスを含まない<span>要素では、それ自体のアクセシブルなオブジェクトではなく、スタイルの変更はAccessibleTextインタフェースの“text attribute run”を通じてエクスポーズされることになる。

通常のアクセシブルツリーに加え、要素に次のプロパティのうち一つがある場合は、ARIAではその要素も引継がれるよう求めている。

• フォーカス可能である、またはID属性及びaria-activedescendant属性を伴った子孫がある。いずれかのケースでフォーカスが置かれ、フォーカスイベントが起動される必要がある。
• マッピング可能なロール（role）｛後述のロール（role）の章のロール（role）)のマッピング参照｝の前に"presentation" のロール（role）でないロール(role）属性を使用している。 "presentation" ロール（role）が使用されている場合、要素がフォーカス可能ならばその要素は引き渡されるべきであり、それによりフォーカスイベントが起動可能になる（フォーカスが失われてはならない）
• グローバルなステート（state）及びプロパティのうちの一つを使用している。（しかし、hidden要素は一般にアクセシブルオブジェクトの階層から取り除かれるため、リストの中でaria-hiddenは使用しない）。
• ARIAリレーションaria-controls、aria-describedby、aria-flowto、aria-labelledbyまたはaria-owns）を通して別の要素によって指定されたIDを持っている。

アクセシブルな階層（子孫も含む）から取り除かれるべきオブジェクト

• マッピング可能なあらゆるロール（role）の前のrole="presentation"を伴った要素で、かつフォーカス可能ではない要素
• 先祖の<table> 要素がrole="presentation"を伴っているテーブルセルで、かつフォーカス可能ではないテーブルセル
• ロール(role）の特性が"Children Presentational: True"となっているオブジェクトで、次のロール（role）を含むもの：

子孫の削除が起きたとき、残っているルートオブジェクトに対してAccessible Hypertextインタフェースもエクスポーズされないようにすべきである。子孫が残っていると、これらのロール（role）に対する子孫には対応していない支援技術によっては混乱してしまうので、子孫は削除される。（例、JAWSのバーチャルバッファーはアクセス可能な名前を2度話す、あるいはスライダーのつまみをイメージとして表してしまうこともあるだろう）

2.1. タブインデックスによるフォーカスの管理

ARIAをサポートするユーザーエージェントは、tabindex、focus、及び blurをHTMLのすべての要素で使えるように、それらの使用法を拡張する。HTML５のワーキングドラフトでは、この手法を採用しているので、次のバージョンのHTMLにおいては仕様通りとなる見込みである。

HTML４およびそれ以前のものでは、タブ順序にはリンクとフォームのコントロールのみがあり、フォーカスを受け取ることができた。focusメソッドを用いたスクリプトを使用しても、他の要素にフォーカスを設定することは不可能であった。tabindexを用いてタブ順序に加えることが可能であっても、フォーカス可能にしてタブ順序に入れないことはできなかった。この問題を乗り越えるために、ユーザーエージェントはtabindex属性の値と適用範囲を拡張する。

基本的に、div、spanまたはimgといったどのような要素も、tabindex="0"と設定することで、デフォルトのタブ順序に加えることができる。さらに、tabindex="-1"を伴ったアイテムは、スクリプトまたはマウスクリック経由でフォーカスを置くことができる。しかし、デフォルトのタブ順序の一部にはならない。

スライダーのような単純ウィジェットから、メニューバー、ツリービュー、またはスプレッドシートといったコンテナウィジェットに至るまで、キーボードでアクセス可能なカスタムウィジェットを開発する一つの方法を、tabindexシステムは提供する。このシステムは、IE5.5までのInternet Explorerの古いバージョンでも動作する。

ユーザーエージェントにおける実装に際し、tabindexを全ての要素で可能にするために、次のことをしなければならない。

1. 1. それぞれの要素は、a)フォーカス可能ではない（タブ移動もできない）、b)フォーカス可能だが、タブ移動はできない、c)フォーカス可能で、かつ、タブ移動できる、のいずれかになる。従来はフォーカス可能ではなかった要素に対しても、tabindex属性の存在と値が作用しなければならない。ユーザーエージェントの中のマスククリックでの操作とタブナビゲーションのコードはこの情報を活用しなければならない。
2. それぞれのHTML要素は、element.tabIndexプロパティをエクスポーズ しなければならない。
3. focus及びblurメソッドが、HTML要素インタフェースに追加されるべきである（あらゆる要素のタイプに対してスクリプト可能となる）。
4. フォーカスを受け取ることができる要素は、focus及びblurイベントを起動しなければならない。
5. デフォルトのスタイルシートは、擬似クラス:focusを持った要素であればフォーカスoutlineプロパティを受け取ることができるように、ルールを規定しなければならない。
6. .他のブラウザとの互換性のために、keydownイベントをキャンセルする場合は、keypress イベントもキャンセルしなければならない。これは必要なことで、なぜなら、Internet Explorerをサポートする開発者は、キーストロークの処理を行うためにkeydownイベントを使用しなければならず、非英数キーに対しては、keypressではなく、keydownイベントを起動しているためである。ウェブページの開発者が、キーボードにスクリプト制御を実装する際には、keydownイベントを使用可能にするが、矢印キーなどのキーストロークによる影響を打ち消す必要がある。
7. フォーカス可能なすべての要素が、アクセシブルなオブジェクトの階層内にエクスポーズされ、フォーカスを受け取った際には、アクセシビリティ・イベントを起動するオブジェクトがあるようにする。
8. 必要に応じて、アクセシビリティ階層内のあらゆる要素に対する、FOCUSEDやFOCUSABLEのアクセシビリティAPIのステート（state）、focus のアクセシビリティAPIイベントをエクスポーズする。
9. 場合によっては、フォーカスの置かれた要素上でEnterを押下することは、クリックと同様の操作となるべきである ([HTML5], セクション 3.4.1.7).

HTML５仕様では、tabindexの拡張された振る舞いがどうあるべきか ([HTML5]、 セクション 6.5.1)を文書化している。どのような振る舞いであるべきかに関するGeckoの文書は「キー操作可能なカスタムDHTMLウィジェット」にある。IEのtabindexの振る舞いに関する文書は、「MSDN：tabindexプロパティ」。また、Operaには、いくつかの簡単なテストケースがある。

2.2. ARIAを用いたフォーカスの管理

aria-activedescendantプロパティもまた、あらゆるタイプのARIA要素において、キーボードのアクセシビリティを確保するために使われることもありうる。それは、しばしば、コンテナウイジェットキーボード・ナビゲーションを提供する、より便利な方法である（タブ順序においてはウィジェット全体で1回のみとなるが、ユーザーはキーストロークを使ってコンテナに含まれる子孫アイテムをナビゲートすることができる）。

一般的な使用方法は以下を用い、そして開発者は、コンテナの要素にtabindex="0"と、現在アクティブな子孫のIDを示すためにaria-activedescendantを用いる。現在のアクティブな子孫にキーボードフォーカスが置かれていることを示すために表示スタイルを定義するのは、ユーザーエージェントではなく、開発者の責任となる（実際のフォーカスはコンテナに置かれているので:focusメソッドによってではない）。

aria-activedescendant実装するために、ユーザーエージェントは以下のことを行わなければならない。

1. HTML 5 Tabindexのtabindexの推奨事項を実装する。 コンテナウィジェットはタブ順序に含まれなければならないので、開発者がaria-activedescendantのシステムを用いることができるように、全ての要素においてtabindex="0"をサポートしなければならない。
2. DOM内でフォーカスが置かれ、かつ、有効なIDを示しているaria-activedescendantを持つ要素については、アクセシビリティAPI内でフォーカスが置かれているようにマークしてはならない。（つまり、FOCUSED またはFOCUSABLEのステート（state）を使ってはならない）
3. aria-activedescendant属性が、現在DOMフォーカスのある要素上で変化する際、新しいアクティブな子孫上でアクセシビリティAPIのFOCUSイベントを起動する。aria-activedescendantがクリアされるか、または現在の文書内の要素を指していない場合は、属性の変更が起こったコンテナオブジェクトに対してfocusイベントを起動する。
4. aria-activedescendant属性を伴った要素の子孫で、ID属性を持った要素については、オブジェクトがアクセシブルとなるように、ターゲットに対して次のステート（state）を適用する。
   1. FOCUSABLE。要素がARIAのロール（role）も持っている場合。なぜなら、コンテナの aria-activedescendantが潜在的にそれを示す可能性があるためである。ロール（role）がない際には、これをチェックする必要があるとはかぎらない。なぜなら、フォーカスを受け取るであろう実際のHTML要素が、既にフォーカス可能なことがあるためである。
   2. ACTIVE。コンテナ要素がaria-activedescendantを子孫のIDとマッチするよう設定する場合。
   3. FOCUSED。ACTIVEとaria-activedescendantを伴ったコンテナウィジェットが、真のDOMフォーカスを受け取っている場合。
5. 支援技術がaria-activedescendantを伴ったコンテナの子孫にフォーカスを設定するときは、当該の項目を示すようにaria-activedescendantの値を変更するよう実装すべきである。

開発者向け注記：次の子孫にフォーカスを移動させる際は、scrollIntoView()メソッドを用いて、フォーカスを受け取る子孫全体が画面上に表示されるようにスクロールさせること（[HTML5]、 セクション 6.4）。

2.3. 支援技術からのフォーカス移動の操作

代替入力ソフトは、FOCUSABLEとしてエクスポーズされたアイテムにフォーカスを置くことができる必要がある。スクリーンリーダー、音声入力ソフト、及びオンスクリーンキーボードは、そのソフトウェアに実装されているユーザーコマンドに基づいてフォーカスを設定することができる。これを、MSAAベースの支援技術ではaccSelect(SELFLAG_TAKEFOCUS)メソッド経由で行い、ATKではAtkComponent::grab_focus経由で行っている。

• カレント要素が実際のDOMフォーカスを取得可能であれば、DOMフォーカスをその要素に設定する。
• そうでない場合、カレント要素にIDとaria-activedescendant属性を持った先祖が存在しているならば、DOMフォーカスを先祖に設定する。設定できたならば、その先祖にあるaria-activedescendant をカレント要素のIDに設定する。

開発者向け注記： 代替入力を可能にするために、onfocusハンドラが必要になるかもしれない。例えば、フォーカス可能なリスト項目のあるlistbox を実装している場合、新しいリスト項目がフォーカスを受け取ることのできる手段は、マウスクリックまたはキーの押下だけであると考えないこと。したがって、フォーカスの置かれた要素に対する直接的などのようなスタイルの変更も、クリック及びkeypressハンドラではなく、onfocusハンドラによって行われるべきである。aria-activedescendantを使う場合、これらの属性の変更に対応するために、DOMAttrModifed (IEではonpropertychange)を注視すること。

3.1. ARIAセマンティクスをエクスポーズするための一般原則

可能であれば、ARIAのセマンティクスは、デスクトップアクセシビリティAPIの標準的なメカニズムを通じてエクスポーズされるべきである。例えば、ARIAウィジェットの場合、同様なデスクトップウィジェットではどのようにウィジェットがエクスポーズされるか比較してみる。一般的に、ほとんどのARIAウィジェットの機能は、ロール（role）、値、ブーリアンのステート（state）、及びアクセシビリティAPIとの関係などを通じてエクスポーズされる。

ユーザーエージェントは、支援技術にステート（state）の変更を知らせるべきである。反対に、プロパティ変更の支援技術による通知は、支援技術がユーザーエージェントと情報伝達する手法に依存する。例えば、aria-multilineプロパティはしばしば変更されるものではないが、一方で、aria-checkedのステート（state）はユーザーの入力に反応して頻繁に変更される。

3.2. ネイティブなマークアップセマンティクスとARIAとの衝突

ロール（role）やname、ステート（state）、値といったアクセシビリティAPIのコアなプロパティは、それぞれ唯一のものである。衝突が起こると、通常、ARIAが勝つ。なぜなら、ARIAは基本的に他を無効にするものだからである。つまり、ネイティブなマークアップがリンクがあると言っても、ARIAのマークアップでボタンであると言っていれば、ボタンとしてエクスポーズされるべきである。

3.3. アクセシビリティAPIのプロパティに直接マッピングされない属性のエクスポーズ

ARIAのロール（role）、ステート（state）、及びプロパティ がアクセシビリティAPIと直接マッピングされない場合、ARIAの加工されていないデータをテキスト文字列としてエクスポーズさせるメカニズムを提供する。ユーザーエージェントは、アクセシビリティAPIと直接マッピングするかしないかにかかわらず、ARIAの加工されていないデータをこのAPIを通じて常にエクスポーズすることができる。

また、ARIAは、デスクトップアクセシビリティAPIが現在カバーしていない新しい機能もエクスポーズする。ARIAは、アクセシビリティAPI には従来見られなかったセマンティクスをエクスポーズするのに、オブジェクトの属性を使う。 オブジェクトの属性は、大まかに特定されるname-valueのペアで、柔軟性があるためアクセシビリティAPIがインタフェースを備えていないものをエクスポーズできる。例えば、aria-live属性は、アクセシビリティAPIにはそのようなプロパティが存在しないため、オブジェクトの属性を経由してエクスポーズされなければならない。オブジェクトの属性のname-valueのペアをエクスポーズさせるための特定の規則は、この文書で説明されている。そして記載されていない一般的なケースに対する規則については、ステート（States）及びObjectプロパティに記載されている。

それ自体が"オブジェクトの属性"を持たないアクセシビリティAPIに対しては、類似のメカニズムあるいはname-valueのペアをエクスポーズするための新しいインタフェースを開発するのが有用である。Mac OS X Accessibility Protocolでは、全ての取得物はすでにシンプルなname-valueのペアであり、必要に応じて新しいセマンティクスをエクスポーズすることが可能である。新しいセマンティクスに対するサポートを得るには、支援技術の開発者との共同作業が必要になることに留意すること。

3.4. ロール（role）のマッピング

ARIAでは、ロール（role）属性が複数のロールを示すことがある。ロール（role）の値は、スペースで区切られたトークンの順序を持ったセットで、各々のトークンは有効なロール（role）のトークンでなければならない。ARIAには、landmark及び先進的なウィジェットのようなロール（role）が含まれており、これらは従来のアクセシビリティAPIにはない。さらに、ARIAの将来のバージョンでは、開発者が定義したロール（role）がロール文字列の中で利用可能になるであろう。その場合は、ロール文字列の中で、カスタムロールの後に万一のための代替ロール（role）が提供されることになると考えられる。

プラットフォームのアクセシビリティAPIには、そのプラットフォーム上で支援技術が求める既定のロール一式がある。ARIAのロール（role）は、プラットフォームのアクセシビリティAPIのロール(role）と常に完全に一致するわけではない。

もう一つの相違点は、プラットフォームアクセシビリティAPIにおいては、従来のロール（role）のメカニズムを通じて1～2個のロール（role）しかエクスポーズできないことである。これに対して、ARIAでは、複数のロール（role）がエクスポーズできる。追加的なロールはおそらく万一のための代替ロール（role）であろう。これは、カスタムロール（role）がある実装において検出されなかったときのためのバックアップとなる。あるいは、landmarkロール（role）となる。landmarkは、一般にプラットフォームのアクセシビリティAPIとのマッピングを持たないため、どのように最初のウィジェットロール（role）がエクスポーズされるかに影響を及ぼすことなく、landmarkはロール（role）文字列のどこにでも存在しうる。

ユーザーエージェントは、ロール（role）文字列全体が解析可能であっても、アクセシビリティAPIの標準的なロール（role）のメカニズムが最もフィットするウィジェットロール（role）を提供できるように、ロール（role）をエクスポーズすべきである。

1. アクセシビリティAPIの標準的なロール（role）のメカニズムを経由してアクセシビリティAPIとマッピングする際は、（複数の）アクセシビリティAPIと既にマッピングが取れている最初のロール（role）のトークンが使用されるべきである。下記のロール（role）一覧表を使用し、特定できる特別なケースについてのルールを適用する。
2. ARIAの仕様において "abstract"と定義されているロール（role）は、アクセシビリティAPIの標準的なロール（role）のメカニズムを経由してマッピングされるべきではない。abstractのロール（role）は以下のようになる。
3. プラットフォームのアクセシビリティAPIの標準的なロール（role）とマッピングがない場合、プラットフォームのアクセシビリティAPIのロール（role）のマッピングに使用されるアルゴリズムはロール（role）属性が提示されていないかのように動作すべきである。つまり、ユーザーエージェントが、ロール（role）属性を伴った要素に対する基本的なマークアップの通常の処理に頼ることになる。例えば、<table role="log">に対しては、プラットフォームのアクセシビリティAPIのどのロール（role）を使用すべきか判断するためにタグ名の"table"を使うこと。<input type="text" role="search">の場合は、テキスト入力のためにプラットフォームのアクセシビリティAPIを使用すること。
4. ロール（role）文字列全体が、オブジェクトの属性の"xml-roles"にエクスポーズされるべきである。これによって、支援技術がロール（role）に対する付加的な処理を行うことができる。

動的なロール（role）の変更は、WAI-ARIAの仕様ではエラーであると考えられており、 エラーへの対処の項で説明されている。

• MSAAやIAccessible2では、アクセシブルな親オブジェクト上でEVENT_OBJECT_REORDERと共に、EVENT_OBJECT_HIDE 及びEVENT_OBJECT_SHOWが、そのイベントである。
• ATKやAT-SPIでは、children-changed:removeを起動し、その後に新しいオブジェクトのためにchildren-changed:addが続く。

3.5. ステート（state）とプロパティのマッピング

このセクションでは、付加的なステート（state）及びこの文書の前のセクションでは扱わなかったオブジェクトのプロパティのエクスポーズ方法について解説する。可能であれば、APIの標準的なステート（state）を用いる。用いることができないときは、オブジェクトの属性（または同様のメカニズム）が必要となる。

1. VISIBLE/INVISIBLEやSHOWING/OFFSCREENなどのような管理されたステート（state）を計算する。一般的にAIRAの属性を持たない通常の要素に対して行われる場合と同様に行われる。FOCUSABLE/FOCUSEDについては、aria-activedescendantによる影響を受けることがあるので、aria-activedescendantにおけるルールを参照のこと。
2. 基本的なマークアップに対して、アクセシビリティの実装よってサポートされているステート（state）及びオブジェクトの属性を加える。
3. 主要なロール(role）のための特例のルールを適用する。例えば、ロール(role)によっては、エクスポーズされるべき付加的なステート(state)を必要とする。主要なマッピングされたロール(role)については、Role(role）にあるロール(role)一覧表で、エクスポーズすべき付加的なステート(state)及びオブジェクトの属性を確認できる。
4. 関連のあるAIRAのプロパティのステート（state）を計算する。関連のあるARIAのプロパティを判断するためには、グローバルなステート（state）及びプロパティ のリストを、カレント要素にあるロール(role）によってサポートされている特定のステート（state）とプロパティと組み合わせる。 例えば、全ての要素がaria-requiredをサポートしているが、role="checkbox"のように、aria-checkedプロパティをサポートしているロール（role）は限られている。プロパティの計算については、以下の一覧表を参照のこと。
5. 将来のバージョンにおける新しいARIAのプロパティとの上位互換性のために、この表にはないすべてのプロパティでオブジェクトの属性があるものは、名前から"aria-"という接頭辞を取り除いてエクスポーズする。例えば、aria-foo="bar"は、オブジェクトの属性であるfoo=barを伴ってエクスポーズされる。それは、aria-fooが仕様上は既知のARIAプロパティではないからである（具体的なマッピングのルールによってまだカバーされていない）。

ARIAのプロパティのマッピングルールに関する一覧表

重要な注記：ARIAの属性が、提示されていない、長さがゼロの文字列に設定されている、又はundefinedである場合、BooleanまたはNMTOKENの型のAIRAプロパティはどれも"undefined"である。これは、文字列、10進型、IDREF、またはIDREFSの型であるプロパティには影響を及ぼさない。

また、グローバルでないステート（state）及びプロパティは、それらをサポートするロール(role）を伴った要素上でのみ計算されるようにする。

動的なARIAのプロパティの変更には、例えばstate changeイベントのようなイベントをエクスポーズして変化が起こったことを示す。簡潔さと性能のために、ユーザーエージェントは、支援技術が通常は無視するプロパティに対する変更イベントを取り除いても よい。 しかし、少なくとも、state changeイベントは、次の変更に対して実行されるべきである。

• aria-disabled：ENABLED及びSENSITIVEのステート（state）に影響を及ぼす。
• aria-checkedまたはaria-pressed：CHECKEDステート（state）に影響を及ぼす。値が"mixed"に変更、または"mixed"から変更になる場合も、MIXED/INDETERMINATEに対するステート（state）の変更が実行される べきである。
• aria-invalid：INVALID_ENTRYステート（state）に影響を及ぼす。（APIにおけるNVALIDステート（state）は正当なステート（stete）が存在しないという意味であり、異なっているため注意すること）
• aria-expanded、aria-readonly、aria-required：アクセシビリティAPIの同じような名称のステート（state）に影響を及ぼす。

他の変更のタイプ

• aria-activedescendantにおける変更は、aria-activedescendantで説明されているように、focusイベントに影響を及ぼす。
• aria-valuenowにおける変更は、値で説明されているように、値変更のイベントに影響を及ぼす。
• ロール（role）またはaria-multiselectableの変更は、要素に対するアクセシブルなオブジェクトを破壊し新しく再生すべきである。なぜなら、アクセシビリティAPIを経由してエクスポーズされたインタフェースも同様に変更する大きな変更となるからである。
• aria-selectedにおける変更は、選択で説明されているように、selectionイベントに影響を及ぼすべきである。

3.6. 追加的な計算が必要とする特別な処理

4.1. 付加的なインタフェースをエクスポーズする

一般的に、アクセシブルなオブジェクトのためにどのインタフェースがエクスポーズされるかをベースマークアップで決定すべきである。しかしながら、次のような場合は、どちらのインタフェースがエクスポーズされるべきかをARIAのマークアップが変更している。

• AccessibleValue：値の項で述べたように、要素のいずれかのロール（role）がaria-valuenowをサポートしている場合、aria-valuenowを持ったオブジェクトに対してvalueインタフェースをエクスポーズするべきである。なぜなら、valueインタフェースによって値が設定され、aria-valuenowが実際に読み/書きとなるからである。値が妥当な値に変更され、カレント要素がreadonly、disabledのいずれでもない場合、ブラウザはaria-valuenowを設定する必要がある。開発者向け注記：valuenowを実装するあらゆるものはon　DOMAttrChanged (IEではonpropertychange)を監視し、それに反応する必要がある。
• AccessibleTable：role="grid"及びrole="treegrid"に対してエクスポーズされるべきである。（注記：Mozillaは未対応 - 既知のバグ）
• AccessibleSelection：ロール（role）がaria-multiselectableをサポートしていて、aria-multiselectable="true"のとき、エクスポーズされるべきである。
• AccessibleHypertext：要素の子孫がロール（role）に基づいて切り取られてしまっている場合はエクスポーズされるべきではない。どのロール（role）がサブツリーを切り取るのかについては11.3.2.1参照のこと。

ARIA特有の事項ではないが、アクセシブルなウェブアプリケーションという目的のために、インタフェースをエクスポーズするための、いくつかの役に立つ追加的な規則について言及する価値がある。

• AccessibleAction： 将来のバージョンのARIAがアクションの取り扱いに対する正確性が向上するとしても、少なくとも"クリック"ハンドラを伴うものに対してエクスポーズされるべきである。また、MSAAにおいてはdoDefaultAction（＃０アクションと同様）をサポートする必要がある。これはクリックにマッピングされる。
• AccessibleEditabletext：contenteditableまたはdesignModeを経由して編集可能になったリージョンに対してエクスポーズされるべきである。

4.2. アクション

アクションは以下の規則によってエクスポーズされる。

• 要素が登録されたクリック・イベント・ハンドラを有している。
• 要素はxlinkである。
• 要素はアクションを可能にするARIAのロール(role）を有している（下記の表を参照）。

4.3. 文書のコンテンツまたはノードの可視性に対する変更

文書の変更を処理することはARIAに限らず重要である。しかしながら、多くの場合AIRAのマークアップを伴うAJAX及びその他のユースケースを有効にすることは極めて重大なので、本項でそれをどのように行うか文書化ている。

テキストの変更に対してこれらのイベントを駆動させる。

1. テキストが取り除かれたとき、IA2_EVENT_TEXT_REMOVED(IA2) 及びtext_changed:delete (ATK)を駆動。
2. テキストが挿入されたとき、IA2_EVENT_TEXT_INSERTED(IA2) と text_changed:insert (ATK)
3. テキストが変更されたとき、削除イベントに続き、挿入イベントを駆動

問題のノードが要素であり、アクセシブルなオブジェクトを有しているノードの変化に対してこれらのイベントを駆動させる。

1. サブツリーが削除または非表示となったとき、EVENT_OBJECT_HIDE(MSAA) 及び children_changed:remove (ATK)を駆動させる。MSAAのEVENT_OBJECT_DESTROYイベントは動作の安定性の問題が過去にあり、支援技術が避けているため使用しない。いずれの場合でも、ユーザーの視点では、非表示のものと無効化されたものとの間には違いはない。
2. サブツリーが挿入、または展開されたとき、EVENT_OBJECT_SHOW(MSAA) 及び children_changed:add (ATK)とを駆動させる。
3. サブツリーが移動されたときは、ある場所から削除されて他の場所へ挿入したように扱う。
4. サブツリーが変更（例、replaceNode）されたときは、削除と挿入のように扱う。

ノードが要素ではない、またはアクセシブルなオブジェクトを持たない場合：

• おそらく、AccessibleTextインタフェース によるテキストのアウトプットに影響を及ぼす。上で述べたように、関連するテキスト変更のイベントを計算し、駆動させる。
• アクセシブルな子孫が存在しうる。適切なshow/hide/children_changed イベントがアクセシブルなオブジェクトを伴った第１列の子孫に対して駆動されなければならない。

上で述べた変更イベントのいずれかを駆動するときは、（ページの読み込みなどによって引き起こされたタイムアウトとは反対に）ユーザーの入力によって変更が引き起こされたかどうかについての情報を提供するととても有用である。これによって支援技術はユーザーのアクションからの変更とは反対の実世界からの変更を提示するための別の規則を持つことができる。　マウスホバーは明確なユーザーの入力とはみなされない。なぜなら、マウスの偶発的な衝突で起こりうるからである。

変更がユーザーの入力によって起きたかどうかをエクスポーズするためには：

• ATKでは、ユーザーが変更をしていないときは、":system"をイベント名に付記して提供することができる。
• MSAAでは、スクリーンリーダーは一般に同じスレッド上にアクセスして処理をするため、ベストプラクティスとしては、ユーザーが変更をした場合、そのイベントに対するアクセシブルなオブジェクトのオブジェクト属性"event-from-user-input=true" をエクスポーズする。

変更の状況についてのさらなる有益な情報をエクスポーズする：

• アクセシブルなイベントオブジェクトのmember-ofリレーションは、 (もしあれば)aria-atomic="true"を伴った先祖を示すべきである。
• container-live、container-channel、container-relevant、container-busy、container-atomicといったオブジェクトの属性は、関連するARIAのプロパティに対する計算値を提供してアクセシブルなイベントのオブジェクトにエクスポーズされるべきである。計算値は直近の先祖の値である。デフォルトの値が使用されている場合はオブジェクトの属性はエクスポーズしないことを推奨する。

追加的なMSAAイベントが必要になることがある：

• マッピングされたMSAAのロール（role）ROLE_SYSTEM_ALERTを伴った先祖に何かしら変更があった場合、警告のためにEVENT_SYSTEM_ALERTイベントを駆動すべきである。この警告のロール（role）はaria-liveプロパティに対して"assertive"という暗示された値を持つ。
• Menuイベントを駆動させる必要がある。MSAA/IAccessible2のMenuを参照のこと。

4.4. 選択

選択には二つの場合がある。

• 単一選択
• 複数選択

単一選択の場合では、選択のイベントとステート(state）をフォーカスから切り離して管理することが常に必要というわけではない。なぜなら、選択 はfocusを反映するからである。一つの例外はタブリストに対してである。タブの場合、タブまたは関連付けられたタブパネルにフォーカスがある場合、タブはSELECTEDとみなされる。これを実装するには、フォーカスの当たっている箇所からタブパネルを見つけるまで親鎖を上がって行き、aria-labelledbyの関係をタブパネルから関連するタブまで全探索し、見つかったタブをフォーカスが当たっているとマークする。

aria-multiselectableプロパティをサポートするロールを持った要素でaria-multiselectable="true"のとき、複数選択の場合が発生する。これにはいくつかの重要な側面がある。

1. コンテナの正しいステート（state）をエクスポーズする： MULTISELECTABLE及びMSAAではさらに EXTSELECTABLE。
2. aria-multiselectableを伴ったコンテナのAccessibleSelectionインタフェースをサポートすること。選択インタフェースは、支援技術が実際に子孫に選択を設定するのに使用することができる。 aria-selectedが定義されていない場合、すなわち、要素がSELECTABLEでない場合は、特定の子孫に対しては機能させないようにすべきである。特定の子孫が何らかの理由によりDISABLEDまたはREADONLYとなっている場合も機能させないようにすべきである。ある項目から選択をクリアする際は、aria-selected="false"と設定するが、属性は削除しないようにする。そうすることで依然としてSELECTABLEとなっている。開発者向け注記：スクリプトはaria-selectedの変化に留意する必要がある。なぜならば、選択は、マウスやキーボードではなく、支援技術によって発生することがあるからである。
3. 子孫でaria-selectedに変更があった場合は、次のように、正しいイベントを駆動させる。

4.5. MSAA/IAccessible2のメニュー

MSAA下では、メニューの開閉の度に特別なイベントが必須となる。これらのイベントは入れ子構造で対称性を持っていなければならない。

• menubarにあるmenuが開いたときは単一のEVENT_SYSTEM_MENUSTART。これはmenuitemにフォーカスが移動し、menuのモードが現在有効になっていない場合に作動する。しかし、EVENT_SYSTEM_MENUPOPUPSTARTイベントの前に駆動させなければならない。menubarは自然な親チェーンの中、またはaria-owns（RELATION_NODE_CHILD_OF implを使用してaria-ownsの先祖に行く）によって発生したものの中になければならない。
• ポップアップメニューが可視化したとき、一つまたは複数のEVENT_SYSTEM_MENUPOPUPSTART。メニューが可視化したとき作動する。しかし、メニューが閉じられて再度開くまで、1回のみ駆動すべきである。サブツリーのいずれかが可視化した際は、role="menu"がないか子孫をチェックすることに注意を払うべきである。menuのロール（role）が変化のルートノードには存在しない可能性がある。
• menuitemのフォーカスイベント。EVENT_SYSTEM_MENUPOPUPSTARTの後に発生しなければならない。
• ポップアップメニューが非表示になったときに、１つまたは複数のEVENT_SYSTEM_MENUPOPUPEND。これはEVENT_SYSTEM_MENUPOPUPSTARTが駆動したとき、アクセシブルなメニューオブジェクトに対してのみ駆動すべきであり、このような場合に1回駆動するのみにすべきである。サブツリーが非表示の際には、role="menu"がないか子孫をチェックすることに注意を払うべきである。
• menubarモード（MENUSTARTが駆動した）で、menubarの中の全てのメニューが閉じる際、またはフォーカスが（ダイアログの中のコントロールのような）menuitem以外のどこかに移動する際には、最終のEVENT_SYSTEM_MENUEND。

メニューが開いているとき、ウィンドウズ上のスクリーンリーダーは一般にフォーカスイベントを無視するので、メニュー以外のものがフォーカスを受け取ったとき（例、メニューオプションを選択してダイアログを開く）、EVENT_SYSTEM_MENUPOPUPENDに続けて、対称のEVENT_SYSTEM_MENUPOPUPENDを駆動させることが重要である。実際、スクリーンリーダーは正しいメニュー終了イベントが駆動しないと非常に混乱する。

つまり、完璧に対称性を持ったイベントを用いることは困難である。なぜなら、メニューはさまざまなテクニックを用いて可視と非表示にすることが可能なので、実装では発生するメニューイベントの経過を追い、対称化を確保することが望ましい。

5.1. frameとiframe要素を扱った文書

• ARIAのルートノード：HTMLまたは他の全ての言語における文書要素 の<body>または<frameset>
• サブ文書：<frame>、<iframe>または類似したメカニズムにより作成された文書。サブ文書は、文書、アプリケーション、或いは別のサーバーを参照しているカレンダーといったウィジェットを含むことがある。アクセシビリティ階層において、この状況に対して２つのアクセシブルなオブジェクトがある。 ひとつは親文書の中の<frame>/<iframe>要素で、内包する文書のコンテンツを表している１つのアクセシブルな子オブジェクトの親となっいる。
• アクセシブルな外部文書：<frame>/<iframe>を表すアクセシブルなオブジェクト
• アクセシブルな内部文書：内包した文書のためのARIAのルートノードを表すアクセシブルなオブジェクト。アクセシブルな外部文書の子である。

アクセシブルな外部文書に対するアクセシブルな名前を計算する。

• アクセシブルな外部文書のためのアクセシビリティ・プロパティはエレメントに対して通常はそのままの状態でエクスポーズされる。

アクセシブルな内部文書に対するアクセシブルな名前を計算する。

1. サブ文書の場合は、<frame> または<iframe>からaria-labelledbyを使って深さ優先の名前計算をする。名前がまだ空値ならば、<frame>または<iframe>からtitle属性を使用する。
2. 名前が未だに空値の場合は、文書のARIAのルートノードにあるaria-labelledbyから深さ優先の名前計算を使うこと。もし、まだ空値ならばARIAのルートノードのtitile属性を使用すること。
3. 名前が未だに空値で、<title>要素またはアクセシブルな名前を得るための他の手段が存在する場合、それを使用すること。

アクセシブルな内部文書に対するアクセシブルな説明を計算する。

1. サブ文書の場合、<frame>または<iframe>からaria-describedbyを使用して深さ優先の説明計算をすること。
2. 説明がまた空値の場合は、文書のARIAのルートノードのaria-describedbyから深さ優先の名前計算を使用する。

サブ文書中にあるノードのcontainer-fooを計算する：container-live、container-atomic、container-relevant、container-channel及びcontainer-busyについては、内部ノードが同一文書内にある外部ノードをオーバーライドする。なぜなら、内部のサブツリーはより意味のある文脈だからである。しかしながら、外部文書の作者は別人で、ライブのiframeに対してその文脈を定義したいと考えるかもしれないので、外部文書が内部文書をオーバーライドする。したがって、

1. aria-live、aria-atomic、aria-relevant、及びaria-busyのプロパティからcontainer-[プロパティ]のオブジェクトの属性に流し込むためのプロパティを収集しながら、外部文書からの物も含めて、親チェーン全体を巡る
2. ノードがあるオブジェクトの属性を設定している場合は、文書の中でそのオブジェクトの属性を再度変更させない値を持つステート（state）を設定する。
3. 親文書に入った時は、これらのオブジェクトのそれぞれのプロパティを再度オーバーライドできるようにステート（state）をリフレッシュさせる。

アクセシブルな内部文書に対するその他のプロパティの計算

1. ユーザーが制御するプロパティ（aria-selected、aria-valuenow、aria-valuetext、aria-activedescendant）に対しては、ARIAのルートノード上でのみARIAのマークアップを使用する
2. 個別のプロパティベースで、アクセシブルな外部文書のARIAのプロパティが優位となる。
3. アクセシブルな外部文書がプロパティを設定しない場合は、内部文書のARIAのルートノードを使用する。
4. リレーションは連鎖的ではない。アクセシブルな外部文書が関係を設定する場合、内部文書のARIAのルートノードに設定されているものではなくそれを使用する。

5.2. CSS セレクタ

属性セレクタをサポートする際はARIA属性を含めなければならない。例えば、.fooMenuItem['aria-haspop=true'] は "fooMenuItem"クラス及びtrue値を持ったARIA属性"aria-haspopup"を伴った全ての要素を選択するべきである。表現はARIA属性の動的な変更に伴って更新されなければならない。これにより開発者はスタイリングとARIAのセマンティクスをマッチさせることができる。

6.1. 定義

• ターゲット要素：ARIAのリレーションで指定されている要素。例えば、aria-controls="elem1"においては、、"elem1"がターゲット要素。
• 有効なID：次のような条件を満たすARIAのプロパティに対する特定のID。
  リレーションを指定する要素として、同一文書中に存在するターゲット要素を指している。

6.2. バリュータイプ: IDREFと IDREFS

Q：無効なIDがARIAのプロパティに対して指定されている場合どうなるか。
A：ユーザーエージェントはIDを無視する。

Q：ARIAのプロパティの中に有効なIDと無効なIDが混在しているとどうなるか。
A：ユーザーエージェントは有効なIDに対応するオブジェクトのみを返す。

Q：同じIDに複数の要素がある場合どうなるか。
A：当該IDの最初に見つかった要素が使用される。挙動はgetElementByIdの場合と同様で、IDの一意性を保障するのはweb開発者の責任である。

Q：IDREFS型の単一のARIAのリレーションにおいて、同一の要素が複数回指定されるとどうなるか。
A：[言い換える必要があるかもしれないが、アクセシブルなオブジェクトに対するポインターの配列が戻り値だと思う。]ユーザーエージェントは同一オブジェクトに対して複数のポインターを返すことになる。

Q：単一のIDREF型のプロパティに対して複数のID（スペースで区切られたリスト）が指定されているとどうなるか。
A：ユーザーエージェントは（スペースで区切らずに）文字列全体を使用し、そのIDをもつ要素を参照しようとする。例えば、aria-activedescendant="foo bar"はid="foo bar"とマッチするであろう。

[IE特有] Q：IE7と互換性があるため、開発者が“id”ではなく“name”属性を使っている場合どうなるか。
A：文書のバージョンに関係なく、IEでは“id”属性にのみマッチする。“id”属性にのみマッチングするのが正しい挙動だと思う。

6.3. バリュータイプ:decimal（10 進型）

Q：１０進型に対して非数値の値が指定されているとどうなるか。
A：プロパティの文字列バージョンが求められている場合は、ユーザーエージェントは開発者によって指定された文字を単純に返す。しかしながら、明確に10進型が要求されている場合は、ユーザーエージェントは文字列を10進型に変換できず、デフォルトの値を返す。

6.4. ユーザーエージェントでの検証

一般的に、ユーザーエージェントはARIAのプロパティのバリデーションをあまり行わない。要求に応じて小さなバリデーションが起動される。たとえば、有効なＩＤがARIAのリレーションに対して指定されているか確かめたり、aria-posinsetを（aria-setsizeも含めて）１以内にするといったことである。ユーザーエージェント次のような論理的なバリデーションに対しては責任がない。

1. リレーションによって生み出される循環参照。例えば、２つの要素がお互いを親子関係として指定するなど。
2. DOMツリー構造に関する正しい使用法。例えば、リレーションを伴った要素の子孫DOMとなっているaria-activedescendant。
3. ARIAのロール（role）を伴った要素が指定されたロール（role）を正しく実装する。例えば、ユーザーエージェントはrole=”checkbox”を伴った要素が実際にチェックボックスのように挙動するかは検証しない。

6.5. ロール（Role）

Q. 抽象ロール（role）、またはプラットフォームのアクセシビリティAPIのための標準的なロール（role）にマップしないロール（role）を開発者が使用したらどうなるか。
A:これについては仕様に定義されている：

http://www.w3.org/TR/2009/WD-wai-aria-20090224/#ua_role_identifyロール（role）属性の任意のロール（role）が抽象である、またはマッピングがない場合は、そのロール（role）をスキップする。ロール属性の中に既知のロール（role）がない場合は、ｘｍｌ-rolesのオブジェクトの属性の中のロール（role）の属性値をエクスポーズする以外は、ユーザーエージェントは、そのロール（role）が欠落しているかのように振舞う。

Q.開発者が要素のロール（role）を動的に変更したらどうなるか。
A.これはARIAの仕様では正しくない実装方法であり、、オブジェクトによってサポートされている必要があるアクセシブルなインタフェースに変化を引き起こす。これは、支援技術にとっては予期せぬことである。したがって、動的なロール(role)に対処する最もお金のかからない方法が用いられる。ロール（role）の変更に伴い、オブジェクトに対して適切な無効化イベントを発生させ、支援技術がキャッシュあるいはバーチャルバッファーを更新できるようにする。関連する無効化イベントは次の通り。

• MSAA/IAccessible2では、アクセシブルな親オブジェクトにEVENT_OBJECT_REORDERを伴ったEVENT_OBJECT_HIDEとEVENT_OBJECT_SHOW。
• ATK/AT-SPIでは、新しいオブジェクトに対して、children-changed:removeを発生させ、その後にchildren-changed:addが続く。

6.6. ステート（state）とプロパティ

Q.ARIAのプロパティにはグローバルでないものがあり、特定のロール（role）でのみサポートされているものがある。サポートされていない従属的なARIAのプロパティを使った場合、何をマップすべきか。
A. ユーザーエージェントはARIAのプロパティが欠落しているかのように振舞うべきであり、プラットフォームのアクセシビリティAPIを経由してそのARIAのプロパティをマップさせるべきではない。例えば、aria-checkedは<div role="grid">ではCHECKEDとしてエクスポーズすべきでない。

Q. ARIAのプロパティが未知の値、または認められていない値を持っているとき、プラットフォームのアクセシビリティAPIに何をエクスポーズすべきか。
A.1 オブジェクトの属性としてエクスポーズするとき、未知の値をエクスポーズすること。可能性のある値に照らし合わせて入念に調べないこと。
A.2 プラットフォームAPIのブーリアン・ステート（state）としてエクスポーズするとき、""、 "undefined" または値がない場合はfalseとして扱うこと。他の値はtrueとして扱うこと。
A.3 さもないときは、値を無視してプロパティは存在しないものとして扱うこと。

Q. 未知のARIAのプロパティが使われたとき、プラットフォームのアクセシビリティAPIに対して何をエクスポーズすべきか。
A. "aria-"の接頭辞を取り去った同じ名前とともにオブジェクトの属性をエクスポーズすること。オブジェクトの属性値はARIAのプロパティの値に等しくなるべきである。これは将来のバージョンの新しいARIAのプロパティとの上位互換性の助けとなる。

Q. aria-hiddenが実際のノードの表示、非表示とマッチしないときはどうするか。
A.この誤った状態は確認する必要はない。なぜなら、レイアウトAPIがより完璧な情報を提供する場合、aria-hiddenは必要ない。忠告：aria-hidden="true"を伴った要素が見えるならば、ARIAの間違った使用方法である。aria-hiddenプロパティはDOMベースの支援技術が可視状態の変化の情報を受け取ることができるようにするためのみにエクスポーズすべきである。なぜなら、実際に非表示となっているすべてのノードの最も完全なセットはレイアウトAPIが提供するからであり、aria-hidden属性ではなくそれらを使用すべきである。

Q. aria-valuenowを変更するために支援技術がプラットフォームのアクセシビリティAPIセッターを使用しているならば、ユーザーエージェントはaria-valueminとaria-valuemaxによって設定される制限の中に新しい値が入っていることを保障すべきか。
A. その通り。制限を越えている場合は値を設定してはならない。しかしながら、ユーザーデータの妥当性を保障するのはwebアプリケーションの最終的な責任であることに留意すること。

Q.aria-valuenowを取得するために支援技術がプラットフォームのアクセシビリティAPIゲッターを使用している場合、ユーザーエージェントはaria-valueminとaria-valuemaxによって設定される制限の中に入っていることを保障すべきか。
A. いいえ。制限外か否かに関わらず、単にaria-valuenowをエクスポーズすればよい。

Q. 要素がaria-valuetextプロパティのセットは持っているが、aria-valuenowは持っていない場合どうなるか。
A. このガイドで説明されているようににvaluetextをエクスポーズする。しかし、１０進型のみを返すバリューゲッターに対してはエラーを返すこと。

Q.aria-valuenowを変更するために支援技術がプラットフォームのアクセシビリティAPIセッターを使用している場合、ユーザーエージェントはカレント要素が無効または読み取り専用になっていないことを保障すべきか。
A. その通り。カレント要素が無効または読み取り専用となっている場合は値を設定しないこと。

Q. 支援技術が要素の選択状態を変更するためにアクセシビリティのプラットフォームAPIを使用する場合、ユーザーエージェントは要素が無効になっていないことを保障すべきか。
A. その通り。（読み取り専用の要素に対して選択状態を変更しても問題ないが）カレント要素が無効となっている場合は、選択状態の設定または解除をしてはならない。

Q. ユーザーエージェントはaria-activedescendantが実際に子孫を指定しているかどうかをチェックすべきか。
A. いいえ。

Q. aria-level、aria-setsizeまたはaria-posinsetが０またはマイナスの場合はどうするか。
A. １を返す。

Q. aria-posinsetがaria-setsizeより大きい場合はどうするか。
A.aria-posinsetの代わりにaria-setsizeを返す。

Q. 任意のウィジェットのために必須のariaのプロパティ（例、ロール（role）が必須としている）が欠落している場合はどうするか。
A.

6.7. 支援技術にエラーを伝達する

ARIAのために引き起こされるエラーの多くは、callerには伝達されない。例えば、IDREFSのリスト中に無効なIDを見つけても、callerに対してエラーコードを返す理由とはならない。伝達可能なエラーはARIAの特定のプロパティに限った場合である。

1. 子ID及びaria-owns：aria-ownsは要素に子のリストを付加する。無効な子IDを特定する時、同様なことが起きるが、新しい有効な範囲の外にある子IDを指定する場合もエラーを返す。

7.1. 参考文献

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

[ARIA]

Accessible Rich Internet Applications (WAI-ARIA) Version 1.0. L. Seeman、 M. Cooper、 R. Schwerdtfeger、 L. Pappas編集、W3C ワーキングドラフト (作業進行中), 2008年2月4日。 このバージョンのWAI-ARIAはhttp://www.w3.org/TR/2008/WD-wai-aria-20080204/で入手できる。最新バージョンのWAI-ARIAはhttp://www.w3.org/TR/wai-aria/で入手できる。

[HTML5]

HTML 5、 D. Hyatt、 I. Hickson編集、W3C ワーキングドラフト(作業進行中)、2008年1月22日、http://www.w3.org/TR/2008/WD-html5-20080122/。 最新バージョンの HTML 5はhttp://www.w3.org/TR/html5/で入手できる。

7.2. 謝意

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

この文書の策定にあたっては、以下の方々からの協力を仰いだ。