ASのためにできること

こんにちは、mehm8128です。

今回は、ASのために私たちができることを紹介します。

これまでに紹介してきたようなユーザーエージェント・支援技術間での互換性の問題に遭遇した場合、もしくは遭遇していなくてもなんらかの形でそのような問題の解決に貢献したいと考えている場合、これから紹介するような方法で貢献することができます。

ユーザーエージェント・支援技術のベンダーに不具合報告・修正PRを作成 #

これが最も直接的な方法です。 ブラウザ側の問題であればブラウザエンジンに、スクリーンリーダー側の問題であればスクリーンリーダーに不具合報告を行ったり、OSSであれば修正PRを作成したりすることで直接解決することができます。

具体的な窓口は、MDNの以下のページに記載されています。

ブラウザーにバグを報告するタイミングと方法 - ウェブ開発の学習 | MDN

ブラウザーはソフトウェアであり、他のソフトウェアと同様にバグが存在することがあります。開発しているウェブサイトが、期待通りに、あるいは MDN や仕様書などのドキュメントに記載されている通りに動作しないことに気づく場合があります。これは、あなたのコードのバグ、ドキュメントのバグ（そうでないことを願いますが！）、あるいはウェブサイトのテストに使っているブラウザーのバグのいずれかを示している可能性があります。この記事では、どれが原因なのかを判断する方法と、ブラウザーの問題だと判明した場合にバグを報告する方法について説明します。

developer.mozilla.org

注意点として、ASの問題は、ユーザーエージェントの問題なのか支援技術の問題なのかの切り分けが難しいことがあります。 ユーザーエージェントの役割は、HTMLを解釈し、Accessibility APIとして情報を公開するところまでです。 支援技術の役割は、Accessibility APIで公開された情報を受け取り、ユーザーが理解可能な形で示すところです。

そもそもHTMLを解釈できていなかったり、解釈していてもAccessibility APIとして情報を公開していなければユーザーエージェントの問題ということになります。例えば、ARIA属性が付与されている要素をブラウザのdevtoolsで確認したときに、そのARIA属性の情報がAccessibilityのタブに表示されていなければ、適切にHTMLを解釈できていないのでブラウザ側の問題である可能性が高くなります。また、同じスクリーンリーダーで確認したときに、あるブラウザでは正常に情報を読み取れるけど他のブラウザでは上手く読み取れないという場合は、ブラウザがスクリーンリーダーに対して情報を正しく公開できていない可能性が高く、これもブラウザ側の問題と考えられます。 逆に、ブラウザのdevtoolsでは属性値を確認できるけどスクリーンリーダーがそれを読み上げてくれない場合や、同じブラウザで確認してもスクリーンリーダーによって情報を読み上げたり読み上げてくれなかったりする場合は、スクリーンリーダー側の問題であると考えられます。

また、一見不具合のように感じても、実はそういう挙動になっている背景がある意図的な挙動である場合もあります。 例えば、Safariにおいてlist-style: noneが付与された<ul>や<ol>がlist roleになっていないのは、不具合ではなくてWebKit側の意図している挙動です。

"Fixing" Lists | scottohara.me

Jan 2023 - There have been additional updates to how Safari exposes list semantics based on their nesting context. For instance, if a list is a descendant...

www.scottohara.me

このような仕様化されていないブラウザのヒューリスティックは本当はあまり良くないのですが、このようになっている経緯があるので、不具合として報告しても直されることはないということに注意が必要です（ただし、この場合は<nav>要素というコンテキストにおける例外のように、適切な例外を追加したい、という要望であれば通る可能性はあります）。

WPTへのissue・テストケース作成 #

他の手段として、WPTへのissue・テストケース作成が挙げられます。 WPTはブラウザが直接参照しているテストスイートであるため、貢献することによる影響は大きいです。

後述しますが、「こういうテストケースがあった方がいいのではないか」というようなissueを作成したり、実際にテストケースを作成してPRを提出することで、ブラウザが参照し、web-platform-tests dashboardで各ブラウザのテスト通過状況が確認できるようになります。

このテストケースを基に、前のセクションで述べたような方法でブラウザ側にissueやPRを提出することで、より根拠を持って提出できるという側面もあります。

WPTの中でも、主にアクセシビリティに関係あるのは以下のディレクトリです。

• accessibility
• acc-name
• dpub-aam
• core-aam
• html-aam
• svg-aam
• wai-aria

これらについては、6日目に深堀りする予定です。

a11ysupport.ioやWAICのAS情報などへの情報提供・テストケース作成 #

これは比較的間接的な方法になりますが、開発者への情報提供として2日目に挙げたようなデータベースへの貢献も考えられます。 a11ysupport.ioはテスト結果とテストケースの作成のどちらも募集しています。WAICのAS情報は、現状テスト結果のみ募集しています。 ARIA-ATについては、ARIA-AT Community Groupのメンバーにならなければ直接の貢献は難しいようです（Running a Test Plan · w3c-cg/aria-at Wiki）。ただし、CGなのでW3C会員でなくとも参加は可能になっています。

