Smart Communication Design Company
ホーム > ナレッジ > コラム > 2014年 > TPAC 2014参加報告

TPAC 2014参加報告

2014年11月7日

第二本部(第一部) アクセシビリティエンジニア
黒澤 剛志

2014年10月27日から31日にかけて米国サンタクララで開催されたW3C(World Wide Web Consortium)主催のイベント、TPAC(Technical Plenary / Advisory Committee Meetings Week) 2014に参加してきました。W3CはWorld Wide Webで利用されている技術の標準化を行っている団体で、TPACはW3Cの年次総会というべきイベントです。期間中はW3C全体や各Working Groupにおけるミーティングが行われました。

W3Cにとって今年のTPACは大きな意味をもっていたと思います。2014年はWorld Wide Webが開発されてから25年、W3Cが発足してから20年にあたります。そして、TPAC 2014開催中の10月28日にはHTML5が勧告として公開されました。本コラムでは、そんなTPACの中から私が特に興味深いと思った内容を報告します。また、アクセシビリティBlogでは本コラムで取り上げていない話題も紹介しています(レポート1レポート2レポート3レポート4)ので、合わせてご覧ください。

仕様のモジュール化

TPAC開催期間中にHTML5の勧告が公開されましたが、TPACではその次のHTML仕様をどのように標準化するかの議論がなされました。HTML Working Groupでの議論の中心となったのはRobin Berjon氏による「After 5」や「HTML Modularisation」です。これらは、HTMLを巨大な仕様として標準化しつづけるのではなく、モジュールに分割して標準化すること、安定版と最新版だけをメンテナンスすることを提案しています。これらはソフトウェアの開発で一般的に行われている手法であり、それと同様の手法をとろうというものです。提案を要約すると次のようになります。

  • HTML5は細かな修正(エラッタ)だけを行う
  • 機能の追加などは、HTMLの仕様をモジュールに分割した上で、モジュールごとに行う
  • GitHubのプルリクエストなどを使って、より多くの人を標準化に巻き込む

この背景には巨大な仕様をメンテナンスすることは難しいという問題があります。メンテナンスすること自体以外にも、テストも難しいという点が挙げられていました。ある仕様がW3C勧告となるには、その仕様が2つ以上の実装によってサポートされていることを事前に確認しなくてはなりません。そのため、仕様をモジュール化していないと、仕様の一部分しか変更していなくても、テストは仕様全体に対して行う必要があるのか、という話がでました。仕様をモジュールに分けておけば、モジュールごとのテストで済む、というわけです。

仕様をモジュールにわけて標準化することは既にCSS(Cascading Style Sheets)などでも行われています。また、Protocols and Formats Working Group(PFWG)が標準化しているWAI-ARIAも次期バージョン(1.1)からモジュールに分割される見込みです。

このようにモジュール毎に分割して標準化することはW3Cでは比較的よく行われていますが、デメリットもいくつかあります。その1つが仕様の全体を把握するのが難しいというものです。TPAC 5日目のPFWGのミーティングでは、CSSの仕様にアクセシビリティ上の問題がないか、という議論がありましたが、現状PFWGもCSSの全てのモジュールをレビューできていないとのことでした。なお、ミーティングでは、CSS Working Groupは草案などの公開アナウンスをPFWGのメーリングリストにも送る、ということが決まりました。

HTMLをモジュールに分けて標準化する場合には、仕様の構成や公開場所がわかりやすくあってほしいと私は思いますし、Web制作者も、これまで以上に標準化と実装の進捗に注意を払う必要があると感じました。

ユーザーの設定に応じられるコンテンツ・アプリケーション

アクセシビリティを確保するには様々な観点がありますが、ユーザーの設定を尊重する、というのもその1つでしょう。例えば、アニメーションを考えてみましょう。(アニメーションの利用に支障がない人にとって)良いアニメーションはコンテンツや操作の理解を高めます。しかし、動きがあるとそれに気が取られてしまい他の場所に集中できない、という人もいます。そのため、いくつかのOSではアニメーションを無効にする設定やアニメーション効果を軽減する設定をもっています。ですが、Web技術にはこのようなユーザーの設定を取得する仕組みがありませんでした。そのため、アニメーションを無効にしたいユーザーは、自分で設定を変更したり、停止ボタンを押したりする必要があります。ですが、もし、アニメーションを無効にしたい、という設定をコンテンツが認識できれば、コンテンツ側で最初からアニメーションを無効にしておくことができます。

私が所属しているIndie UI Working Groupは大きく2つの仕様の標準化を行っていますが、その1つがユーザーの設定をWebページから取得できるようにしよう、というものです。これはIndieUI: User Contextと呼ばれています。

TPAC 2日目のIndieUI Working Groupのミーティングでは、この仕様に関連したWebKitのデモが行われました。OS Xには画面反転機能がありますが、この機能を有効にすると、写真などの画像も反転して表示されます(ネガ状態で表示されます)。文字を読みやすくするために画面反転を使っている場合には、写真は反転しない(ポジ状態で表示する)方が読みやすいでしょう。デモでは、CSSのメディアクエリーを使って、画面反転機能を使っているかどうかを検出し、CSSのfilterプロパティを使って、写真を再度反転する(ポジ状態で表示する)ことが行われました。

なお、該当メディアフィーチャー(inverted-colors)は、当初IndieUI: User Contextの一部でしたが、現在はCSS Working Groupが標準化しているCSS Media Queries Level 4(Editor's Draft)に取り込まれています。なお、対応するDOM APIなどは引き続きIndieUI: User Contextに含まれています。

全てのWebページ、全てのアプリケーションがこの仕組みを使う必要があるとは私は思いませんが、HTMLアプリケーションがネイティブアプリケーションと遜色のない機能を提供するには、ユーザーのシステム設定に応じてコンテンツや機能を調整する仕組みが必要だと私は考えています。

2015年は日本で

今年のTPACは米国で行われましたが、TPAC 2015は札幌で開催される予定です(10月26日から30日)。さらに、TPAC 2015の翌週、11月1日から6日に横浜でIETF(Internet Engineering Task Force) Meetingが行われます。IETFで標準化が進んでいるHTTP/2は早ければ2015年の前半に正式なRFCとなる見込みです。2015年は今年以上に日本から盛り上げていきたいと考えています。