あけましておめでとうございます。株式会社ミツエーリンクスの黒澤剛志です。本稿では、昨年に引き続いて、2019年のWebアクセシビリティの短期的に予測してみます。
Web Content Accessibility Guidelines（WCAG）2.1
WCAG 2.1は2018年6月5日にW3C勧告（Recommendation）となりました。WCAG 2.0からの内容はそのままに、レベルAに5個、AAに7個、AAAに5個の計17個の達成基準が追加されています。WCAG 2.0同様、WCAG 2.1の本文には具体的な内容は記述されていないため、関連文書を参照しながら対応をすすめていくことになるでしょう。達成基準によって情報量に差はありますが、Understanding WCAG 2.1やTechniques for WCAG 2.1などが公開されています。
なお、WCAG 2.1の日本語訳はウェブアクセシビリティ基盤委員会が進めており、作業中の内容はGitHubで公開されています。本稿執筆時点では正式公開には至っていませんが、遠からずアナウンスがあるものと思われます。
さて、実際にWCAG 2.1の対応を検討すると、実装するための技術が十分揃っているとは言いにくい達成基準があることは否めません。特に認知・学習障害への対応として追加された達成基準（1.3.5 Identify Input Purpose（Level AA）や1.3.6 Identify Purpose（Level AAA））は、達成方法がよく整備されていると言うのは厳しいのが現状です。
W3Cもこのようなギャップを埋めるために、Personalization Semantics Content Module 1.0などの標準化をすすめています。この仕様は入力欄やリンク、ボタンなどUIの目的を機械可読な形で（マシンリーダブルに）埋め込むための属性を定義し、認知・学習障害のユーザーなどがコンテンツを利用しやすい形に変換することを意図しています。なお、現在の草案では各属性にaui-という接頭辞がつけられていますが、この命名規則は最終決定されているわけではありません。標準化動向には注視したいところです。
EdgeとNarrator
2018年12月6日、Microsoftはデスクトップ版EdgeのレンダリングエンジンをEdgeHTMLからChromiumベースに移行することを発表しました。今年の早い時期にChromium版Edgeのプレビュービルドが公開される予定です。また、発表の直後にはMicrosoftからChromiumのアクセシビリティAPI[1]対応を拡張する提案が公開されています。
一方、Microsoftはそれよりも早い時期から、Windows 10の次期大型アップデート（19H1）向けにNarratorのChrome（Chromium）対応を進めていることを発表してきました（2018年10月24日付けのWindows 10 Insider Preview Build 18267）。
これまでEdgeとChromiumでは実装しているアクセシビリティAPIが異なり、前者はUI Automation、後者はIAccessible2を利用しています[2]。支援技術がそれぞれのブラウザーに対応するには実質的に2つのAPIに対応する必要がありました。
Edgeの提案はChromiumにUI Automationのサポートを追加することで、UI Automationに対応した支援技術がChromiumをより良くサポートできることが意図されています。NarratorのChromium対応ではNarratorがIAccessible2に対応することで、IAccessible2を利用しているChromiumをより良くサポートできることが意図されています。それぞれの登場時期や提供される機能、互いの関係性に注視したいところです。
Accessible Rich Internet Applications（WAI-ARIA）・Accessibility Object Model（AOM）
2018年は7月と12月にWAI-ARIA 1.2の草案が公開されました。WAI-ARIA 1.2はセマンティクスの拡張という観点では限定的で、HTMLで表現できるセマンティクスをWAI-ARIAで表現できるようにするための調整がなされています。本稿執筆時点で最新の草案（2018年12月18日付）にはblockquote、paragraph、captionというロールが追加されており、それぞれblockquote要素、p要素、caption要素とfigcaption要素に対応しています。ブラウザーのサポートも進んでいます[3]が、通常は対応するHTMLの要素を使えばよいため、利用する場面はそこまで多くはないでしょう。
一方、WAI-ARIA 1.2の草案の大きな変更点はJavaScript API（IDLインタフェース）が定義されたことでしょう。WAI-ARIAはその名の通り、リッチインターネットアプリケーションをアクセシブルにするための仕様ですが、これまではすべての操作をDOM属性の変更で行っているため、JavaScriptのコードは冗長になりがちでした。草案ではWAI-ARIAの各属性に対応するプロパティ（IDL属性）が定義されており、JavaScriptのコードから直接、WAI-ARIAの値を読み書きできることが想定されています。
もっとも、WAI-ARIAの草案に取り込まれているJavaScript APIは値を直接読み書きできるものの、値の型はすべて文字列であるため、次のような冗長性は解決しません。
const colLabel = document.querySelector(COLUMN_SELECTOR);
const rowLabel = document.querySelector(ROW_SELECTOR);
const formControl = document.querySelector(CONTROL_SELECTOR);
const colLabelId = (colLabel.id = colLabel.id || generateId());
const rowLabelId = (rowLabel.id = rowLabel.id || generateId());
formControl.ariaLabelledBy = [colLabelId, rowLabelId].join(' ');
これを次のようにシンプルにしようという提案が、Accessibility Object Model（AOM）の中で行われています。
const colLabel = document.querySelector(COLUMN_SELECTOR);
const rowLabel = document.querySelector(ROW_SELECTOR);
const formControl = document.querySelector(CONTROL_SELECTOR);
formControl.ariaLabelledByElements = [colLabel, rowLabel];
このAOMは、アクセシビリティツリーに関する操作を提供するJavaScript APIの標準化を目指したプロジェクトです。アクセシビリティツリーをJavaScriptで扱うためのAPIの検討や、それを実現するためにWAI-ARIAに限らず関連する仕様（HTMLなど）への提案を行っています。前述の提案もHTMLの仕様に対するものでした。
AOMそのものは、ブラウザー上で動くリモートデスクトップアプリケーションにおいて、リモート画面のアクセシビリティツリーをJavaScript APIで再現できたら……などの野心的なユースケースを考えていますが、開発者やユーザーが利用できるようになるのは、より身近なAPIからと考えています。
AOMの本体と言えるアクセシビリティツリーを表すAPIの仕様はまだ固まったものはなく、開発者が気軽に使えるものではありません[4]。とはいえ、現在主要なブラウザー（Chrome、Edge、Firefox、Safari）は開発者ツールでアクセシビリティツリーを調査する機能を提供しており、同じことがページ内のJavaScriptからできないことは、開発者ツールプロトコルのロックインを招いている（事実上Chrome DevTools Protocol一択）とも言え、更なる標準化の進展を期待しています。
スタイルガイド（コンポーネントリスト）
ここ数年、フロントエンドの開発ではスタイルガイド（コンポーネントリスト）を整備することが増えてきていると感じています。スタイルガイドを整備することで、コンテンツやUIの一貫性を保ち、一定の品質を保つことが期待できます。アクセシビリティについても、一定の品質を確認したコンポーネント同士を組み合わせてコンテンツを作ることで、自動的に一定の品質を確保されることが期待できます。
とはいえ、特にインタラクションを伴うコンポーネント同士の組み合わせでは、当初想定していなかったコンポーネント同士を組み合わせたことで、問題が発生するケースもまま見受けられます。一方、スタイルガイドのフレームワークの1つ、Storybookでは、スタイルガイドに機械的なアクセシビリティチェックをするパネルを追加するアドオンが提供されており、スタイルガイドを見るたびにチェックが実行されえます[5]。
もちろん、機械的な検証ですべての問題が見つかるわけではありませんし、コンポーネントがスタイルガイドに載ってから問題に気がつくのでは遅いこともあるでしょう。とはいえ、開発中に案件関係者が高頻度で参照するスタイルガイドで、アクセシビリティチェックを実施することで問題により気がつきやすくなるのはたしかです。他のスタイルガイドにも同様の機能が広まることを期待しています。
リスクかチャンスか
さて、近年、米国ではアクセシブルでないWebサイトに対する訴訟が増加しています。数字の取り方にもよりますが、2018年上半期の訴訟件数（1053）だけで2017年の件数（814）を越えています。アクセシビリティに取り組まなければ、個人が尊厳をもって生きる権利を何らかの意味で否定していると捉えられかねないと意識すべきでしょう。W3C WAIも各国の法律や規制の動向をまとめたページを公開していますが、米国のみならず、数多くの国と地域で法整備が進んでいます。グローバル企業では文字通り待ったなしの状況と言えるでしょう。また、米国ではすでにWCAG 2.1 レベルAAの対応をすることで合意する事例も出てきていますので、WCAG 2.1のキャッチアップも急務となるでしょう。
一方で、訴訟に対する恐怖や罰則の回避を目的としたアクセシビリティ対応が実際のユーザーを向いたものになりにくいことも、以前から指摘されています。
2018年は自社がいかにアクセシビリティに取り組んでいるかを積極的に伝えることも、これまでに増して多くなったように感じています（例えば、Appleのアクセシビリティ ストーリーやMicrosoftのAI for Accessibility）。また、タイプライターや音声認識など、過去のイノベーションが当時のアクセシビリティ対応をきっかけにしていることも盛んに取り上げられるようになりました。W3C WAIもアクセシビリティがビジネスに与える影響をまとめたページを公開しましたし、インターネットの父ともいわれるVint Cerfが電子メールに興味をもったのも彼の聴覚障害が関係していたことを2018年のインタビューで改めて述べています。
やって当たり前のアクセシビリティの確保、リスクと捉えるか更なるイノベーションのチャンスと捉えるか。みなさまの2019年はどちらでしょうか。
