WAI ARIA ライブリージョン/API 対応
========================

**警告:** これらの注釈は、スクリーンリーダーの開発者向けです。 開発者は、ARIA ライブリージョン開発者のドキュメントを使用する必要があります。

Firefox 3 には、Mozilla エンジンがドキュメントのライブ変更を公開する方法に対する重要な改善が含まれています。

これらの機能は、ARIA ライブリージョンマークアップでマークアップされたページと、追加のマークアップを追加しなかったページの両方で、スクリーンリーダー開発者がライブリージョンサポートの品質とパフォーマンスを向上させるのに役立ちます。

ARIA のライブリージョンのマークアップについては、ARIA の仕様またはライブリージョンのレポートをお読みください。

いつものように、私たちはコミュニティフォーラムの変更に関する質問や提案には門を開いています。

ウェブページの異変に対して発行されるイベント
----------------------

| 文書内の変更点 | ATK/AT-SPI イベント | IAccessible2 イベント |
| --- | --- | --- |
| オブジェクトが非表示または削除されようとしている | children\_changed::remove （親で発行され、イベントデータは削除されるアクセシブルオブジェクトの子インデックスを指している） | EVENT\_OBJECT\_HIDE\* （実際にアクセス可能なオブジェクトが消えようとしている時に発行される） |
| オブジェクトが表示または挿入される | children\_changed::add （親で発行され、イベントデータは挿入されたアクセシブルオブジェクトの子インデックスを指します。） | EVENT\_OBJECT\_SHOW\* （実際の新しいアクセシブルオブジェクトで発行される） |
| オブジェクトが異なるオブジェクトに置き換わった（特にオブジェクトのインターフェイスや役割が変更された場合に起こります） | children\_changed::remove の直後に children\_change::add | EVENT\_OBJECT\_HIDE の直後に EVENT\_OBJECT\_SHOW |
| テキストが削除された | text\_changed::delete | IA2\_EVENT\_TEXT\_REMOVED （オフセットと削除されたテキストを使用するために IAccessibleText::get\_oldText を使用します） |
| テキストが挿入された | text\_changed::insert | IA2\_EVENT\_TEXT\_INSERTED （オフセットと挿入されたテキストを取得するために IAccessibleText::get\_newText を使用します） |
| テキストが置き換えられた | text\_changed::delete の直後に text\_changed::insert | IA2\_EVENT\_TEXT\_REMOVED の直後に IA2\_EVENT\_TEXT\_INSERTED |

\* MSAA の CREATE/DESTROY は使用しません。これは、画面の内側を読むリーダーからのリクエストによるもので、これらのイベントは、重要なシステムでクラッシュを発生させるため避けられます - SHOW/HIDE はこれらのイベントと同等です。

イベントから作者提供の ARIA ライブリージョンセマンティクスの取得
-----------------------------------

ある祖先要素 (最も近い祖先の勝利) に定義されている場合、ページ内の任意の変更イベントに対して、作成者はイベントオブジェクトから以下のオブジェクト属性を取得できます。

