あけましておめでとうございます。株式会社ミツエーリンクスの中村直樹です。昨年まで執筆していた当社黒澤に代わって、2020年のWebアクセシビリティの短期的な予測をしてみます。
Web Content Accessibility Guidelines（WCAG）2.2
WCAG 2.1（原文、参考日本語訳）がW3C勧告（Recommendation）となって1年半が経過しました。WCAG 2.1で新規に追加された達成基準に関する知見がWebアクセシビリティのコミュニティに十分に出揃ってきているのかは個人的には疑問に思うところではあるものの、WCAGを策定しているAG WG（Accessibility Guideline Working Group）では、WCAG 2.1の次となるWCAG 2.2について、策定を進めようとしています。
WCAG 2.2はどのような姿になるのでしょうか。本稿の執筆段階ではまだ編集者草案（Editor’s Draft）も公開されていないような状況ですので、草案を元にして具体的な中身を述べることはできません。しかしながら、2.2という数字が示すように、小数点以下の数字が増えるWCAG 2のドットリリースであることは間違いありません。ここから言えることは、WCAG 2.0から2.1になったときと同様の枠組みで勧告が策定されていく、ということです。つまり、
- WCAG 2.1の達成基準の番号は、WCAG 2.2でも基本的にそのままスライドする形で存続する。
- WCAG 2.2の新規の達成基準は、WCAG 2.1に追記される形になる。
という大枠になります。新規の達成基準の候補については、Potential WCAG 2.2 SCsというタイトルのGoogleスプレッドシートに挙げられており、17の達成基準の候補が挙げられています。WCAG 2.0からWCAG 2.1では達成基準が17増えたわけですから、最大で同規模の分量となることが見込まれます。
さて、WCAG 2.2の策定スケジュールはどのようになるのでしょうか。
2017年1月に開始されたAGWGの憲章（Charter）では、当初の予定であれば昨年10月末に期限が切れ、次の憲章が発行される予定でした。ところがこの憲章は12月末までに期限が延長されたため、本稿の執筆段階では確定した情報を得られずにいる、と書きかけたところで、12月20日付けで新しい憲章が発行されました。これによるとWCAG 2.2のマイルストーンは、
- 2020年1月：最初の公開草案（First Public Working Draft）
- 2020年5月：勧告候補（Candidate Recommendation）
- 2020年11月：勧告
とされています。一方で、WCAG 2.1の策定を振り返ってみますと、
という日程でした。WCAG 2.1の日程と比較すると、作業草案の改訂期間が短く取られていることがわかります。これにより、WCAG 2.1よりも速いペースで勧告を目指す心づもりのようですが、そこまで速いペースで勧告までいくのかは個人的にはやや疑問に思います。とはいえ、今年中に勧告候補が発行され、どのような達成基準が新規に追加されるのかという大枠が固まっているという状況は、かなりの高い確率で訪れそうです。
WAI-ARIA 1.2
WAI-ARIA 1.1（原文、参考日本語訳）がW3C勧告となって2年が経過しました。WCAG 2.2とは異なり、後続仕様となるWAI-ARIA 1.2については作業草案（Working Draft）が既に発行されています。2018年12月18日付けで作業草案が発行されて以来、しばらく作業草案の更新がありませんでしたが、奇しくも1年後の同日の日付に作業草案が更新されました（2019年12月18日付けの作業草案）。
さて、その作業草案の変更点（Change Log）を眺めてみますと、1つ前の作業草案から多数のロールが追加されているのが見て取れます。これは、ARIA Working Group Road Mapで説明されているように、WAI-ARIA 1.2ではHTML要素に対して対応するロールが存在しないものについて、対応するロールを追加していくという方針に基づくものです。
WAI-ARIA 1.1の時点でHTML要素に対応するロールがなかったものの一例としては、strong要素が挙げられます。これまでは、strong要素に対応するロールがなかったため、支援技術にそのセマンティクスを伝える術がありませんでした。しかし、WAI-ARIA 1.2ではstrongロールが定義され、これがstrong要素に対応するロールと位置づけられることになります（ロールと要素が同名であるので、紛らわしいですが）。支援技術がstrongロールを受け取ってどう表現するのかは支援技術次第になりますが、従来よりもきめ細やかにHTML要素のセマンティクスを支援技術経由で伝えられる状況は着実に近づいてきていると言えます。その意味では、支援技術が新しいロールに対応することを前提として、これまで以上にHTMLコードの品質が問われる場面が今後増えていくのかもしれません。
なお、前出のRoad MapではWAI-ARIA 1.2ですべてのHTML要素を対象にする予定でしたが、一部のロールについてはWAI-ARIA 1.3に持ち越しになるようです（Plans regarding role parity）。
WAI-ARIA 1.2のスケジュールについては、公開されている情報からは明確にはわからないというのが正直なところです。ただし、最新の作業草案に記載されているこの文書のステータス（Status of This Document）では、
Feature development for this version is complete, and this is a wide review draft published to obtain feedback before finalization of the spec.
と、WAI-ARIA 1.2における新機能の追加が完了したことを述べており、WAI-ARIA仕様を策定しているARIA Working Groupが特にWAI-ARIA 1.1からの変更点についてフィードバックを求めています。フィードバックのデッドラインについては述べられていませんが、フィードバックコメントに重大なものがなければ、今年の早いうちに勧告候補のステータスに進むことが予想されます。
Webブラウザーのビルトイン機能
あまりWebアクセシビリティのコミュニティでは注目されてこなかったと筆者は認識しているのですが、2019年を振り返ってみると、Webブラウザーのビルトイン機能が拡充された年でありました。具体的には、SafariではWebアクセシビリティの監査ができるようになったり（Audits in Web Inspector | WebKit）、執筆時点ではFirefoxのリリース版には搭載されていませんが、色覚シミュレーションができるようになったり（@FirefoxDevToolsによるツイート）と、ブラウザーだけでできるWebアクセシビリティに関連する機能が増えてきているのが印象的でした。特別なツールを導入することなくWebブラウザーだけでWebアクセシビリティの簡単なチェックがいつの間にかできるようになってきつつあるようです。
国内支援技術の動向
やや古い情報ではありますが、視覚障害者の携帯電話・スマートフォン・タブレット・パソコン利用状況調査2013によると、国内におけるスクリーンリーダーのトップシェアはPC-Talkerであり、約85%であると報告されています。
そのPC-Talkerを開発している高知システムが、昨年末にPC-Talker専用の音声ブラウザーNetReaderにChromiumエンジンを搭載したネオモードの開発をはじめたという話がありました（PC-Talker ベータサイト）。ウェブ制作者向けに機能制限がされたクリエイター版も頒布されており、実際に試すことも可能です。PC-TalkerユーザーのInternet Explorer離れがいよいよ加速していくのか、興味深いところではあります。
国交省ガイドライン
2019年10月に改訂された国土交通省のバリアフリー整備ガイドラインでは、情報提供のアクセシビリティ確保に向けたガイドラインとしてウェブアクセシビリティに関する章が追加されました。内容自体は、JIS X 8341-3:2016の適合レベルAAを基本とし、適合レベルAAAにも取り組むように求めるという、かなり高度なものを求める内容となっています（所属会社のBlogに記載した筆者のエントリーも参照ください）。
ガイドラインが求めるレベル感には賛否が分かれるものがあると筆者は考えますが、いずれにせよ、このガイドラインが対象とする公共交通機関（鉄道、バス、旅客船、航空機）の私企業に対して、一定の基準が国から提示されたことは意義深いものであると考えます。今後、このバリアフリーガイドラインの対象である鉄道をはじめとする事業者がどのようなスタンスで取り組んでいくのか、また、他の公共性が高いと思われる他の事業分野（金融機関、医療機関、教育機関など）に波及していくのかどうかを占う1年になりそうです。
