アクセシビリティ ツリーの概要
ここでは、スクリーン リーダーのユーザー専用のユーザー インターフェースを作成するものとします。ここでは、ビジュアル UI を作成する必要はありませんが、スクリーン リーダーが使用するのに十分な情報を指定するだけです。
ここで作成するのは、DOM API と同様にページの構成を示す一種の API ですが、情報の多くは視覚表示にのみ効果があるため、情報もノードも少なくて済みます。次のような内容になります。
これは基本的に、ブラウザが実際にスクリーン リーダーに提示する内容です。ブラウザは DOM ツリーを取得して、支援技術に使いやすい形式に変更します。この変更したツリーをアクセシビリティ ツリーと呼びます。
ユーザー補助ツリーは、少数の画像、多数のリンク、場合によってはフィールドとボタンなど、90 年代の古いウェブページに似ています。
この場合、ページを目視でスキャンすると、スクリーン リーダーのユーザーと同じようなエクスペリエンスが得られます。インターフェースはありますが、シンプルかつ直接的で、アクセシビリティ ツリーのインターフェースに非常によく似ています。
アクセシビリティ ツリーは、ほとんどの支援技術で利用されています。フローは次のようになります。
- アプリ（ブラウザまたは他のアプリ）は、API を介して UI のセマンティック バージョンをアシスト技術に公開します。
- 支援技術は API を介して読み取った情報を使用し、代替ユーザー インターフェースの表現を作成します。たとえば、スクリーン リーダーは、ユーザーがアプリの音声表現を聞き取れるインターフェースを作成します。
- 支援技術によって、ユーザーは別の方法でアプリを操作することもできます。たとえば、ほとんどのスクリーン リーダーは、ユーザーが容易にマウスクリックや指によるタップをシミュレートできるように、フックを提供しています。
- 支援技術は、アクセシビリティ API を介してユーザーの目的（「クリック」など）をアプリに伝えます。アプリは、元の UI のコンテキストでアクションを適切に解釈します。
ウェブブラウザの場合、指示ごとに追加のステップがあります。ブラウザは実際のところ、ブラウザ内部で実行するウェブアプリのプラットフォームだからです。そのためブラウザは、ウェブアプリをアクセシビリティ ツリーに変換し、支援技術から受け取ったユーザーのアクションに基づいて、JavaScript で適切なイベントが発行されるようにする必要があります。
しかし、ブラウザが行う処理はそれだけです。ウェブ デベロッパーとしての役割は、このような流れを認識したうえで、このプロセスを活用できるウェブページを開発し、ユーザーがアクセスできる環境を整えることです。
そのために、Google はページのセマンティクスを正しく表現しています。つまり、ページの重要な要素に適切な役割、状態、プロパティが与えられ、わかりやすい名前と説明が指定されているようにします。そうすればブラウザ側で、支援技術がその情報にアクセスして、カスタマイズされたエクスペリエンスを作成できるようにすることが可能です。
ネイティブ HTML のセマンティクス
DOM の多くはセマンティックな意味を暗黙的に持つため、ブラウザで DOM ツリーをアクセシビリティ ツリーに変換できます。つまり、DOM は、ブラウザによって認識され、さまざまなプラットフォームで予測可能な形で動作するネイティブ HTML 要素を使用します。よって、リンクやボタンといったネイティブ HTML 要素のユーザー補助機能は、自動的に処理されます。この組み込みのユーザー補助機能を活用するには、ページ要素のセマンティクスを表す HTML を記述します。
ただし、ネイティブ要素のように見えるけれども実際は異なる要素を使用することもあります。たとえば、この「ボタン」はボタンではありません。
HTML で作成する方法はいくつかありますが、その 1 つを以下に示します。
<div class="button-ish">Give me tacos</div>
実際のボタン要素を使用しない場合、スクリーン リーダーはそれが何からアクセスされたかを知ることができません。また、tabindex を追加して、キーボードのみで操作するユーザーにも使用可能にするという追加の作業が必要になります。現状のコードのままでは、マウスがなければ使用できないからです。
この問題は、div ではなく通常の button 要素を使用すると簡単に修正できます。ネイティブ要素を使用すると、キーボード操作を処理するというメリットもあります。また、ネイティブ要素を使用するからといって、洗練された視覚効果を失う必要はありません。ネイティブ要素のスタイルを設定すれば、意図したとおりに見えるようにしつつ、暗黙的なセマンティクスと動作を維持できます。
先ほど説明したとおり、スクリーン リーダーは要素の役割、名前、状態、値を通知します。適切なセマンティクス要素、役割、状態、値の使用については説明しましたが、さらに要素の名前を検出可能にする必要があります。
大まかに、名前には以下の 2 つのタイプがあります。
- 表示可能なラベル。すべてのユーザーがこのラベルの意味と要素を関連付けます。
- 代替テキスト。視覚的なラベルが不要な場合にのみ使用されます。
テキストレベルの要素の場合、なにもする必要はありません。定義すれば、なんらかのテキストのコンテンツがあるからです。ただし、入力要素やコントロール要素、画像のような視覚的なコンテンツの場合、名前を指定していることを確認する必要があります。実際、テキスト以外のコンテンツに代替テキストを指定することは、WebAIM チェックリストの最初の項目に挙げられています。
その方法の 1 つは、推奨案に従い「フォームの入力要素に、関連するテキストのラベルを付ける」ことです。ラベルと、チェックボックスなどのフォーム要素を関連付ける方法は 2 つあります。いずれかの方法で、ラベルテキストをチェックボックスのクリック ターゲットにすると、マウスのユーザーにもタッチスクリーンのユーザーにもメリットがあります。ラベルと要素を関連付けるには、次のいずれかを実行します。
- ラベル要素内に入力要素を配置する
<label>
<input type="checkbox">Receive promotional offers?
</label>または
- ラベルの
for属性を使用して、要素のidを参照する
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
チェックボックスのラベルを適切に設定すると、スクリーン リーダーは要素にチェックボックスの役割があり、オンの状態で、「プロモーション情報を受け取る」という名前が付いていることを報告できます。