| オブジェクトの属性名 | 取りうる値 | 既定値 | 必要な場合の ARIA マークアップ | 意味 |
| --- | --- | --- | --- | --- |
| `container-live` | `"off" | "polite" | "assertive"` | `"off"` | 祖先要素への `aria-live` | 中断 |
| `container-relevant` | `'additions'` `'removals'` `'text' | "all"` | `"additions text"` | 祖先要素への `aria-relevant` | どのような型の変異が使用可能なのでしょうか？セクション](#events\_fired\_for\_web\_page\_mutations\_the\_mutation\_events\_list)を参照して、イベントの型とこの属性の値を照合し、作者がそのイベントをユーザーに表示すべきと考えたかどうかを判断してください。 |
| `container-busy` | `"true" | "false" | "error"` | `"false"` | 祖先要素への `aria-busy` | 現在の変更は、まだ完全に完了していません。A11y API の BUSY 状態に対する状態変化イベントは、現在 BUSY とマークされているコンテナオブジェクトが BUSY でなくなった時点で発行されます。これは、アトミックリージョンにおいて特に重要です。アトミック領域全体は、それが最終的にビジーでなくなったときに一度だけ表示される必要があります。 |
| `container-atomic` | `"true" | "false"` | `"false"` | 祖先要素への `aria-atomic` | この変更は、常に一度に表示されるべきリージョン内に存在するかどうか。もしそうなら、 member-of リレーションはリージョンのルートを指します（次の章を参照）。 |
| `member-of` | もし `container-atomic=true` ならば、祖先のアクセシブルなオブジェクトを指します（したがって、実際にはオブジェクト属性ではなく、アクセス可能なリレーションとなります）。 | 指定されなかった場合はアトミック領域ではありません。 | 祖先要素への `aria-atomic` | このオブジェクトが存在するアトミックコンテナーのルートを指します。これは常に現在のオブジェクトの祖先となります。 |
| `event-from-input` | `"true" | "false"` （以下で詳述します） | ブラウザーは計算できません。 | 作者の協力は必要ありません。 | このイベントの根本的な原因は、ユーザーの明示的な入力だったのでしょうか？ |

"container-" 接頭辞は、この属性が、そのノードの類似した名前の最終的な計算プロパティが何であるかを記述するため、そのように名付けられています。これは、 AT がこの情報を取得するために、親ノードの連鎖をたどる必要がないことを意味しています。現時点では、 `container-`\_name\_attribute が設定されていないプロパティに対して、 AT は W3C 仕様で定義されている既定値でフォールバックするコードを持たなければなりません。

イベントがユーザーの入力であったかどうかを判断する
-------------------------

これですべてのイベントは、そのイベントがユーザーの入力によって発生したのか、それともウェブページが引き起こしたものなのかについての情報を提供するようになりました。この情報は、それぞれのプラットフォームで異なる形で取得されます。プラットフォームによっては、非同期イベントを使用するものもあるからです。

IAccessible2 では、この情報はオブジェクト属性 "event-from-input" から取得され、 "true" または "false" に設定されることになります。もし、それが表示されていない場合は、何かが間違っていて、 Mozilla はこの情報を提供することができなかったということです。この情報は、 EVENT\_SHOW、EVENT\_HIDE、IA2\_EVENT\_TEXT\_INSERTED、IA2\_EVENT\_TEXT\_REMOVED に対してのみ利用できます。

ATK/AT-SPI では、この情報はイベント名を調べることによって取得さ れます。イベント名に ":system" が付与されている場合、それはユーザー入力によるものではありません。 children-changedと text-changedイベントについては、":system "文字列が計算されます。

なぜこれが有益なのでしょうか？ AJAX ページの大部分は、ライブリージョンマークアップを提供しませんが、それでも可能な限り使用可能である必要があります。画面の内側からリーダーにとって、ページ上の変更でユーザーを中断させるタイミングを決めるのは困難です。もし、スクリーンリーダーが自動的に多くを読み取ったら、ウェブページは使用するのに煩わしすぎるでしょう。スクリーンリーダーが何らかの読み取りをしない場合、ユーザーは重要な情報を見逃してしまう可能性があります。

この情報はヒューリスティックに有益な情報を使用すると考えられています。多くの場合、ユーザーのキーストロークによって直接発生したページの変更は、読み取られるべきです。これらはユーザーが行っていることと同期しているため、ユーザーを混乱させることなく読み取ることができる可能性が高い。ユーザーが次のキーを押すと、音声はそのキーのエコーに移動します。スクリーンリーダーでは、変更の型、変更の大きさ、変更が発生した場所など、他にも考慮したい要素があります。これは、スクリーンリーダーの技術革新の可能性がある分野です。

| 直近の出来事 | ユーザーからの入力？ |
| --- | --- |
| キー押下 | はい |
| マウスクリック | はい |
| マウスホバー | いいえ |
| ページ読み込みイベント | いいえ |

フォーカスの変化、タイマーのコールバック、 XMLHttpRequest のコールバックなど、それ以外のものはすべて中立です。それらは、それらが起こった元の理由がユーザー入力によるものであった場合のみ、ユーザー入力としてカウントされます。

スクリーンリーダーが何を提示すべきか？
-------------------

WAI-ARIA スクリーンリーダー実装者ガイド (en-US)のライブリージョンの節をお読みください。