ARIA: 毒か解毒剤か？

スクリーン リーダーに嘘をついていけば、アクセシビリティは向上します。

ARIA とは

ARIA を使用すると、ウェブ作成者はスクリーン リーダーでしか見ることのない代替現実を作成できます 🤥?

ウェブ コンテンツで起きていることについて、真実について話したり、スクリーン リーダーに対して真実に「嘘」をついたりすることが必要な場合もあります。たとえば、「フォーカスはここにある」、「これは本当にスライダーだ！」などです。これは、ワークベンチのツールやウィジェットの上に魔法の付箋を貼るようなものです。この魔法のような付箋は、誰もがそこに書かれていることを信じさせます。

魔法の付箋が存在する場合、それによって、各ツールが何であるか、またはツールに関する Google の考えがオーバーライドされます。例: 「ここにあるものはグルーガンだ！」実は作業台の上に空の青い箱が置いてあるのに、魔法のような付箋のおかげで、グルーガンだとわかります。「30% も充電されています」と付け加えることもできます。30% フルのグルーガンがあることがスクリーン リーダーによって報告されます。

これと同等のウェブでは、内部に画像を含むプレーンなボックス要素（div）を取得し、ARIA を使用して 100 点満点中 30 点の値のスライダーを指定します。

ARIA とは

ARIA は、ウェブページの外観やマウスまたはキーボード ユーザーの動作には影響しません。 ARIA との違いに気付くのは、支援技術を使用しているユーザーのみです。ウェブ デベロッパーは、支援技術を使用していないユーザーに影響を与えることなく、任意の ARIA を追加できます。

ARIA はキーボードのフォーカスやタブの順序には何も機能しません。これはすべて HTML で行われ JavaScript で微調整されることもあります

ARIA の仕組み

ブラウザは、スクリーン リーダーなどの支援技術によって各要素に関する情報を要求されます。ARIA が要素に存在する場合、ブラウザは情報を取り込み、その要素についてスクリーン リーダーに伝える内容を変更します。

ARIA が選ばれる理由

なぜユーザーに嘘をついたくなるのでしょうか？

地元のウェブストアで必要なウィジェットが一部のみ販売されているとします。でも、あの MacGyver なんだ。他のウィジェットから独自のウィジェットを 作成するだけですちなみに、MacGyver で最も使用されている 7 つのものは、スイス アーミー ナイフ、ガム、靴ひも、マッチ、ペーパークリップ、誕生日キャンドル、ダクトテープです。彼はそれらを使って、単に置き場所にならないように、爆弾などのものを作っています。これは、ウェブ作成者がメニューバーを作成する必要がある場合とよく似ています。メニューバーは、HTML の一部のように思えるほど便利ですが、そうではありません。なるほど。著者がリンクやボタンに満足するとは思わなかった？作成者は、div、画像、スタイル、クリック ハンドラ、キープレス ハンドラ、spit、ARIA などの使い慣れたツールを使用して、1 つをまとめます。

ARIA を最大限活用するのではなく、単に拡張機能として使用することもあります。基本的には、すでに正常に動作している HTML に ARIA を少し追加すると便利です。たとえば、フォーム コントロールで、無効な入力に関連するエラー メッセージ アラートを指し示すことができます。テキストボックスが検索用であることを示す 場合もあるでしょうこうした小さな調整で、通常のウェブサイトをスクリーン リーダーで操作しやすくなります。

メニューバーの例

マウス クリックを使用するユーザーのサポート

一緒にメニューバーを作成しましょう。多くのアイテムは div と呼ばれる汎用のボックス要素に表示されます。ユーザーが div をクリックするたびに、対応するコマンドが実行されます。マウスでクリックする人なら 問題なく機能するでしょう

次に、見栄えを良くします。そこで、CSS（スタイル）を使用して、要素を適切に配置し、要素の周囲に視覚的なアウトラインを設定します。他のメニューバーと同じように、これがメニューバーであり、その使い方を直感的に認識できるようにします。メニューバーでは、マウスオーバーしたアイテムに異なる背景色が使用されるため、視覚的なフィードバックをユーザーに提供できます。

