仮想ノードは通常位置と寸法を明示的に設定する必要がある。設定しない場合、アクセシブルノードの親を基準として解釈される。属性を設定することができる。DOM要素に設定するのに似ている。true;仮想アクセシブルノードはデフォルトではフォーカスできない。virtualNode.focus();仮想アクセシブルノードがフォーカスされたとき、DOMのフォーカスは変わらない。document.activeElementも変わらない。DOM要素のフォーカスが変わった時、アクセシブルフォーカスも追従し、DOM要素に関連付けられたアクセシブルノードがフォーカスされる。APIは著者に、完全な計算されたアクセシビリティツリーにアクセスすることを許可する。それぞれのDOM要素に関連付けられたアクセシビリティノードのすべての計算されたプロパティに加え、仮想ノードを含む計算された木構造を走査可能にする。このことは次のことを可能にする:ページ、または要素のセマンティックプロパティが確からしいかを確認するプログラムによるテストを書くことブラウザーベースの信頼できる支援技術の構築。アクセシビリティツリーを利用したスクリーンリーダー、スクリーンルーペ、または他の支援機能を持ったブラウザー拡張やページ内ツール。アクセシビリティプロパティが(ARIAなどを通じて)要素に正しく適用されたかを検査する。ブラウザが特定のバージョンのARIAに対応しているかを検査できる。アクセシビリティツリーの問題をコンソールベースでデバッグしたりチェックしたりする。アクセシビリティツリーの状態に反応する。要素に表されたロールを検査したり、アクセシブルなヘルプテキストを変更したりなど。現在、アクセシビリティツリーはブラウザ間で標準化されていない。それぞれのアクセシビリティツリーの計算は実装がわずかに異なる。このAPIが役に立つには、ブラウザ間で一貫して動作することが必要で、開発者はそれぞれに特別なコードを書く必要がない。我々はツリーがどのように計算され表現されるかについて合意ができるよう十分な時間をかけていきたいと考えている。多くのアクセシビリティプロパティを計算するにはレイアウトが必要となる。ウェブ制作者に単純なプロパティアクセスと同期してアクセシビリティプロパティの計算された値を調べることを許可すると、パフォーマンスのボトルネックに混乱をもたらしてしまう。インターフェースの一部を意味しない非同期的なメカニズムを作成したいと考えている。前の3つと比較して計算されたアクセシビリティツリーにアクセスすることはユーザーに与える影響が最小限となる。優先順位の構成要素の考え方の元、このことに最後に取り組むことは理にかなっている。このAPIの対象者このAPIは主に、ウェブアプリの多くを動かしているJavaScriptフレームワークやウィジェットライブラリーを制作、メンテナンスしている比較的少数の開発者に興味を持たれるだろう。それらのフレームワークやライブラリーにとってアクセシビリティは、可能な限り幅広く多様な文脈で使用されるようになるため、重要な目標の一つである。低レベルのAPIによって彼らは制約やバグを回避し、彼らの制作したコンポーネントを使用する開発者のためにクリーンな高レベルのインターフェースを提供できるようになる。このAPIはウェブプラットフォームの境界を押し広げるような巨大なフラッグシップウェブアプリの開発者をも対象としている。これらのアプリの開発チームでは、Canvasのような低レベルAPIを利用してでもパフォーマンスを向上させたがっていることがしばしばある。そのような開発チームだと、アクセシビリティを優先するだけのリソースもあるが、既存のAPIでは非常に面倒である。AccessibleNodeに何が起こったのか?当初の意図としては、これまでのユースケースを読み書き可能なAPIにまとめるものだった。関連付けられているという点でDOMに似ていた。これはドキュメントオブジェクトモデルと似たようなアクセシビリティオブジェクトモデルと命名された。議論が進むにつれこのモデルにはいくつかの問題があることがわかってきた。アクセシビリティツリーを計算することは、それを変更するために必要にはならない。排他的に使用して関係性を表現することは分かりにくかったこれらの問題により、APIをもともと対処するつもりだったユースケースに基づいて再評価、そして簡素化することとなった。次のステップアクセシビリティオブジェクトモデルの開発は、現在の主要なブラウザベンダーを代表した編集者のチームがリードしている。GitHub上で問題を報告することができる。(WICG)の一部としてこの仕様の開発は継続するつもりだが、時が経てば自身のコミュニティグループに開発が移るかもしれない。Initiativeの現在の活動からは全体的にほとんど独立している。ARIAがWeb上のアクセシビリティプロパティのための構造的なマークアップとセマンティクスを定義している際には、しばしば支援技術のベンダーやネイティブプラットフォームのAPIと調整をしなければならないが、AOMは単に開発者のためにより低レベルの制御ができる並列のJavaScriptのAPIを提供し、ウェブプラットフォームのギャップを埋めるにとどまり、新しいセマンティクスを導入することは無い。O’Connorに多大な感謝を。現在は積極的に参加していないが、この仕様の最初の草案に貢献した。支援技術とアクセシビリティツリーこの仕様の中で支援技術は、アプリケーションの既存のUIを補強したり置き換えたりする第三者のアプリケーションのことを指す。知られた例の一つとしてスクリーンリーダーがある。スクリーンリーダーは視覚的でポインターベースのUIを、聴覚出力(音声、およびトーン)と、キーワード、ジェスチャーの両方、またはいずれかによる入力メカニズムに置き換える。多くの支援技術は、アクセシビリティAPIを通じてウェブページとやりとりする。XのNSAccessibilityなどがある。これらのAPIを利用するとアプリケーションのインターフェースを示すオブジェクトのツリーを公開することができる。アプリケーションウィンドウのことを示すルートノードから、個々のインタラクティブな要素まで様々なレベルのノードがグループ化されている。支援技術がアクセシビリティツリーを使って代替インターフェースを作り、ユーザーの命令で発火したインタラクションイベントが支援技術にルーティングされ、支援技術のユーザーはほぼこのAPIを通じてアプリケーションとやりとりをする。(例えば、キーボードショートカット、ジェスチャー、点字ルーティングキー、スイッチ機器、音声入力など)は完全に支援技術の責務で、アプリケーションの役割ではない。Xのネイティブアプリケーションを使用するVoiceOverユーザーは、「control、option、スペースバー」キーの組み合わせ押す。それはスクリーンリーダーが現在いるUI要素をクリックするということを示す。これらのキー押下はアプリケーションに渡されることはないが、スクリーンリーダーが受け取り、accessibilityPerformPress()関数を該当のUI要素を示すアクセシビリティノード上で実行する。アプリケーションはプレスアクションを処理し、通常はクリックイベントを処理するコードにルーティングされる。アクセシビリティAPIはテストや自動化でもよく利用される。それらは堅牢で包括的な方法でアプリケーションの状態を調査、またプロセスの外からUIを操作する方法を提供する。通常、アクセシビリティAPIの主な動機は障害を持つユーザーのための支援技術だが、これらのAPIが一般的で多くの用途があることを理解することは重要である。