Test the Web Forward Shenzhen & TPAC 2013参加報告

2013年11月に中国深センで開催されたW3C主催のイベント、Test the Web Forward ShenzhenおよびTPAC（Technical Plenary / Advisory Committee Meetings Week）2013に参加してまいりました。

深センは香港のすぐ北にある中国本土の都市です。高層ビルやマンションがいくつも建っているだけではなく、現在も新たなビルや地下鉄などの建設が続いている活気あふれる街でした。

11月9日に行われた Test the Web Forward Shenzhen（深セン） はWebに関連した仕様のテストを作成するイベントです。W3Cの標準化プロセスでは、それぞれの仕様がブラウザーなどによって実装されていることが鍵になりますが、その確認にはテストが必要になります。近年は仕様の数が増えてきていることもあり、仕様に対してテストが足りない状況が続いています。そこで Test the Web Forward では仕様のEditor（編集者）を始めとする専門家と一般の参加者が集まってテストを作成するイベントを行っています。Test the Web Forwardが中国で開催されるのは北京、上海に続いて3度目となり、今回は300名余が参加したとのことです。なお、日本国内では6月7日、8日に東京で Test the Web Forward Tokyo が開催されています。

Test the Web Forwardではテストの書き方やテストが必要とされている仕様の紹介の後、実際に参加者がテストを作成していきますが、その際にEditorやブラウザーに実装した人たちに仕様について直接確認することができます。私は今回、HTML Canvas 2D Contextのフォーカスリング（関連： アクセシビリティBlog：「canvas要素のフォーカス領域を指定する」 ）に関するテストを書きましたが、仕様の状況について会場で仕様のEditorと直接確認することができ、Test the Web Forwardならではと感じました。

翌週の11月11日から15日にかけて行われた TPAC では、W3Cの総会となるPlenary Dayや各Working Groupでのミーティングなどが行われました。私は13日のPlenary Dayの他、11日と12日は UAWG（User Agent Accessibility Guidelines Working Group） のグループミーティング、14日と15日は Indie UI WG（Independent User Interface Working Group） のグループミーティングに参加しました。

それぞれのグループミーティングで議論されたことを簡単にご紹介します。

もし仕様に基づいてアクセシブルに作った（はずの）コンテンツを、ブラウザーがアクセシブルな形でユーザーに届けなかったとしたら、どうでしょう。例えば、コンテンツ側が画像には代替テキストを設定したとしても、代替テキストを必要とするユーザーに代替テキストを知るすべがなければ（ブラウザーにそのような機能が存在していなければ）、アクセシブルであると言えるでしょうか？

このような問題を未然に防いだり、対応を求めたりするためのガイドラインがUAAG（User Agent Accessibility Guidelines）です。このガイドラインはユーザーエージェント（User Agent、ブラウザーやメディアプレーヤーのようにコンテンツを取得してユーザーに提供するソフトウェア）が備えるべきアクセシビリティの要件をまとめています。UAAGはW3CのUAWGが策定を進めており、TPACの直前に UAAG 2.0のLast Call Working Draft が公開されました（関連： アクセシビリティBlogの記事「User Agent Accessibility Guidelines (UAAG) 2.0 Last Call Working Draftに対する意見募集」 ）。TPACのUAWGのミーティングではUAAG 2.0 Last Call Working Draftの各達成基準について、ブラウザーやブラウザーの拡張機能としてそれが実装されているかどうか、あるとすればそれは何かを挙げていました。

多くの達成基準にはなんらかの実装が挙げられていましたが、達成基準の中には長く実装されていない、修正されていないものもあります。例えば、多くのブラウザーではページの拡大・縮小やウィンドウサイズの変更を行うと、以前注目した部分（Point of Regard）とは別の部分が表示される、という問題があります。これは特に弱視のユーザーがページの拡大率を変更すると以前注目していた部分がわからなくなるという点が取り上げられていました。この問題はアクセシビリティの分野では何年も前から議論されていますが、多くのブラウザーで修正されていません。それはそもそも技術的に修正が難しいのか、単に修正をするためのリソースが割かれてこなかっただけなのか、などをブラウザーベンダーとともに考える必要があると感じました。

UAWGのミーティングで印象に残ったことは、コンテンツ制作側が個々にアクセシブルでない機能を作るよりも、ブラウザーがアクセシブルに実装した機能をコンテンツ制作側から使ってもらおう、という話です。例えば、HTML5のvideo要素やaudio要素にはビデオやオーディオの再生・音量調整などを行うコントロールをブラウザーに表示させる機能があります。今のところコンテンツ側がブラウザーのコントロールにスタイルを設定することは難しいですが、UAWGのミーティングではコンテンツ側からコントロールにスタイルを設定できるようにして、Web制作者にとってより使いやすくしようという話も取り上げられていました（現段階では、Shadow DOMの利用を検討しているようです）。

私はTPAC会期中にUAWGへの参加を誘われ、メンバーとして参加しました。ユーザーが実際に情報を得たり操作を行ったりする部分（ユーザーエージェント）のアクセシビリティが確実に担保されるよう、UAWGを通して活動していきたいと考えています。

Indie UI WGではデバイスや環境に依存しないユーザーインターフェースを実現するために、2つの仕様を検討しています。Indie UI: EventsとIndie UI: User Contextです。

Indie UI: Eventsはユーザーの物理的な操作を抽象化して、操作の意図をDOMのイベントとして表現するための仕様です。これによってユーザーがマウスを使っているのか、キーボードを使っているのか、あるいは今はまだ存在していないデバイスを使っているのかに関わらず、ユーザーの操作の意図をコンテンツに伝えることができます（関連： アクセシビリティBlogの記事「IndieUI: Events 1.0の最初の草案が公開される」 ）。TPACのミーティングでは後方互換性や既存のDOMイベントからのスムーズな移行などが検討されました。例えば、Indie UI: Eventsのオブジェクトを既存のイベントと互換性がある形（スーパーセット）にすることや、Indie UI: Eventsへの移行を助けるためのPolyfillの開発も検討されました。

Indie UI: User Contextはユーザーの（アクセシビリティに関する）設定や状況をコンテンツが理解することで、よりユーザーにあった形で情報や機能を提供できるようにするための仕様です。例えば、ユーザーが画面の色反転機能を使っていることがわかれば、コンテンツ側で画像の色を再反転したり、背景や影を調整したり、といったことができるようになります。また、ミーティングでは、EPUBでの利用を想定したアクセシビリティに関するメタデータ Accessibility Metadata Project とIndie UI: User Contextとの関係性が検討されました。ユーザーの設定や状況を自動的に認識して、その状況にあったコンテンツを検索できると良い、といった話を興味深く聞きました。

2012年4月にW3CでIndie UI の取り組みが始まってから1年半ほどが経ちますが、Indie UI: Eventsは標準化なども進み、実際に使えるようになる日もそう遠くないように感じました。今後もIndie UIには注目していきたいと考えています。