あけましておめでとうございます。株式会社ミツエーリンクスの黒澤剛志です。私は主にフロントエンド技術（HTMLやCSSなど）からWebアクセシビリティを見てきました。本稿では、フロントエンド技術の標準化や実装動向とJIS X 8341-3:2010への対応という側面から見たWebアクセシビリティの短期的な予測を寄稿させていただきます。
Web標準とWebアクセシビリティ
HTML5
2014年のWeb標準と言えば、まず、HTML5の勧告が予定されていることが挙げられます。HTML5は既に勧告候補（Candidate Recommendation）に達しており、これから大きく変わることはまずありません。新しい機能の検討は、引き続き、HTML Living StandardやHTML 5.1などで行われるでしょう。
例外は拡張仕様の取り込みと実装されなかった機能の削除です。拡張仕様ではImage Description Extension（longdesc属性）の策定が進んでいます。今年は、拡張仕様がHTML5に取り込まれるかも含めて注視が必要でしょう。
また、アクセシビリティの観点からはブラウザーが要素や属性を（視覚的、DOM的に）実装したかだけではなく、支援技術（スクリーン・リーダーなど）にセマンティクスが伝わるかどうかも重要です。これに関して、W3CはHTMLとアクセシビリティAPIの対応関係をまとめたHTML to Platform Accessibility APIs Implementation Guideの策定を進めています。ブラウザーはアクセシビリティAPIを介して支援技術などにWebページの情報を伝えています。ブラウザーが提供する情報が揃ってくることで、（アクセシビリティAPIを利用している）支援技術もユーザーに情報や機能を提供しやすくなるでしょう。
HTML5で現在も細かな修正や議論が行われている部分にはHTMLとWAI-ARIAの対応関係があります。HTMLとWAI-ARIAを組み合わせて使うことは既に一般的になっていますが、HTMLの要素や属性だけでセマンティクスが表現できるならば、WAI-ARIAの属性を追加せずにHTMLの要素や属性を使うべきという議論があります[1]。HTML5やHTML 5.1、HTML Living Standardにはそれぞれ、HTMLのセマンティクスとWAI-ARIAのセマンティクスとの対応関係がまとめられていますが、一部内容が異なる部分があります。現在のブラウザーの実装はおおむねHTML5/HTML 5.1を基本としていますが、今後も標準化および実装の状況には注意を払う必要があるでしょう。短期的には、コンテンツ制作側がやや冗長にWAI-ARIAの属性を指定する必要があるかもしれません。
WAI-ARIA
WAI-ARIAに関しても2014年は重要な年になるでしょう。2013年9月にW3C WAI（Web Accessibility Initiative）はWAI-ARIAのFAQページを更新し、WAI-ARIA 1.0（現在：勧告候補）を2014年の早い段階で勧告案（Proposed Recommendation）にし2014年内に終了させる（勧告とする）見込みであることを明らかにしました。また、WAI-ARIAとアクセシビリティAPIとの対応関係をまとめたWAI-ARIA 1.0 User Agent Implementation Guideも勧告候補になっており、ブラウザー間での高い互換性も期待できます。
2013年9月にはWAI-ARIA 1.1の最初の草案が公開されました。WAI-ARIA 1.1はHTML 5.1に対応したいくつかの機能をWAI-ARIA 1.0に追加するマイナーアップデートになる模様です。9月に公開された草案ではlongdesc属性に相当するaria-describedatが追加されています。大きな機能の追加はWAI-ARIA 2.0で行われる見込みで、今年は、WAI-ARIA 1.1と2.0の動向に注目が集まるでしょう。
Canvas 2D Context
Canvas 2D Context（canvas要素における2次元グラフィックスの描画API）には描画領域のどこに注目すべきか（フォーカスがあたっていると判断されるべきか）を指示する方法がありません。これは弱視のユーザーを始めとした拡大鏡ソフトウェアを使っている場合に拡大すべき場所がわからない、といった問題を引き起こします。この問題に対処するために、Canvas 2D Context Level 1では2つの枠組みが検討されていました。
1つはフォールバックコンテンツに対応したパスをフォーカス領域として設定するdrawSystemFocusRingとdrawCustomFocusRingです。これらのメソッドは、引数に指定された要素にフォーカスがあたっているかどうかをブラウザーがチェックし、フォーカスがあたっていればシステムのフォーカスリングを描画する、もしくはカスタムのフォーカスリングを描画すべきかどうかを判断できるというものです。
もう1つは描画領域にヒット領域を指定するAPI（addHitRegion/removeHitRegion）です。ヒット領域とフォールバックコンテンツとを関連づけたり、ヒット領域同士に論理的な親子関係を設定したり、といった機能が検討されていました。
drawSystemFocusRingとdrawCustomFocusRingはGoogle ChromeとMozilla Firefoxによって実験的にサポートされましたが、「仕様に曖昧な部分が残る」「名前から実際の動作が想像しにくい」などにより、Canvas 2D Context Level 1からの削除を含めて議論されています（なお、ヒット領域は現在も実装がありません）。今年は、Canvas 2D Contextをよりアクセシブルにする方法の検討がLevel 2を中心に続けられるでしょう。
Indie UI: Events
Webを利用するデバイスの多様化が進んでいるため、様々なデバイスで利用できる・操作できるユーザー・インターフェースを作るためにやるべきことは増えています。例えば、カスタムのスライダーを作る場合には、キーボードやマウス、タッチ操作などへの対応が必要になるでしょう。また、タッチスクリーンでスクリーン・リーダーを使っている場合のジェスチャー操作のように、現在のDOMイベントでは認識することが難しい操作もあります。
Indie UI: Eventsはユーザーの操作を抽象化して意図のレベルでWebページに伝えるためのDOMイベントを定義する仕様です。例えば、スライダーではユーザーがキーボードを使っているか、マウスを使っているか、タッチスクリーンを使っているかなどによらず、Webページはユーザーがスライダーの値を1つ増やしたがっている、最小値にしたがっているという意図のレベルで認識・処理できるようになります。このことによって、これまで対応が難しかったユーザーの操作に対応しやすくなることや、コードの簡潔化・明瞭化がもたらせることを期待しています。
この仕様はIndie UI Working Groupが標準化しており、同Working GroupはIndie UI: Events 1.0を今年の早い段階で最終草案（Last Call Working Draft）としたい考えです。既にAppleがWebKitに対応の基礎となるコードを追加する（Bug 117367 - IndieUI: Add basic IndieUI infrastructure）など、実装も少しずつ進みつつあります。また、Indie UI Working GroupはPolyfillの開発も検討しており、こちらの動向も注意が必要でしょう。
WebVTT
キャプションフォーマットの1つ、WebVTT（Web Video Text Tracks）のサポートは今年も広がるでしょう。既にGoogle Chrome、Safari、Internet Explorer 10以降はなんらかのレベルでWebVTTをサポートしています。Mozilla FirefoxはWebVTTをサポートした安定板をリリースしていませんが、開発版では実装が進んでいます。2014年にはMozilla Firefoxの安定版でもサポートされることを期待しています。
一方、標準化についても、WebVTTをW3C勧告にするための動きが進んでいます。これまでWebVTTはText Tracks Community Groupで議論されてきましたが、W3CのTimed Text Working Group[2]の作業範囲にWebVTTの標準化も含めるようにRecharterが進行中です。現在公開されているTimed Text Working Groupの新Charter草案では、WebVTT 1.0は2014年3月に勧告候補、2014年11月に勧告というマイルストーンが設定されています。
既にWebVTTに対応しているブラウザーでもサポートのレベルはばらついているため、仕様の安定化と互換性の向上が望まれます。
数式
2013年は数式に関する動向も印象的でした。ブラウザーのMathMLのサポートは必ずしも良いものとは言えません。Internet Explorerは現在もMathMLに対応していませんし、Google ChromeはMathMLのサポートを打ち切りました（Issue 236462: Remove MathML）。
しかし、Google Chromeの拡張機能として動作するスクリーン・リーダー、ChromeVoxが数式の読み上げをサポートしたのも2013年です。また、AppleのSafariもMathMLの情報をある程度、支援技術に提供しはじめています。数式の情報をアクセシビリティAPIで表現する方法が確立していない、という問題はありますが、今年も数式をアクセシブルにする方法について議論が続くものと考えています。
JIS X 8341-3:2010への取り組み
では、実際のWebコンテンツ、Webサイトのアクセシビリティはどうでしょうか。ここではJIS X 8341-3:2010の視点から簡単に見てみたいと思います。2013年は公共機関だけではなく、民間企業でもJIS X 8341-3:2010への対応や試験結果の公開、アクセシビリティ方針の公開などが進みました。その中には、これまで以上にアクセシビリティに対する積極的な姿勢も見られます。
例えば、2013年6月にヤフー株式会社が公開したウェブアクセシビリティ方針では「ユーザーファースト」という文脈にWebアクセシビリティを位置づけています。これまで障害者や高齢者に対する「配慮」という文脈で語られがちであったWebアクセシビリティを、欠かすことのできない本質的なものとして位置づけているように私は感じました。
また、2013年11月にコニカミノルタが公開したウェブアクセシビリティ方針では動画コンテンツのアクセシビリティにも言及しています。それによるとコニカミノルタは既に100本以上の動画コンテンツにキャプション（字幕）を提供しているとのことです。アメリカ合衆国では連邦通信委員会（FCC）がインターネットで配信されるTV番組に対してもクローズドキャプション（ユーザーが表示・非表示を切り替えられるキャプション）を提供するよう指令を出しており、グローバルに展開している企業では、動画のアクセシビリティは今後も重要性が増していくでしょう。
今年は、昨年以上に公共機関や民間企業を問わずJIS X 8341-3:2010への対応とアクセシビリティの向上が進むことを期待しています。
