命名はじめにこの取り組みの目的は、Webプラットフォームへの追加機能を開発して、開発者が支援技術APIに情報を提供できるようにし、ブラウザーがそれらのAPIに提供する情報を理解することです。モチベーションとなるユースケース既存のAPIの背景は付録で見つけることができる。ウェブ上でできることの境界を押し広げているウェブアプリケーションは、APIが不十分なためそれらをアクセシブルにするため苦闘している。ブラウザとやりとりするネイティブAPIと比較して表現力に劣っている。現在、ウェブコンポーネントのデフォルトセマンティクスを定義するにはARIAを使用しなければならない。これにより、真に詳細な実装であるARIA属性がDOMに「リーク」してしまう。それはUIに応じて、数百ないしは数千もの要素のうち、一つを参照するかもしれない。この要求は、多くの余分なDOMの属性が必要となり、これらのAPIを複雑にする。ようなユーザーアクションによって引き起こされる。要素を用いたリモートデスクトップのストリーミングなどを表現するなどそのためには、少なくとも要素と同じようなアクセシビリティプロパティや、他の仮想ノードとの親/子/その他の関係性、位置や次元を表す必要がある。開発者は現在、ARIAやその他のアクセシビリティプロパティがどのように適用されているかを調べたりテストする方法を持っていない。(AOM)は、上記のユースケースに取り組むためのHTMLや関連する標準に対する一連の変更である。以前のバージョンのAOMに慣れ親しんでいれば、AccessibleNodeに何が起こったのか?と疑問を持つかもしれない。属性をHTML要素に反映する。1.2の仕様の一部となった。要素の参照を反映するARIAプロパティの直接的反映。ような関係属性の文字列に反映させる。aria-describedby="id1">要素を参照する非反映のプロパティでAPIを拡張することを提案する。ownedElement1;これにより、関係に属するそれぞれの要素にグローバルに固有なID属性を割り当てることなく要素間のセマンティクスの関係性を示すことができる。HTML仕様の変更として提案されている。</custom-optionlist></custom-combobox>これは失敗で、なぜならIDREFsはshadowRoot、またはそれらが現れる文書の文脈の範囲に限られる。著者は代わりにこの関係性をプログラムで示すことができる。optionList.firstChild;このことにより、関係が自然に表現されるようになる。#3513で議論されている。オプションを用いて静的なデフォルトセマンティクス、または設定されたコールバックを用いて動的に要素ごとのセマンティクスを提供できることを提案する。非反映のデフォルトアクセシビリティプロパティをウェブコンポーネントに設定する今、ウェブコンポーネントを制作するライブラリの著者はネイティブ要素にとっては暗黙であるセマンティクスを表すためにARIA属性を「生やす」ことを強いられている。オブジェクトを利用して、不変のデフォルトセマンティクスをカスタム要素に提供することもできる。オブジェクトに設定されたプロパティは、カスタム要素をアクセシブルなオブジェクトにマッピングする際に、デフォルトの値として利用される。これは「不変なクラス変数」を作るのに類似している。これらのセマンティクスプロパティはカスタム要素の定義に関連付けられていて、カスタム要素のインスタンスには関連していない。カスタム要素のインスタンスに適用される。カスタムタブコントロールを作成する著者は、タブ、タブリスト、タブパネルの3つのカスタム要素を個々に定義することができる。アクセシビリティツリーにマッピングされるとき、タブのロールがデフォルトでマッピングされる。要素がデフォルトでボタンのロールを持ってアクセシビリティオブジェクトにマッピングされるのに似ている。オブジェクトを、ユーザーインタラクションに応じてカスタム要素のインスタンスのセマンティクスの状態を変更するのに利用できる。オブジェクトにセットされたプロパティはアクセシビリティオブジェクトに要素をマッピングされる際に利用される。これは「インスタンス変数」を設定するのに類似している。セマンティクスプロパティのコピーはカスタム要素のインスタンス毎に作られる。それぞれに定義されたセマンティクスは関連するカスタム要素のインスタンスオブジェクトにのみ関連付けられる。});これらの要素を使用する著者は通常通りARIAを用いてデフォルトセマンティクスを上書きすることができる。要素の見た目を縦並びに変更できる。属性を追加することで、カスタム要素に定義されているデフォルトセマンティクスを上書きすることができる。3</custom-tab></div>著者が提供するロールがデフォルトのロールを上書きするので、それぞれの場合においてマッピングされるロールは著者が提供するロールに基づく。仮に著者によって提供されたセマンティクスがカスタム要素のセマンティクスと競合する場合でも著者が提供するセマンティクスが優先される。支援技術からのユーザーアクションイベント支援技術ユーザーのプライバシーを保護するために、通常、支援技術からのイベントは合成されたDOMイベントを発生させる。上記の関連する支援技術のイベントに対応した有効なターゲットの文脈の中で発生したときに合成される。イベントがフォーカスされた要素で発火される。支援技術からのイベントをリッスンする例えば:ユーザーは音声制御ソフトウェアを利用しており、ウェブページの中のどこかのボタンの名前を読み上げられる。送信することができる。同じユーザーはあるページをスクロールダウンする音声コマンドを発行する。モバイルスクリーンリーダーユーザーは、スライダーに移動し、範囲に基づいたコントロールを増加させるジェスチャーを実行することができる。現在、ブラウザーはネイティブHTML要素の組み込みサポートを実装することによって、アクセシビリティアクションを一部実装している。増加・減少アクションをサポートし、テキストボックスは値を設定したりテキストを挿入するアクションをサポートしている。)しかしウェブページの著者がカスタムエレメント上のアクセシビリティアクションをリッスンする方法が無い。上ではiOSのVoiceOverでは増加・現象のためにスワイプアクションを促す提案がされるが、いかなるウェブAPIもそのセマンティックイベントを扱うことができない。開発者はセマンティックイベントを補足するようなキーボードイベントまたは入力イベントをリッスンすることができるようになるだろう。キーイベントを扱うことができ、同じように支援技術のイベントも扱うことができる。アクセシビリティノードに触れさせられることができる。このメカニズムは、著者がカスタム描画APIのアクセシビリティをよりきめ細かくコントロールするためにネイティブアクセシビリティAPIによく存在する。仮想のアクセシビリティノードを表している。仮想アクセシビリティツリーのルートを形成する。付与されると、暗黙のうちに無視され、DOMの子要素と仮想アクセシブルノードが混在することはない。