あけましておめでとうございます。株式会社ミツエーリンクスの黒澤剛志です。本稿では、昨年に引き続いて、2018年のWebアクセシビリティの短期的な予測を寄稿させていただきます。
Web Content Accessibility Guidelines (WCAG) 2.1
WCAG 2.0は2008年12月11日にW3C勧告（Recommendation）となりましたので、今年で10周年を迎えます。WCAG 2.0は国際的なガイドラインとして用いられていますが、W3CではWCAG 2.0以後のガイドラインの検討が進んでいます。
昨年もWCAG 2.0以後のガイドラインとしてWCAG 2.1を紹介しましたが、いよいよWCAG 2.1の標準化が大詰めを迎えています。本稿執筆段階での最新の草案（Working Draft）は2017年12月7日付のものですが、標準化を進めているAccessibility Guidelines Working Groupは次のステップとして2018年1月下旬に勧告候補（Candidate
Recommendation）を公開することを予定しています。まだ内容を確認されていない人は早めの確認が必要です。
WCAG 2.1はWCAG 2.0と矛盾しないように仕様を拡張するという形をとっており、様々な内容が追加されています。追加内容にはタッチ操作のターゲットサイズなどのように、すでに一般的に浸透しているものもありますが、これまでWebアクセシビリティの文脈では十分考えられてこなかったと感じるものも追加されています。
筆者が特に気になったのは、Webにおける認証です（WCAG 2.1の2017年12月7日付草案では2.2.6 Accessible Authentication）。Webにおける認証は、これまでユーザー名とパスワードの組み合わせが使い続けられてきましたし、HTMLで「この部分は認証情報である」と明示する仕組みはほぼありませんでした。認証情報の管理（保存や自動入力）もブラウザーなどが該当の入力欄を認証情報と判断するかどうかに依存してきたと言えます。
そのため、認証を改善しようとすると、Webにおける認証の仕組み作りから始めなくてはならないということが、アクセシビリティの観点からも明らかになったと感じています。現在、Webのフロントエンド技術では、認証情報を明示的に管理するAPIであるCredential Managementや、ユーザー名とパスワードの組み合わせに限らない認証方法を提供するWeb Authenticationの標準化が進んでいます。これらの技術はWebアクセシビリティの観点から議論されることは少なかったと感じていますが、今後はWebアクセシビリティを支える技術として考える必要があるでしょう。
さて、話を元に戻すとWCAG 2.1は2018年1月に勧告候補、6月にはW3C勧告となることが計画されています。今年は最終的な内容やどのように普及していくかに注目が必要です。
メディアのアクセシビリティ
前節ではWCAG 2.1について述べましたが、WCAG 2.0や一致規格であるJIS X 8341-3:2016への対応を目指すサイトやサービスも増えてきています。対応が順調に進んでいる領域もありますが、なかなか進んでいないと感じる領域もあります。中でも映像や音声といったメディアのアクセシビリティ対応は今なお十分とは言いにくい状況にあると感じています。例えば、総務省のみんなの公共サイト運用ガイドライン（2016年版）は公共機関に対してJIS
X 8341-3:2016 レベルAAへの対応を求めていますが、レベルAAの範囲でメディアのアクセシビリティを確保できているサイトは現状ほとんどないと言えるでしょう。その一方で、以前よりもメディアのアクセシビリティを取り巻く状況が改善しつつあることも確かです。この節ではWCAG 2.0 レベルAAの範囲で対応が求められるキャプションと音声解説について見てみます。
キャプションはメディアの音声部分をテキストで提供しているもので、一般には字幕と考えてよいでしょう。WCAG 2.0 レベルAAの範囲では、事前に作成した動画に加えて、リアルタイムに提供する動画についてもキャプションを提供することが求められます（1.2.4 キャプション (ライブ)）。とはいうものの、リアルタイムに提供されている動画にキャプションを提供できているサイトはほとんどないと感じています。
これまでにも動画ファイルをアップロードすると自動的にキャプションを付与したり、書き起こしテキストを作成するサービスが複数存在しました（例えば、YouTubeなど）が、2017年にはリアルタイムに書き起こし作成（して、別言語に翻訳）するプロジェクトも発表されました（MicrosoftのPresentation Translator）。自動的に書き起こされたテキストが常に正しいわけではありませんが、メディアのアクセシビリティ対応を進める上での助けになることは間違いないでしょう。
一方、音声解説は映像の中で視覚的に表現されている情報を音声で説明するというもので、テレビ番組などでは副音声として提供されることがあります。音声解説の提供もレベルAAに含まれている（1.2.5 音声解説 (収録済) など）ものの、Webサイトで提供されているケースはあまりありません。これは、音声解説の作成にはスキルが必要ということに加えて、ブラウザーのサポート状況がまだ十分ではないという点もあると考えています。
音声解説では1つのメディアに複数の音声トラックを格納して、ユーザーが再生時に音声トラックを切り替えることが想定されていますが、ブラウザーによる複数音声トラックのサポートは限られています。MPEG-4について言えば、Internet Explorer 11やEdge、Safariは複数の音声トラックを認識し、切り替え用のユーザーインターフェースも提供しています[1]が、Google ChromeやMozilla Firefoxではサポートされていません。そのため、音声解説を提供しているサイトの中には音声解説なしの動画と、音声解説ありの動画を作成して別々に提供するという形をとっているところもあります[2]。
ブラウザーによる複数音声トラックのサポートは数年前から膠着状態にあると言えるのですが、JavaScriptライブラリーでの対応が改善[3]したり、Microsoft Officeでも複数音声トラックを切り替えるようになる[4]など、音声解説を取り巻く状況は着実に改善されています。
2018年はメディアを含めたWebアクセシビリティ対応がより一般化することを期待しています。
Accessible Rich Internet Applications（WAI-ARIA）
具体的な技術や仕様に目を向けると、2017年12月14日にWAI-ARIA 1.1が勧告に、WAI-ARIA Authoring Practices 1.1がノート（Note）になりました。WAI-ARIA 1.1で追加されたaria-modalやaria-currentは勧告になる前から使っていたという人も多いのではないでしょうか。すでにWAI-ARIA
1.1を取り入れてきた人には、勧告になったことによる影響はあまりないと思いますが、逆にまだの場合は今から押さえておきましょう。
WAI-ARIA 1.1と同時に、電子書籍向けのDigital Publishing WAI-ARIA Module 1.0も勧告になりました。この仕様は電子書籍などで利用するセマンティクスをWAI-ARIAの語彙として定義しているものです。脚注や参考文献リスト、例など、HTMLで表現できそうで、明示的に表現できなかったセマンティクスをrole属性に指定することができます。電子書籍リーダーなどがこれらのセマンティクスを読み取ることで、ユーザーのナビゲーションを支援したり、読み上げ内容を改善したりすることが期待されています。すでに英語圏の大手出版社、PearsonやHachetteといった出版社は電子書籍への指定を始めているか、準備中とのことです。また、SafariやMozilla
Firefoxといったブラウザーがrole属性に指定されたセマンティクスをスクリーン・リーダーなどの支援技術に伝えています[5]。2018年は電子書籍リーダーなどでの対応の広まりを期待しています。
