ARIA: 毒か解毒剤か？

Aaron Leventhal
Aaron Leventhal
X

ARIA とは

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

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

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

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

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

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

ARIA の仕組み

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

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

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

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 属性です。全体については、その要素に role="menubar" を使用します。アイテムのグループには role="menu" を使用し、個々のメニュー項目には role="menuitem" を使用します。

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

キーボードのバグを修正

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

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

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

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

キーボードのバグは、ほとんどの場合、ARIA ではなく、ウェブ コンテンツ（特に HTML と JavaScript）のバグです。

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

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 セマンティクスをオーバーライドできるようにします。