ASに関するデータベース
Accessibility Supported
こんにちは、mehm8128です。
今回はa11ysupport.io、WAICのAS情報、ARIA-ATという、3つのASに関するデータベースを紹介します。
a11ysupport.io #
a11ysupport.ioとは、Web技術をユーザーエージェント・支援技術の組み合わせがどの程度サポートしているかというデータを収集・公開しているサイトです。詳細はFAQに記載されていますが、後述するARIA-ATに関わっている人が運営しています。
aria-sortを例にして見ていきます(ref: aria-sort - ARIA | MDN)。

例えば1行目はaria-sort="ascending"を指定しているときに「昇順」であることをスクリーンリーダーが読み上げるかどうかという挙動で、FirefoxにおけるOrcaとChromeにおけるTalkBackが読み上げないという結果になっています。
表の下にはそれぞれの挙動について詳細な解説が記載されています。
あるWeb技術を使いたくなったときにこの表を確認することで、自分のサービスがサポートしている環境において、そのWeb技術がどのような挙動をしてくれるか知ることができます。そしてサポート状況が許容できるものであればその技術を使って実装を進めることができます1。 ただ、a11ysupport.ioは日本固有のスクリーンリーダーであるPC Talkerなどのデータがないので、別で動作確認をする必要があることに注意が必要です。
テストケースには、各挙動をテストする方法が記載されています。このテストケースを用いて情報提供することができます。
こういうデータベースは多くの環境でテストが必要なことと、現状手動テストに頼らざるを得ないことから、どうしても情報が古くなってしまいがちなので、多くの人たちが最新の環境でテスト結果を提供することで価値のあるサイトにしていくことができます。
WAICのAS情報 #
ウェブアクセシビリティ基盤委員会(WAIC)の作業部会では、AS情報というデータベースを構築しています。僕も作業部会委員の一人として、AS情報自体のメンテナンスやテストケースの作成に関わっています。 詳細は以下の記事で紹介しています。
AS情報はアクセシビリティ サポーテッド(AS)情報で公開されています。こちらは多くのテストケースがWCAGの達成基準に含まれるテクニックに紐づけて作成されています。というのも、1日目にも紹介したようにASはWCAGで定義されている概念なので、WAICのAS情報構築はWCAGのテクニックに基づいています。ただ、今後WCAGに紐づかない独自のテストケースによってAS情報を増やしていく可能性もあります。 テクニックに紐づいているので、WCAGの達成基準を満たそうとしたときに「このテクニックは、この環境(OS、ユーザーエージェント、支援技術)ではASであるので、達成基準を満たすために利用して問題ない」という判別ができるようになっています。

ソース: テスト0050-01
また、a11ysupport.ioと違う点として、日本で作成しているデータベースなのでPC TalkerやNetReaderに関する情報が含まれているということもポイントです。1日目に紹介したように、国によっても多様な環境でWebを利用している人がいるので、国に固有の環境に関するデータベースはどうしても必要になってきます。
一方、現状はASテスト体験会や常時受け付けの投稿に頼ってしまっているというのと、日本特有のデータベースということで情報提供するユーザーが少ないということがあり、十分に更新できていないという問題はあります。これについては次のセクションで触れるように、今後テストの自動化などを進めることを検討しています。
また、a11ysupport.ioと比べて「この環境ではこの挙動がサポートされている」ということは分かりづらくなっているので、情報の提示方法についても今後検討していきたいと考えています。
ARIA-AT #
ARIA-ATはW3CのARIA-AT Community Groupが構築している、支援技術の相互運用性を上げるためのプロジェクトです。その一環として、主に相互運用性データベースの構築をしています。
現在は特にAPGのパターンごとにテストケースを作成しており、APGのパターンを様々な環境でテストし、結果をまとめています。 自動テストと手動テストの両方を行っており、スクリーンリーダーの自動操縦によるテスト結果も含まれています。

ソース: JAWS 2025.2508.120 and Chrome for Accordion | ARIA-AT Reports
これはGitHub上に自動テストのGitHub Actionsのソースコードが公開されているため、誰でも見ることができるようになっています。 そこで僕は以前、前述のWAICで作成しているAS情報のテストケースを、ARIA-ATのGitHub Actionsを用いて自動化してみました。
詳細はここでは説明しないのですが、以下のCosenseにメモしています。WAICのASテストケースを用いてAIにARIA-AT用のテストケースを作成してもらい、Chrome+NVDAで自動実行したログを取得するところまで実現できました。
今後WAICにおけるAS情報の作成に似たような仕組みを利用したいと検討している一方、PC TalkerはARIA-ATに前例がない上にNVDAなどとは仕組みが大きく異なるため、作業部会内で別の方法を検討中です。
まとめ #
それではまた明日。
-
例えば
aria-sortの値として"ascending"と"descending"以外を指定しないのであれば、表の”MUST convey the ‘other’ value”のサポート状況は考慮しなくても問題ありません。 ↩