ようなインタラクティブなロールであってもよい。ユーザーは支援技術を介して、様々なレベルでアクセシビリティツリーを探索することができる。かれらは、ランドマーク要素のようなユーザーのページのセクションへの移動を助けるグループ化されたノードとやり取りすることができたり、ボタンのようなインタラクティブなノードとやり取りすることができる。呼ばれる)を必要とする。ボタンは「OK」や「メニュー」というラベルを持つ。"focused"など)の状態の情報を持つことができる。アクションを公開する。各アクセシビリティAPIにおいて少しずつ違いはるが、概念的にはほとんど似ている。APIを通じてのみである。DOMツリーは並行して主にページの視覚的な表現とアクセシビリティツリーに変換される。アクセシビリティAPIを介してアクセスされる。異なるプラットフォーム間で複数のアクセシビリティAPIをサポートしているブラウザもあれば、特定のアクセシビリティのみをサポートしているブラウザもある。少なくとも1つのネイティブアクセシビリティAPIをサポートするブラウザはセマンティックの情報構造ツリーを公開するためのメカニズムを持っている。このAPIの目的のため、実装の詳細は気にせずそれらのAPIを参照する。ネイティブHTMLをアクセシビリティツリーにマッピングするネイティブHTML要素はアクセシビリティAPIに暗黙的にマップされる。属性(があれば)によってラベリングされる。ARIAまた、ARIAを利用することで開発者が属性によって要素に注釈をつけ、要素のデフォルトのロールやセマンティックプロパティを上書きすることができるが、アクセシビリティアクションは公開できない。どちらの場合も、DOMノードとアクセシビリティツリー内のノードは1対1で対応しており、対応するアクセシビリティノードのセマンティクスにたいする最小限の細やかな制御ができる。この名前を選ぶ際、簡潔さと明確さ、そして普遍性の間のバランスを取ろうとした。名前は仕様の範囲を制限したり狭め過ぎたりしてはいけない以下に、真剣に提案されたすべての名前のそれぞれの長所と短所を簡潔にまとめた。以下の名前への投票や違う名前の提案は歓迎しているが、まずは既存の提案とその懸念点を慎重に考慮してほしい。大筋で合意には至っており、完璧な命名にしようとするよりはむしろ世に出すよう努めていきたい。