一部のメニュー項目は親です。子サブメニューを生成する。ユーザーがこれらのいずれかにカーソルを合わせると、子サブメニューをスライドするアニメーションが開始されます。

もちろん、HTML 標準ウィザードではウェブ作成者が必要とするものをすべて追加できるわけではないことが主な理由として、ウェブの多くのケースがそうであるように、こうした要素にはアクセスできません。たとえそれができたとしても、ウェブ作成者は常に独自の特別版を作りたいと思うでしょう。

メニューバーのキーボード アクセスを可能にする

ユーザー補助への第一歩として、キーボード ユーザー補助機能を追加しましょう。このパートでは HTML のみを使用し ARIA は使用しません支援技術なしでは、ARIA は外観、マウス、キーボードなどの主要な要素には影響しません。

ウェブページがマウスに反応するように、キーボードにも反応できます。Google の JavaScript は、発生したすべてのキー入力をリッスンし、そのキー操作が有益かどうかを判断します。そうでなければ、小さすぎて食べられない魚のようにページに戻ります。次のようなルールがあります。

• ユーザーが矢印キーを押した場合、独自の内部メニューバーのブループリントを確認して、新しいアクティブなメニュー項目を決定しましょう。現在のハイライトを消去し、新しいメニュー項目をハイライト表示して、目の見えるユーザーが現在地を視覚的に把握できるようにします。ウェブページは event.preventDefault() を呼び出して、ブラウザが通常のアクション（この場合はページのスクロール）を実行しないようにする必要があります。
• ユーザーが Enter キーを押した場合、クリックと同様に扱い、適切なアクションを実行します（別のメニューを開くこともできます）。
• 他の操作をするべきキーをユーザーが押しても、それを食べてはいけません。 意図したとおりにページに戻します。たとえば、メニューバーには Tab キーが必要ないため、これを返してください。これを正しく行うのは難しく、作成者はしばしば混乱を招きます。たとえば、メニューバーには矢印キーが必要ですが、Alt+矢印または command+矢印キーは不要です。これらは、ブラウザタブの閲覧履歴内の前または次のページに移動するためのショートカットです。作成者が注意を怠ると、これらはメニューバーに出力されます。この種のバグは頻繁に発生しますが ARIA はまだ使用を開始していません

メニューバーへのスクリーン リーダーのアクセス

メニューバーは、粘着テープと div を使って作られています。そのため、スクリーン リーダーはそれが何であるかを認識しません。アクティブなアイテムの背景色は色のみです。メニュー項目の div は、特別な意味を持たない単なるプレーン オブジェクトです。したがって、メニューバーのユーザーには、どのキーを押しているのか、どのアイテムに押されているのかについて指示を得られません。

しかし、これは不公平です。メニューバーは、目の見えるユーザーに対しては問題なく機能します。

ARIA を導入しました。ARIA を使用すると、メニューバーにフォーカスが置かれているスクリーン リーダーのように操作できます。作成者がすべて正しく処理していれば、カスタム メニューバーは、デスクトップ アプリケーションのメニューバーと同様に、スクリーン リーダーを認識します。

1 つ目は ARIA の嘘です。aria-activedescendant 属性を使用して、現在アクティブなメニュー項目の ID に設定し、変更するたびに慎重に更新するようにします。例: aria-activedescendant="settings-menuitem"。この小さな白いライによって、スクリーン リーダーは ARIA アクティブ アイテムをフォーカスと見なし、読み上げられるか、点字ディスプレイに表示されます。

aria-activedescendant に戻ります。これを使用して、フォーカスされているメニューバーから特定のメニュー項目を指し示すことで、スクリーン リーダーはユーザーがどこに移動したかを認識しますが、オブジェクトに関するその他の情報は把握しません。この div とは一体何なのでしょうか。ここでロール属性を使用します。含まれる要素全体に対して role="menubar" を使用し、次にアイテムのグループに対して role="menu" を使用し、個々のメニュー アイテムに対して ... drumroll ... に対して role="menuitem" を使用します。

