ARIA: 毒か解毒剤か？

Aaron Leventhal
Aaron Leventhal
X

ARIA とは

ARIA を使用すると、ウェブ作成者はスクリーン リーダーにのみ表示される代替現実を作成できます。

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

魔法の付箋があると、各ツールの機能や用途に関する私たちの考えが覆されます。たとえば、「この物体はグルーガンです」という ARIA を追加します。空の青い箱が置いてあるだけですが、魔法の付箋が接着剤ガンであることを示しています。「30% 使用済みです」と追加することもできます。グルーガンの残量が 30% に達したことがスクリーン リーダーから報告されるようになりました。

ウェブでこれに相当するのは、画像が入った単純な div を取り、ARIA を使用して、値が 100 点満点中 30 点のスライダーであることを示すことです。ARIA は div をスライダーにせず、スクリーン リーダーに「1」と伝えるだけです。

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

ARIA は、キーボード フォーカスやタブ順序に対して実際には何もしません。すべて HTML で行われ、場合によっては JavaScript で微調整されます。

ARIA の仕組み

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

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

  • 予測入力、ツリー、スプレッドシートなど、HTML には存在しない特別なコンポーネントを追加する。
  • HTML に存在するコンポーネントを追加しますが、標準要素の動作や外観を変更したいために、作成者が再発明することを決定した可能性があります。たとえば、HTML の <input type="range"> 要素は基本的にスライダーですが、作成者はスライダーとは異なる外観にしたい場合があります。
    • ほとんどの場合、これは CSS で対処できます。一方、range の場合、CSS は awkwARD です。作成者は独自のスライダーを作成し、role="slider" と aria-valuenow を使用して、現在の値をキーボードに伝えることができます。
  • ページの領域に関する変更をスクリーン リーダーに伝えるには、Live Region を含めます。
  • 見出しなどのランドマークを作成します。ランドマークを使用すると、スクリーン リーダーのユーザーは必要な情報をすばやく見つけることができます。ランドマークには関連する領域全体を含めることができます。たとえば、「このコンテナはページのメインエリアです」、「このコンテナはナビゲーション パネルです」などです。

ARIA を使用する理由

すでに動作している HTML に ARIA を追加すると便利です。たとえば、無効な入力に対するエラー メッセージ アラートをフォーム コントロールに表示できます。または、テキスト入力の具体的な用途を示す場合もあります。こうした調整により、通常のウェブサイトでスクリーン リーダーが使いやすくなります。

たとえば、ローカルのウェブストアで必要なウィジェットがすべて販売されていない場合、でも、Google は MacGyver です。他のウィジェットから独自のウィジェットを作成できます。これは、メニューバーを作成するウェブ作成者によく似ています。

<nav> 要素は存在しますが、メニューバーは多くの場合、div、画像、ボタン、クリック ハンドラ、キープレス ハンドル、ARIA を使用して作成されます。

マウス ユーザーをサポートする

では、一緒にメニューバーを作成しましょう。div と呼ばれる汎用ボックス要素にアイテムを表示します。ユーザーが div をクリックすると、対応するコマンドが実行されます。マウス クリックで操作できます。

次に、見栄えを良くします。CSS を使用して要素をきれいに並べ、その周りに視覚的なアウトラインを配置します。他のメニューバーと十分に類似しているため、視覚障がいのあるユーザーは直感的にメニューバーであることとその使い方を把握できます。Google のメニューバーでは、マウスが置かれているアイテムの背景色が異なるため、ユーザーに有益な視覚的なフィードバックを提供できます。

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

ウェブ上の多くの機能と同様に、これらはすべてアクセスしにくいものです。

メニューバーのキーボードを操作可能にする

キーボードのユーザー補助を追加しましょう。この場合に必要なのは HTML の変更のみで、ARIA の変更は必要ありません。 ARIA は、支援技術を使用しないユーザーの外観、マウス、キーボードなどのコア要素には影響しません。

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

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

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

メニューバーは、ダクトテープと div で作成されています。そのため、スクリーン リーダーはどの項目がアクティブなのかを認識できません。アクティブな項目の背景色は単なる色です。メニュー項目の div は、特別な意味のない単なるオブジェクトです。そのため、メニューバーのユーザーには、どのキーを押すか、どのアイテムに移動しているかに関する指示は表示されません。

でも、それは不公平です。メニューバーは、視覚に障がいのあるユーザーに対しては正常に動作します。

ARIA が救出されました。ARIA を使用すると、フォーカスがメニューバーにあるようにスクリーン リーダーに見せかけることができます。作成者がすべて正しく処理していれば、カスタム メニューバーはスクリーン リーダーに対してデスクトップ アプリケーションのメニューバーと同じように表示されます。

最初の ARIA の嘘は aria-activedescendant 属性です。アクティブなメニュー項目の ID に属性を設定し、変更されるたびに更新します。例: aria-activedescendant="settings-menuitem"これにより、スクリーン リーダーは ARIA アクティブ アイテムをフォーカスとして認識し、読み上げたり点字ディスプレイに表示したりします。

祖先、親、子孫の説明

子孫という用語は、あるアイテムが別のアイテムの内部に含まれていることを指します。反対の用語は祖先です。つまり、アイテムが祖先に含まれていることを意味します。次のコンテナのアップ/ダウンでは、より具体的な親/子という用語が使用される場合があります。たとえば、内部にリンクを含む段落があるドキュメントについて考えてみましょう。リンクの親は段落ですが、ドキュメントも祖先として含まれています。逆に、ドキュメントに複数の段落の子要素があり、それぞれにリンクが含まれていることもあります。リンクはすべて、祖父母ドキュメントの子孫です。

