2015に関する記事をお届けします。WGのミーティング内容の一部を紹介します。多くのブラウザーとスクリーン・リーダーなどの支援技術は、Webページの情報のやりとりにアクセシビリティAPIを使っていることが知られています。そのため、支援技術が得る情報はブラウザーがアクセシビリティAPI経由で提供する情報の影響を受けます。WGはブラウザーがアクセシビリティAPIに対して何を提供すべきかの標準化を進めています(HTML-AAMやSVG-AAMなど)。アクセシビリティAPIはOSや、OSとブラウザーの組み合わせによって種類が異なります。そのため、ブラウザーが仕様通りに実装しているかのテストは簡単ではありません。ブラウザーがアクセシビリティAPIに提供している情報を得ることは、DOMにアクセスすることほどには簡単ではないため、Webページのアクセシビリティに関する自動テストでも利用しづらくなっています。そのことで、「このHTMLはスクリーン・リーダーにはこのように伝わる」という解釈がテストツールのヒューリスティックに頼ってしまい、実際にスクリーン・リーダーへ伝わる情報と乖離していることもあると私は感じています。私はテストツールは「このHTMLはスクリーン・リーダーにはこのように伝わる」という情報を提供すべきと考えているわけではありません。提供する場合には根拠に基づいた情報を提供すべき、と考えています。WGのミーティングでは、ブラウザーがアクセシビリティAPIに提供する情報について、特定のOSやブラウザーに依存しない中間的な表現の標準化が必要なのではないかという話がありました。それらの情報をJavaScriptで生成できるようにして、Webページと支援技術が直接やりとりできるようにすべきではないか、という話がありました。この記事では前者の中間的な表現について紹介したいと思います。実際のところ、複数のブラウザーが既に、アクセシビリティAPIに提供する情報を中間的な表現で持っています(MicrosoftによるとEdgeは中間的な表現を採用していないとのことです)。ブラウザーによっては開発者ツールでこれらの情報を見ることもできます。これらの内部表現はブラウザーによって異なり、互換性などは考えられていません。WebページからそれらのアクセシビリティAPIに関連する情報にアクセスする方法もありません。APIなどが紹介されました。この提案では、アクセシビリティAPIの中間的な表現はDOM要素経由でアクセスすることができます。Driverを利用することも多いのではないでしょうか。WG)が標準化を行っている仕様です。DriverにアクセシビリティAPIに関した機能を追加するかなどが議論されました。1に含まれる可能性は低いです。Driver経由でJavaScriptを実行すれば済む)可能性もあります。ブラウザーに対するものにせよ、Webページに対するものにせよ、自動テストには最終的な結果(典型的には適合(○)か不適合(×)か)だけではなく、その結果が得られた根拠(途中経過)が必要だと私は考えています。アクセシビリティAPIに関する情報を得やすくなれば、結果に対する根拠が増えるのではないかと考えています。