TPAC 2015 現地レポート2

引き続きTPAC 2015に関する記事をお届けします。本記事でもARIA WGのミーティング内容の一部を紹介します。

多くのブラウザーとスクリーン・リーダーなどの支援技術は、Webページの情報のやりとりにアクセシビリティAPIを使っていることが知られています。そのため、支援技術が得る情報はブラウザーがアクセシビリティAPI経由で提供する情報の影響を受けます。そこで、ARIA WGはブラウザーがアクセシビリティAPIに対して何を提供すべきかの標準化を進めています（HTML-AAMやSVG-AAMなど）。

しかし、アクセシビリティAPIはOSや、OSとブラウザーの組み合わせによって種類が異なります。そのため、ブラウザーが仕様通りに実装しているかのテストは簡単ではありません。

また、ブラウザーがアクセシビリティAPIに提供している情報を得ることは、DOMにアクセスすることほどには簡単ではないため、Webページのアクセシビリティに関する自動テストでも利用しづらくなっています。そのことで、「このHTMLはスクリーン・リーダーにはこのように伝わる」という解釈がテストツールのヒューリスティックに頼ってしまい、実際にスクリーン・リーダーへ伝わる情報と乖離していることもあると私は感じています。

• ※ 私はテストツールは「このHTMLはスクリーン・リーダーにはこのように伝わる」という情報を提供すべきと考えているわけではありません。あくまでも、提供する場合には根拠に基づいた情報を提供すべき、と考えています。

TPAC 2015 2日目、10月27日のARIA WGのミーティングでは、ブラウザーがアクセシビリティAPIに提供する情報について、特定のOSやブラウザーに依存しない中間的な表現の標準化が必要なのではないかという話がありました。また、それらの情報をJavaScriptで生成できるようにして、Webページと支援技術が直接やりとりできるようにすべきではないか、という話がありました。この記事では前者の中間的な表現について紹介したいと思います。

実際のところ、複数のブラウザーが既に、アクセシビリティAPIに提供する情報を中間的な表現で持っています（MicrosoftによるとEdgeは中間的な表現を採用していないとのことです）。ブラウザーによっては開発者ツールでこれらの情報を見ることもできます。ただし、これらの内部表現はブラウザーによって異なり、互換性などは考えられていません。また、WebページからそれらのアクセシビリティAPIに関連する情報にアクセスする方法もありません。

ミーティングではMozillaが検討しているWeb Accessibility APIなどが紹介されました。この提案では、アクセシビリティAPIの中間的な表現はDOM要素経由でアクセスすることができます。

ところで、ブラウザーに関するテストでは、（間接的に利用する場合も含め）Web Driverを利用することも多いのではないでしょうか。Web DriverもW3CのBrowser Testing & Tools Working Group (BTT WG)が標準化を行っている仕様です。

10月27日はARIA WGとBTT WGの合同ミーティングもあり、そこではWeb DriverにアクセシビリティAPIに関した機能を追加するかなどが議論されました。BTT WGの反応はポジティブだと私は感じましたが、BTT WGはWeb Driver Level 1の早期勧告化（2016年1月の勧告化）を目指しており、アクセシビリティAPIに関する機能がWeb Driver Level 1に含まれる可能性は低いです。また、アクセシビリティAPIの中間的な表現がDOM経由でアクセスできるようになれば、Web DriverのAPIにアクセシビリティAPI関連の機能を含める必要がない（Web Driver経由でJavaScriptを実行すれば済む）可能性もあります。

ブラウザーに対するものにせよ、Webページに対するものにせよ、自動テストには最終的な結果（典型的には適合（○）か不適合（×）か）だけではなく、その結果が得られた根拠（途中経過）が必要だと私は考えています。アクセシビリティAPIに関する情報を得やすくなれば、結果に対する根拠が増えるのではないかと考えています。