ASでないWeb技術の例

Accessibility Supported

目次
  1. ライブリージョン
  2. <dialog>要素とSafari+VoiceOver
  3. React Aria
  4. まとめ

こんにちは、mehm8128です。

今回は、実際にASでないWeb技術の具体例をいくつか紹介していきます。

ライブリージョン #

まずはライブリージョンです。

これについては、以前Browser and UIでymrlさんが発表したスライドが参考になります。

WAI-ARIAライブリージョンの基礎
ymrl.github.io

ライブリージョンはaria-live、aria-atomic、aria-relevant、aria-busyの4つの属性や、これらの属性が暗黙的に設定されるalert、log、statusroleなどを使って実装します。 しかし、これらの属性に従ってブラウザがDOMの変更を検知し、その変更内容をAccessibility APIを通じて伝達するのは複雑で、伝達するテキストの内容が仕様で明確に定義されているわけでもないので実装によって差が生じる余地もあります。 そのため、ブラウザやスクリーンリーダーによって異なる挙動を示すことがあります。

ymrlさんのスライドを見ても分かるように、実際にスクリーンリーダーによって挙動が異なる上、同じNVDAでもChromeとFirefoxで挙動が異なっています。

ちなみに、スクリーンリーダー実装者の参考になるように、MDNにはARIA Screen Reader Implementors Guide - ARIA | MDNというページがあるようです。

そして、この問題を少しでも解決するために最近導入されたのが、ARIA Notifyです。

ユーザーが何かアクションを起こした結果のフィードバックとして情報を伝達したいときに、隠れたHTML要素にHTML要素を配置して、ライブリージョンを用いて伝達するようなhackが使われることがあります。 しかしこれは表示が変化したDOMの内容を伝えるという本来のライブリージョンの用途とは、異なる使われ方です。このような用途ではARIA Notifyの命令的なAPIを用いるべきです。

ただ、本来の用途であれば引き続きライブリージョンを使うのが自然なので、利用するときはサポートしているユーザーエージェント・支援技術で動作確認が必須です。

<dialog>要素とSafari+VoiceOver #

次に、<dialog>要素とSafari+VoiceOverの環境においてフォーカス制御が上手く動かないことがあるという不具合の話です。 これは、以下のしゃもさんの記事で紹介されていました。

macOS26 Safari で <dialog> のフォーカスが壊れる問題を改善する - Qiita
概要 dialogとInvoker Commands（command、commandfor）で作られたダイアログが、macのSafari+VoiceOverのときだけフォーカスがおかしいことに気付きました。 Chrome、Firefoxでは同じコードで問題は起こりません。...
qiita.com

複数事象紹介されているのと、手元にMacがなくて動作確認できていないので個々の具体的な内容については取り上げませんが、これらはASに関する問題と言えます。 仕様通りに実装していても、実は特定の環境で動いていないということがある良い例です。ライブリージョンの件と同様に、サポートしているユーザーエージェント・支援技術での動作確認が必須であることを改めて確認できます。

こういう問題に遭遇したときにどう対応するべきか、悩むところです。 記事では、MacのSafari環境に対して色々な方法を駆使してworkaroundを実装していました。アクセシブルなプロダクトを提供するためには、どうしてもこのように暫定措置を施さなければならない場合があります。しかしさらにその先を考えたときに、追加で意識しておきたい点があると考えています。

1つは、その問題に気づき、原因まで突き止めてworkaroundを入れられる人がいるプロダクトでしか暫定措置を入れられないということです。当たり前と言えば当たり前なのですが、WebKit自体に修正が入らない限り、自分のプロダクトで対応しても他のプロダクトでは同じ不具合は発生したままの状態です。また、該当する挙動が発生しうるプロダクトに関わっている他の人が同じような対処法を見つけられない可能性があったり、そもそもこのような挙動が発生していることに気づかない人も多くいます。

もう1つは、WebKit側で修正が入ったとしても、その修正が適用されるのは基本的に（backportされない限り）最新版のブラウザのみです。よって、例えば会社のBaselineの基準としてWidely Availableを採用している場合は、同じ基準にするのであれば修正が入ってから2年半待たないと暫定措置を外すことができないということになります。

これらの点を考慮して、React Ariaのようなライブラリを使うという選択を採ることも検討できます。次のセクションで紹介していきます。

React Aria #

React AriaはAdobeが公開しているライブラリです。React Ariaには様々なUIコンポーネントを作るためのhooksが含まれており、それを使って独自のUIを組み立てることもできるし、React Ariaを使って構築されたReact Aria ComponentsやReact SpectrumなどのUIライブラリを使うこともできます。

React Ariaには、ブラウザやスクリーンリーダーの組み合わせによっては上手く動かないときがある問題に対処するための様々なworkaroundが組み込まれています。 例えば前のセクションで紹介していたダイアログだと、useDialogというダイアログを作るためのhooksがあり、その中にいくつかworkaroundが含まれています。

今回の記事で紹介されていたような問題へのworkaroundは含まれていないようですが、同じようにフォーカス制御周りの問題に対処していることがコード内のコメントから分かります。

他にも、ARIA系で大きいものだと以下のような問題が対処されています。

このようにReact Ariaでは、ライブラリの内部でブラウザやスクリーンリーダー間の互換性の問題を吸収しようとしています。もちろん十分に対応できていない部分もありますが、WebKitなどのブラウザエンジンと比べるとコントリビューションも行いやすくなっています。 また、ブラウザエンジン側で修正するのと比べると、修正がリリースされて取り込めばすぐに、ユーザーが使っているブラウザのバージョンに関係なく、全ユーザーに届けられるというメリットがあります。そして、自分のプロダクト側でworkaroundを入れるのと比べると、ライブラリを使っている開発者全員にworkaroundを届けることができるので、より多くの開発者にメリットがあります。

もちろんブラウザエンジン側にも素早く修正が入るのがベストです。しかし、それが全ユーザーに届くまでのタイムラグやコントリビューションの難易度などを考えると、こういったライブラリ側で環境間の差異を吸収してくれているようなライブラリにコントリビュートするというのも、アクセシビリティに貢献する1つの手だと考えています。

まとめ #

それではまた明日。