また、メニュー項目が子メニューにつながる可能性がある場合はどうすればよいでしょうか。ユーザーはそれを知る必要があります。目の見えるユーザーの場合、メニューの最後に三角形の小さな画像が表示されることがありますが、少なくともこの時点では、スクリーン リーダーは画像を自動的に読み取る方法を知りません。展開可能な各メニュー項目に aria-expanded="false" を追加すると、1）展開可能なものがあり、2）現在展開されていないことを示すことができます。さらに、作成者は三角形の img に role="none" を付けて、説明用としてのみ使用することを示す必要があります。これにより、スクリーン リーダーは、せいぜい冗長で、場合によっては不快な画像について、何も言わないようにします。

バグへの対応

キーボードのバグ（HTML!）

キーボード アクセスは主要な HTML の一部ですが、キーボード ナビゲーションをあまり使用しなかったり、適切に設定したりするための微妙な違いがあるために、作成者は常に混乱させています。

バグの例:

• チェックボックスはスペースキーを使用して切り替えていますが、作成者が preventDefault() の呼び出しを忘れています。これで、スペースバーによりチェックボックスとページダウンの両方が切り替わるようになります。これは、スペースバーのデフォルトのブラウザ動作です。
• ARIA モーダル ダイアログがタブ ナビゲーションを内部にトラップしようとし、作成者がブラウザへの Ctrl+Tab アクセスを明示的に許可し忘れている。現在は、Ctrl+Tab キーでダイアログ内を移動するだけで、ブラウザでタブが切り替わることは想定されていません。全然
• 作成者は選択リストを作成し、up/down を実装しますが、home/end/pageup/pagedown または最初の文字のナビゲーションは実装しません。

作成者は既知のパターンに従うべきです。詳しくは、リソース セクションをご覧ください。

キーボード アクセスのみの問題の場合は、スクリーン リーダーを使わないか、仮想ブラウザモードをオフにしてみることもおすすめします。通常、キーボードのバグを見つけるためにスクリーン リーダーは必要ありません。キーボード アクセスは実際には ARIA ではなく HTML で実装されます。結局のところ、ARIA はキーボードやマウスの動作といった基本的なものには影響せず、ウェブページの内容や現在フォーカスされているものなどはスクリーン リーダーにのみ影響します。

キーボードのバグは、ほとんどの場合、ウェブ コンテンツ、特に HTML や JavaScript のバグであり、ARIA のバグではありません。

ARIA のバグ: なぜこんなに多くのバグがあるのでしょうか？

作成者が ARIA を誤った場所は多数あり、それぞれが完全な破損やわずかな差異の原因となります。わかりにくい問題はおそらく、著者は公開前にそのほとんどを把握しないため、さらに悪いことでしょう。

結局のところ、作成者がスクリーン リーダーの使用経験がないと、ARIA になんらかの問題が発生します。メニューバーの例では、「menuitem」が正しい場合、「option」ロールが使用されることになるはずです。aria-expanded の使用を忘れたり、適切なタイミングで aria-activedescendant を設定およびクリアしたりするのを忘れたり、他のメニューを含むメニューバーを忘れたりする可能性があります。メニュー項目の数についてはどうでしょうか。通常、メニュー項目はスクリーン リーダーによって「項目 3/5」のように表示されるため、ユーザーはメニュー項目の場所を把握できます。通常、これはブラウザによって自動的にカウントされますが、場合によっては、ブラウザとスクリーン リーダーの組み合わせによって誤った数値が計算される可能性があるため、作成者はこれらの数値を aria-posinset と aria-setsize でオーバーライドする必要があります。

これがメニューバーですウィジェットの種類を考えてみてください。ARIA の仕様や作成方法を確認してください。パターンごとに、ARIA が不正使用される方法は 10 通りあります。ARIA は、作成者の作業内容を把握します。作成者のほとんどがスクリーン リーダーのユーザーではないことを考えると、どのような問題が発生する可能性があるでしょうか。

つまり、実際のスクリーン リーダーのユーザーが ARIA ウィジェットを試すことは、出荷可能と見なされる前に 100% 必要です。ニュアンスが多すぎます。ブラウザとスクリーン リーダーをさまざまな組み合わせで試行することが理想的です。実装上のさまざまな点と不完全な実装があるためです。

