インターフェースを作成するものとします。リーダーで使用するために十分な情報を提供します。情報の多くは視覚表示にのみ効果があるため、情報もノードも少なくて済みます。リーダーに提示する内容です。ツリーを取得して、支援技術に使いやすい形式に変更します。年代の古いウェブページのようなイメージです。リーダーのユーザーと同様のエクスペリエンスが得られます。ツリーのインターフェースに非常によく似ています。ツリーは、ほとんどの支援技術で利用されています。フローは次のようになります。支援技術に提供します。インターフェースの表現を作成します。リーダーは、ユーザーがアプリの音声表現を聞き取れるインターフェースを作成します。支援技術は違う方法で、ユーザーがアプリを操作できるようにする場合があります。リーダーは、ユーザーが容易にマウスクリックや指によるタップをシミュレートできるように、フックを提供しています。介してユーザーの目的(「クリック」など)をアプリに伝えます。コンテキストでそのアクションを適切に解釈する必要があります。ウェブブラウザの場合、指示ごとに追加のステップがあります。ブラウザは実際のところ、ブラウザ内部で実行するウェブアプリのプラットフォームだからです。適切なイベントが発行されるようにする必要があります。ブラウザが行う処理はそれだけです。デベロッパーとしての役割は、このような流れを認識したうえで、このプロセスを活用できるウェブページを開発し、ユーザーがアクセスできる環境を整えることです。そのためには、ページのセマンティクスを正しく表現して、ページ内の重要な要素に適切な役割、状態、プロパティが存在し、アクセス可能な名前と説明を指定していることを確認する必要があります。すればブラウザ側で、支援技術がその情報にアクセスして、カスタマイズされたエクスペリエンスを作成できるようにすることが可能です。ツリーに変換できます。要素のアクセシビリティは、自動的に処理されます。ネイティブ要素のように見えるけれども実際は異なる要素を使用することもあります。この「ボタン」は実際にはボタンではありません。作成する方法は数多くありますが、一例を示します。リーダーは知る術がありません。追加して、キーボードのみで操作するユーザーにも使用可能にするという追加の作業が必要になります。現状のコードのままでは、マウスがなければ使用できないからです。要素を使用すれば、この問題は簡単に解決できます。ネイティブ要素を使用すれば、キーボード操作に対応できるというメリットもあります。ネイティブ要素を使用するからといって、魅力的な視覚効果を諦める必要はありません。ネイティブ要素のスタイルを指定して目的の外観を実現し、しかも暗黙的なセマンティクスと動作を維持することができます。使用については説明しましたが、さらに要素の名前を検出可能にする必要があります。つのタイプがあります。すべてのユーザーがこのラベルの意味と要素を関連付けます。視覚的なラベルが不要なときにのみ使用されます。テキストレベルの要素の場合、なにもする必要はありません。定義すれば、なんらかのテキストのコンテンツがあるからです。入力要素やコントロール要素、画像のような視覚的なコンテンツの場合、名前を指定していることを確認する必要があります。チェックリストの最初の項目に挙げられています。推奨案に従い「フォームの入力要素に、関連するテキストのラベルを付ける」ことです。ターゲットにすると、マウスのユーザーにもタッチスクリーンのユーザーにもメリットがあります。ラベルと要素を関連付けるには、次のいずれかを実行します。リーダーは要素にチェックボックスの役割があり、オンの状態で、「プロモーション情報を受け取る」という名前が付いていることを報告できます。リーダーを使用して、ページ内をタブで移動しながら、読み上げられる役割、状態、名前を確認すると、不適切に関連付けられたラベルを見つけることができます。