aria-activedescendant を使用して、フォーカスされているメニューバーから特定のメニュー項目を指すようにすることで、スクリーン リーダーはユーザーの移動位置を認識しますが、それ以外はオブジェクトについて何も把握しません。div って何？このような場合に役立つのがロール属性です。全体については、その要素に role="menubar" を使用します。アイテムのグループには role="menu" を使用し、個々のメニュー項目には role="menuitem" を使用します。

メニュー項目から子メニューに移動できる場合はどうすればよいですか？お客様にはそのことを伝える必要があります。視覚のあるユーザーには、メニューの最後に小さな三角形の画像が表示されますが、少なくとも現時点では、スクリーン リーダーは画像を自動的に読み取る方法を認識していません。展開可能な各メニュー項目に aria-expanded="false" を追加することで、展開可能なものがあるが、展開はされないことを示すことができます。また、美容目的のみであることを示すために、img 三角形に role="none" を追加する必要があります。これにより、スクリーン リーダーが画像について冗長な情報を読み上げるのを防ぐことができます。

キーボードのバグを修正する

キーボード アクセスは HTML のコア機能の一部ですが、簡単に上書きできます。次に例を示します。

  • チェックボックスはスペースキーで切り替えますが、作成者は preventDefault() を呼び出すのを忘れています。これで、スペースキーでチェックボックスが切り替わり、ページが下に移動するようになりました。これは、スペースキーのデフォルトのブラウザ動作です。
  • ARIA モーダル ダイアログは、タブ ナビゲーションをその中にトラップする必要があります。ダイアログ内で Ctrl+Tab を押して新しいタブを開くように明示的に許可し忘れた場合、期待どおりに動作しません。
  • 作成者は選択リストを作成し、上下キーを実装します。ただし、作成者は、Home、End、PageUp、PageDown、最初の文字のナビゲーションを追加する必要があります。

著者は既知のパターンに従う必要があります。詳しくは、リソースをご覧ください。

キーボード アクセスのみの問題の場合は、スクリーン リーダーを使用せずに、または仮想ブラウザ モードをオフにして試すことも有効です。キーボード アクセスは ARIA ではなく HTML で実装されているため、スクリーン リーダーを使用せずにキーボードのバグを検出できます。結局のところ、ARIA はキーボードやマウスの動作には影響しません。代わりに、ウェブページの内容や現在フォーカスされている内容などをスクリーン リーダーに伝えます。

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

なぜこれほど多いのですか？

作成者が ARIA を誤った場合、さまざまな原因が考えられます。間違いがあると、完全に破損するか、微妙な違いが生じます。微妙な問題は、著者が公開前に見つけることはほとんどないため、さらに深刻になる可能性があります。

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

これは単なるメニューバーですウィジェットの種類は数多くあります。必要に応じて、ARIA 仕様または作成方法を確認します。各パターンには、ARIA が誤用される 12 通りの方法があります。ARIA は作成者に作業内容の判断を任せています。ほとんどの作成者はスクリーン リーダーのユーザーではないため、どのような問題が発生する可能性がありますか？

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

概要

ARIA を使用すると、HTML で指定されているすべての要素をオーバーライドまたは追加できます。ユーザー補助の表示を少し変更したり、エクスペリエンス全体を構築したりできます。このため、スクリーン リーダーのユーザーではないデベロッパーが ARIA を使用すると、非常に強力であると同時に危険なこともあります。

ARIA は、他の選択肢をオーバーライドするマークアップ レイヤです。スクリーン リーダーが何が起こっているか尋ねてきたときに、ARIA が存在する場合、ユーザーは ARIA バージョンの真実を受け取ります。

参考情報

W3C の ARIA 作成プラクティスには、各サンプルの重要なキーボード ナビゲーションの特性が記載されており、機能する JavaScript、CSS、ARIA が提供されています。これらの例は、現在機能するものに焦点を当てており、モバイルは対象外です。

Accessibility API とは

ユーザー補助 API は、スクリーン リーダーなどの支援技術がページの内容や状況を把握するためのものです。例としては、MSAA、IA2、UIA があります。Accessibility API には次の 2 つの部分があります。

  • コンテナ階層を表すオブジェクトの「ツリー」。たとえば、ドキュメントには複数の段落を含めることができます。段落にはテキスト、画像、リンク、 テキスト装飾を設定できますオブジェクト ツリー内の各アイテムには、ロール（何ですか？）、名前またはラベル、ユーザー入力値、説明、ブール値の状態（フォーカス可能、フォーカスあり、必須、チェック済みなど）などのプロパティを設定できます。ARIA はこれらのプロパティをすべてオーバーライドできます。
    • スクリーン リーダーは、このツリーを使用して、ユーザーが仮想バッファ モードで移動できるようにします（「次の見出しに移動してください」など）。
  • ツリーに対する変更を記述する一連のイベント（「フォーカスがここに移動しました」など）。スクリーン リーダーは、イベントを使用して、何が起こったのかをユーザーに伝えます。重要な HTML または ARIA マークアップが変更されると、イベントが発生し、スクリーン リーダーに変更があったことを通知します。

HTML は、これらのユーザー補助 API に適切にマッピングされます。HTML では不十分な場合、ARIA を追加すると、ブラウザはオブジェクト ツリーまたはイベントをスクリーン リーダーに送信する前に HTML セマンティクスをオーバーライドできます。