a11ysupport.ioについてはContributing | Accessibility Supportを参照、WAICのAS情報についてはアクセシビリティ サポーテッド（AS）情報 | ウェブアクセシビリティ基盤委員会（WAIC）の「検証作業に対するご協力のお願い」のセクションを参照していただくか、定期的に開催しているアクセシビリティ サポーテッド（AS）テスト体験会にご参加ください。

実際にやってみた #

以前、実際にいくつか貢献をしたことがあるので紹介します。

AX: Interactive elements containing the <svg> element which is named by <title> element doesn’t have accessible name #

ASの問題に対して、WPTにテストケースを作成してPRを提出し、マージされた後にそれを根拠としてWebKitにBugを提出したところ、WebKitの中の人がPRを作成してくれて修正されたという例です。

今回問題となっていたのは、インタラクティブ要素内の<svg>要素が<title>要素を持つ場合に、WebKitにおいて<title>要素の中身がインタラクティブ要素のaccessible nameとして考慮されないという不具合でした。 これは、アイコンボタンのアクセシブルな名前はボタンが持つべきかアイコンが持つべきか の記事にて挙げられている問題です。

また、<svg>ではaltが使えないからaria-labelはロジックをすっ飛ばしている - 水底の血にも同様の話が書かれており、これをきっかけとして以下の流れで進みました。

1. issue作成：上記のsvg要素の話の基となった記事を執筆したyuheiyさんが、WPTに対して[html-aam] Tests needed for svg > title when placed inside interactive elements · web-platform-tests/wptというissueを作成
2. PR作成：このissueに対して、僕がAdd tests for interactive element labels named by svg title elements · web-platform-tests/wptというPRを作成し、マージ
3. Bug報告：マージされたテストケースを根拠として、僕がAX: Interactive elements containing the <svg> element which is named by <title> element doesn’t have accessible nameというBugをWebKitに報告
4. 修正：AX: Interactive elements containing the <svg> element which is named by <title> element doesn’t have accessible name · WebKit/WebKitにてAppleのエンジニアが修正

この修正は、Release Notes for Safari Technology Preview 244 | WebKitに記載されています。

Fixed an issue where interactive elements containing an <svg> named by a child <title> element did not expose an accessible name. (312953@main) (172559238)

これによってaccessible nameが付与されない問題は解決される一方で、インラインSVGの代替テキストはどうするべきか – TAKLOGで解説されているように、<title>要素にホバーした際にツールチップが表示されたり、<title>要素の中身が機械翻訳されない問題などは残っています。そのため、必要に応じてaria-labelやaria-labelledbyを使うことも検討できるでしょう。

今回の問題は以前から度々話題になることがあって認識していたのですが、「title要素でSVGにaccessible nameをつける方法はASでないので、別の方法を使う」というhackが広まって本来どうあるべきかということが知られていないのは良くないと思い、今回の件をきっかけとしてWPTのテストケース作成やWebKitへのBug報告を進めていきました。

fix: announce all content inside role="alert" #

こちらはNVDAにPRを送った件です。

以前Accessibility APIでブラウザから情報を取得してみる - mehm8128のWeblogなどでNVDAの中身自体は読んだことがあったものの、実際にコードを書いたり貢献したりするところまではできていなかったので、何かASに関連するissueがないかと漁っていました。そこでNVDA does not announce contents of div with role=“alert” containing a list · nvaccess/nvdaというissueを見つけ、比較的簡単に修正できそうだったのでやってみました。

このissueは、role="alert"をつけた要素が表示されたときに、今まではボタンなどFOCUSABLEな要素しか読み上げられていなかったのですが、リスト関連のroleや見出し、paragraph roleなども読み上げるようにしてほしいという内容でした。

fix: announce all content inside role="alert" · nvaccess/nvdaというPRを作成し、無事マージされました（タイトルは”all content”になっていますが、途中で一部のroleに限定したので実は”all”ではありません）。

思っていたよりも経緯や実装が複雑そうで、結局完全には理解できないままなんとかマージまで持っていったのですが、「role="alert"なのだから表示されたら中身が読み上げられるはずなのに、読み上げられないものがある」という問題を部分的に改善できました。2026.3で入る予定らしいので、リリースまではもう少しかかりそうです。

まとめ #

ASに関する問題は、暫定的なhackyな対応で解決できても、他に同じ状況で困る人がいるかもしれません。例えば記事などでその知見を公開していたとしても、その記事までたどり着ける人はほんの一握りかもしれないし、そもそも問題が発生していることに気づかない開発者も多いはずです。

Webアクセシビリティをやっている人たちは「自分たちのプロダクトがアクセシブルであれば良い」ではなくて、「社会全体をアクセシブルにしたい」というところまで気持ちのある人が多いと思っています。 それを実現するためには、より根本的なところから対処していく必要があります。そのために、今回紹介したようなブラウザやスクリーンリーダーなどに直接貢献していくような方法を採れる人が増えれば良いなと思うし、自分ももっとその領域まで貢献していきたいと考えています。

それではまた明日。