まとめ

まとめると、ARIA マジックを使用すると、HTML に含まれるあらゆる要素をオーバーライドまたは追加できます。 ユーザー補助の表示を微調整したり、エクスペリエンス全体を作成したりするために使用できます。そのため、ARIA は非常に強力であると同時に、通常はスクリーン リーダー自体を使用しないフレンドリーなローカル ウェブ作成者の手に渡っても危険にさらされます。

ARIA は単なる真実のオーバーライド マークアップ レイヤです。何が起こっているのかをスクリーン リーダーに尋ねると、ARIA が存在する場合、実際の基盤となる真実ではなく ARIA バージョンの真実が取得されます。

追加条項 1: 参考情報

キーボード情報とコードサンプルによるハイブリッド リファレンス

• W3C の ARIA オーサリング プラクティス: 各例の重要なキーボード ナビゲーション特性について説明し、機能する JS/CSS/ARIA コードを提供します。例は、現在有効な機能に焦点を当てており、モバイルは取り上げていません。

追加条項 2: ARIA の用途

ARIA は大小の信頼できる情報を置き換えたり補完したりできるため、一般的にスクリーン リーダーが重視する内容を指定する場合に便利です。

ARIA の一般的な用途は次のとおりです。

• メニューバー、オートコンプリート、ツリー、スプレッドシートなど、HTML には存在しない特別なウィジェット
• HTML に存在するウィジェットですが、作成者が独自に考案したものです。これは、通常のウィジェットの動作や外観を微調整する必要があるためと考えられます。たとえば、HTML の <input type="range"> 要素は基本的にはスライダーですが、作成者はデザインを変えたいと考えているとします。ほとんどの場合は CSS も使用できますが、input type="range" の場合、CSS は使いづらいです。作成者は独自のスライダーを作成し、そのスライダー上で role="slider" と aria-valuenow を使用して現在の値を示すことができます。
• ライブ領域は、スクリーン リーダーに「ページのこの領域で、変更内容をユーザーに伝える価値がある」ことを通知します。
• ランドマーク（HTML に同等のものが追加されました）。これは、スクリーン リーダーのユーザーが必要な情報をすばやく見つけられるようにするという点で、見出しのようなものです。ただし、関連する領域全体を含むという点で異なります。たとえば、「このコンテナはページのメインエリアです」、「このコンテナはナビゲーション パネルです」などです。

追加条項 3: Accessibility API とは

Accessibility API は、スクリーン リーダーなどの AT がページの内容と現在の状況を把握する方法です。たとえば、MSAA、IA2、UIA などです。それは Windows だけなのです。Accessibility API は 2 つの部分から構成されています。

• コンテナ階層を表すオブジェクトの「ツリー」。これはロシアの入れ子人形に似ていますが 1 つの人形に複数の他の人形を含めることができますたとえば、ドキュメントには大量の段落が含まれ、1 つの段落にはテキスト、画像、リンク、太字などが含まれます。オブジェクト ツリーの各項目には、ロール（自分とは何？）、名前/ラベル、ユーザー入力値、説明などのプロパティや、フォーカス可能、フォーカス、必須、オンなどのブール値状態があります。ARIA はこれらのプロパティをオーバーライドできます。スクリーン リーダーは、このツリーを使用して、ユーザーが仮想バッファモードで移動できるようにします（「次の見出しに移動してください」など）。
• ツリーの変更を説明する一連のイベント（「フォーカスがここにある」など）。スクリーン リーダーはイベントを使用して、何が起こったかをユーザーに伝えます。重要な HTML または ARIA マークアップが変更されると、何かが変更されたことをスクリーン リーダーに知らせるイベントが発生します。

通常、作成者は HTML のみを使用します。HTML は、これらのユーザー補助 API にうまく対応しています。HTML が十分でない場合、ARIA が使用され、ブラウザは HTML セマンティクスをオーバーライドしてから、オブジェクト ツリーまたはイベントをスクリーン リーダーに送信します。