“Enabling an Accessible Web 2.0”の紹介

2007年5月19日 渡辺隆行 （最終更新： 2007年05月19日 12:24 ）

W4A2007 (May 7 and 8, 2007, Banff, Canada)のBecky Gibsonのキーノート論文、“Enabling an Accessible Web 2.0”の紹介。（おおざっぱな訳なので日本語の内容に責任は持ちません。詳細は原論文を参照してください。）

概要

• 次世代Webは、rich Internet applicationをもたらす技術に支えられている。
• これらは障害者に影響を与える。
• ARIA（Accessible Rich Internet Application）が開発中。Webの部品（コンポーネント）にセマンテック情報を与え、アクセシビリティを増す。
• ツールキットやテストツールによって、Web2.0必須のアクセシビリティを達成するのが容易になる。

1. INTRODUCTION

略

2. WHAT IS WEB 2.0?

• Web 2.0：O'Reilly Media at a conference 2004、次世代Web一般を指す。
• 静的なデータではなく、アプリケーションになる。
• キーとなる概念は「ユーザ参加」と「ダイナミックなインターラクション」

2.1 Web 2.0 Technologies

• HTML、Scripting（JavaScript）、CSS。サイトの59％がJavaScript、54％がCSSを使用。
• CSS：スタイリッシュな要素をWebにおける。
• JavaScript：プログラミングで、スタイルの更新、計算、ロジックの追加、データの検証、XmlHttpRequestを用いてページを非同期に更新

• XmlHttpRequest（XHR）：ページの一部を更新するために、httpの標準的なプロトコルで（JavaScriptを使って）データを転送するAPI。
• 元々は、転送できるデータはXML形式だったが、今は他の形式も一般的に使われる。
• Ajax（Asynchronous JavaScript and XML）：ScriptingとXmlHttpRequestによるデータ転送
• Ajax：ページ全体を転送するのではなく、ページの一部を非同期に（ダイナミックに）書き換える。

• ネットワークが早くなっている。
• マルチメディアもWeb 2.0の主要をしめる。
• ビデオ、サウンド、Flash
• マルチメディアの生放送にキャプションをつける問題が残っている。

2.2 Web 2.0 Implications

• インターラクションが複雑 → ユーザIFもリッチでインターラクティブ。単純なナビゲーションリンクのリストを使っている場合ではない。
• サイトが複雑になるということは、デスクトップアプリケーションにあるような洗練されたUI（Treeコントロール、タブキーでナビゲーションするインターフェース、表示位置を動かせるダイアログ、ツールバー）が必要ということ。
• textarea要素に文字を入力するのでは飽き足らない。スタイリッシュなリッチテキストを入力したい。
• この状況がアクセシビリティの問題を生じる。

2.3 Web 2.0 Accessibility Concerns

Web 2.0は色々な利点があるが、新技術はすぐにアクセシブルにならない。

• ヴィジュアル（リッチでダイナミックなインターラクション）で、マウス操作を必要とする。
• ページの一部が更新すると、アクセシブルなコンテンツでない場合がある。
• 支援技術がユーザ・インターラクション・モデルを理解できず、ページの一部の更新に気がつかず、その更新をどのようにユーザに伝えて良いか分からない。

だから、セマンティックを追加し、障害を持つユーザに適合したIFやナビゲーション方法を提供することで、Web 2.0をよりアクセシブルに出来る。

3. TECHONLOGIES to ENABLE an ACCESSIBLE WEB 2.0

3.1 Accessible Rich Internet Applications

• ARIA：W3C/WAIのPFWGが作成中の仕様。
• ARIAの目的：(X)HTMLにsemantic情報を追加して、支援技術が、UIコンポーネントやユーザとのダイナミックなインターラクションを適切に表示できるようにする。
• ARIA：インプット・フォーカスとフルキーボード・ナビゲーションも求めている。

3.1.1 Providing Additional Semantics

• リンク、フォーム、リスト、見出し要素などはその役割が仕様で決まっているので支援技術にも役割りが伝わる。
• Web 2.0では、もっと複雑な部品（Treeコントロール、タブ・パネル、ポップアップ・ダイアログ、リッチテキストの編集エリア、更新リージョン、オンライン・チャット、など）が必要となる。
• Scriptと、divやspan要素で、こうした部品を作ることになる。
• XmlHttpRequestで、データが変わったり、長大なデータセットをナビゲーションする際に、ページや部品をダイナミック（非同期）に変化させることができる。
• でも、支援技術は、これらの新しい部品や非同期更新の意味（Semantics）を知る由もない。

• デスクトップ・アプリケーションは、既に恁うした部品を（コントロールとして）持っていて、（MSAAのような）アクセシビリティAPIも定められている。
• ARIAの主目的は、(X)HTMLのマークアップに、（アクセシビリティに必要な）Semanticを追加すること。そうすれば、ブラウザがそのSemanticデータを解釈して、OS固有のアクセシビリティAPIを使って、支援技術に伝えることができる。つまり、支援技術はそれがツリー・コントロールだと分かり、階層構造や展開・折りたたみなどを示すことが出来る。

• ARIAの仕様は、部品に記述する、role（役割）とstate（状態）の標準セットを定義する。
• WindowsのFirefox 1.5以降は、ARIAに対応している。
• Window-Eyes 5.5以降が対応（フルサポート？？）。JAWS 7.1では一部サポート、JAWS 8.0ではより対応が進む。

3.1.2 Input Focus and Keybord Navigation

• ユーザがWebページをナビゲーションしたりインターラクションしたりするためには、インプット・フォーカスとキーボード・ナビゲーションが不可欠。
• 支援技術は、ページ内のどの要素にフォーカスがあたっているかを追跡して、それに関する情報をユーザに伝える必要がある。
• DOMでは、全ての要素がキーボードイベントを受け取ることが出来る。
• ところが今のブラウザーは、デフォルトでは、リンクとフォームしか、キーボードを使ってフォーカスを当てることが出来ない。
• キーボードでは、Tabキーを使ってフォーカスを移動するが、Web 2.0のような複雑な部品を使う場合は不十分。
• ARIAでは、tabindexを使って、フォーカスを受け取る要素を指定する。（IEと、FF 1.5以降で利用できる）

• tabindex属性は、ほぼ全ての要素に付加できる。
• tabindexの値は、その要素がどのようにフォーカスを受け取るかを示す：
  • 0：フォーカスを受け取る要素となり、タブキーでフォーカスを当てることが出来る。（フォームやリンクはデフォルトでフォーカスが当たるので tabindex=0を指定する必要はない。）
  • 正：上記の要素より先にフォーカスが当たる要素を示す。
  • 負：プログラムによりフォーカスが当たる要素となる。Web（のScripting）作者は、キーボードイベントを処理して、特定の要素にフォーカスを当てることが出来る。たとえば、矢印キーで特定の要素間をナビゲーションするように設定できる。（Beckyは -1 をTreeコントロールに使っている。）

• Tabindex値を指定することで、Treeコントロールやタブパネルなどの複雑な部品間をtabキーでナビゲーションできる。
• ユーザは、フォーカスが当たった部品の種類や現在の状態（開いているとか選択されているとか）やその他の性質（グループや階層など）を知ることが出来る。
• ユーザは、デスクトップアプリケーション同様に、部品の内部を、矢印キーでナビゲーションできる。
• Beckyのサイトにある「Simple Ajax Application」のTreeコントロールの例：Tabキーでページ内を移動し、Treeコントロール（の最初の要素）にフォーカスを当てることが出来る。そこで右矢印キーを押すと、展開する。下矢印で子階層に降りていく。（矢印キーのよる移動は、このTreeコントロール内に限られている。Tabキーを押すと、Treeコントロールから抜け出す。）
• Window-Eyesは、Treeコントロール内のナビゲーション時に適切な説明を追加する。
• tabindexの指定により、キーボードナビゲーションが容易になった。ARIAにより、スクリーンリーダに部品の状態が伝わる。（今までは、リンク要素のリストでTree構造を作り、タブキーで移動しEnterで展開し、それでもsemanticな情報を支援技術に伝えることが出来ない。）

<div class="xtree axs tree" tabIndex="-1"
  onclick="return treeItemClick(event);" ondblclick="return treeItemEvent(event);"
  onkeydown="return treeItemEvent(event);" onkeypress="return treeItemEvent(event);" id="tree">

  <div id="antDiv">
    <img src="plus.gif" class="axs presentation" onclick="imgToggle(event);" alt="" />
    <span tabindex="0" class="xtreeitem axs treeitem expanded-false" id="firstTS" 
	  onfocus="this.className='treeitemfocus';" onblur="this.className='treeitem';">AntArctic</span>
  </div>
  <div class="collapsedgroup axs group" id="antGroup">
    <div id="penguinPar">
      <img src="plus.gif" class="axs presentation" onclick="imgToggle(event);" alt="" />
      <span class="xtreeitem axs treeitem expanded-false" >Penguins</span>
    </div>
    <div  class="collapsedgroup axs group" id="penguinGroup">
      <div><span  class="xtreeitem axs treeitem" >Adelie</span></div>
      <div><span class="xtreeitem axs treeitem">Chinstrap</span></div>
     略
  </div>
</div>

3.1.3 Dynamic Updates

• Web 2.0の特徴の一つが、（ページの一部が）非同期に（ダイナミックに）更新すること。
• 更新はユーザのリクエストが元になることもあるし、株価情報のように自動的に更新することもある。
• ARIAは、regionを使うことにより、ページの一部が更新することにも対応している。

• ページ内の色々な部分は、その領域(region)の役割（role）を示すことで識別できる。
• Regionには、領域の種類(type)とどのように更新されるかを示す属性が与えられる。
• 更新の種類と、更新をユーザに知らせる方法を示すsemanticを持つ。
  • live=POLITENESS_SETTING：
    • polite：ユーザが現在行っている作業が終わるまで、更新を通知しない。
    • rude：最優先で更新を通知する。
    • off：デフォルトの状態。更新をユーザに通知しない。
    • assertive：警告メッセージのように、ユーザにすぐに知らせる必要はあるが、最優先ではないもの。
  • atomic=BOOLEAN
    • false：デフォルト。ページの一部が更新されたら、支援技術はその部分だけ通知する。
    • true：ページの一部が更新されたら、ページ全体を再提示する。
• 注：Regionの詳細は、W4A2007の「Ajax Live Regions: Chat as a Case Example」(PDF)、Peter Thiessen and Charles Chen が参考になる。
• regionは、FF3でサポートされるが、支援技術側の対応も必要。（Fire Voxは、一部対応済み！）

3.2 Accessibility API's

• OS毎にアクセシビリティAPIがある：
  • MS Windows：MSAA（Microsoft Active Accessibility）とUI Automation
  • Linux：Linux Accessibility Toolkit （ATK）
  • Mac OS X：Mac Accessibility API
  • （OSではないけれど、JavaはBuiltin Accessibility機能を持つ）
• 支援技術は、使用されている部品の名前（name）、役割（role）、状態（state）、説明（descriptions）を知る必要や、部品の変化やイベントに対応する必要がある。

• MSAAはだいぶ前に作られたので、Web 2.0に対応できないところがある。
• IBMは、MSAAの延長として、IAccessible2を開発し、オープンソースとしてLinux Foundationに寄贈した。
• IAccessible2は、JavaとLinux用のインターフェースが追加された。
• ODF（Open Document Format）をWindowsとLinuxで同じようにアクセシブルに出来る。
• Web 2.0との関連で言えば、IAccessible2は、ARIAのlive regionやダイナミックな編集に必要な機能を提供している。
• IAccessible2は、FF 3に実装予定。Eclipseにも実装中。NVDAが対応。ZommTextも次バージョンで対応する予定。

3.3 Adaptation Strategis

• Semantic Webの背景にある考え：ユニバーサルな形式でWebでデータを提供し、ソフトウェアでできたエージェントがそのデータを解釈できるようにする。
• つまり、全てのデータが検索しやすくなりユビキタスになる。
• ユニバーサルな形式では、違う形式やモダリティでデータを表現することも出来る。

• RDF（Resource Descriptor Framework）：Semantic Webで使われる言語。
• リソースを、アプリケーションが利用できる形で表現。
• URL（Uniform Resource Locator）で物（item）を同定し、性質（propertiy）と値（value）で記述する。
• RDFはXMLなので、どんな種類のデータを表現することもできる。
• RDFはによって、色々なデバイスでデータを表現できるデバイス非依存が実現する。
• これはモバイルWebのみならず、アクセシビリティでも重要。

• UB Accessが創設したSemantic Web Accessibility Platform （SWAP）はRDFを使って知識ベースのアクセシビリティを構築しようとしている。[11]
• SWAPは、Webページにアクセシビリティに関する表記を追加して、プロキシサーバーがそれを解釈して、それぞれのユーザに適合したデータに変換する。

• Tronto大学のFluid Project [12]：Web 2.0技術を用いて、ユーザニーズに合わせたユーザインターフェースをカスタマイズする。

4. DEVELOPING an ACCESSIBLE WEB 2.0

• Web 2.0のアクセシビリティに対応した技術は重要だけれども、実際に使われなければ意味がない。
• 今日では、ブログやWikiを用いて誰でもWebに情報を発信できる。技術力がなくても簡単にWebを作れるソフトウェアが提供されている。こうしたツールにアクセシビリティを組み込むことが重要。
• 必要な第一歩は、ツールキットのアクセシビリティ向上、次に、これらのツールキットを組み込んだアプリケーションがアクセシビリティを維持すること。

4.1 Toolkits

オープンソースのJavaScriptとAjax用ツールキットがいくつかある。ブラウザの違いを吸収したり、イベントハンドルやAjaxインターラクションやデータバインドやグラフィック効果用の基本機能ややカスタマイズ可能なリッチなUIを提供する。

• Dojo
• Google Web Toolkit
• Open Rico
• Prototype
• 他 TIBCO、Yahoo UI、Zimbra Kabuki、scriptaculous
• DWR, Direct Web Rooaming：JavaScriptでJavaにアクセス
• これらのツールキットの大部分はアクセシビリティを考慮しようとしている。

• Dojo
  • "Easy" Ajax
  • Data Binding (Tree, Grid, Select,...)
  • Full event system
  • Browser abstract layer
  • UI widgets (user interface component)
  • Dual Licenced (BSD, Academic Free Licence)
• Dijit （core Widget set for Dojo toolkit）は、2007年秋に予定されているDojo 1.0のリリースで、フルにアクセシブルになる予定。
• Dojo 1.0
  • Fully accessible
  • i18n
  • FF 2.0, IE 6+, Safari (latest version)
• Dojoは、フルキーボードアクセスと支援技術のサポートを実現するために、ARIAに対応した初のツールキットの一つになるはず。
• 詳細は、Dojo Bookの8章「国際化とアクセシビリティ」参照。アクセシビリティに配慮してcore widgetを作成・利用する方法を示す文書も作成する予定。

• オープンソースではないけれど、Bindowsも、アクセシビリティを考慮して作成されたAjaxフレームワーク。
• リッチなUIを持っていないけれど、Windows OSのIE上で、508条に対応していると主張している。

4.2 Integrated development Environments

• ツールキット以外に、統合開発環境（IDE）もWeb 2.0の開発を容易にする。
• IBMの Rational Web Developer は、アクセシビリティに配慮したUIをたくさん持っている例の一つ。
• MicrosoftのASP.NETは、Visual Studioに組み込まれているフリーなフレームワーク。
• Ajax Tooling Frameworkは、Web 2.0の開発を容易にするEclipseのプラグインで、前述したオープンソースなツールキットの一部が組み込まれている。
• 渡辺メモ：Aptana：Ajax開発用IDE。Eclipseのプラグインとしても、単独のIDEとしても動作する。V0.2.8で国際化された。前述のツールキットの一部が組み込まれている。

5. TESTING an ACCESSIBLE WEB 2.0

• Web 1.0のテストツールはたくさんある。HTMLが、WCAG 1.0や508条などのガイドラインに準拠しているかどうか評価して、結果を報告する。
• こうしたツールは、ある種のエラーに対しては膨大なレポートを生成し、ある種のエラーは見逃す欠点があると批判されている。
• 例：画像にalt属性があるかどうかは判定できるが、適切な代替情報が提供されているかどうかは分からない。
• 作者だけが、判断できる。

• こうしたツールのほとんどは、ユーザに表示されるHTMLを評価しているので、サーバサイドで生成されるダイナミックなWeb技術（ASP、JSP、Ruby on Rails、PHP Hypertext Processor）の場合、エラーの本当の原因（発生箇所）を突き止めるのは困難である。
• Web 2.0のようにページの一部が更新したりする状況では、評価はさらに困難になる。
• したがって、Web 2.0に対応した新しいアクセシビリティ・テストツールが必要である。

5.1 Rule-based Accessibility Validation Environment (RAVEN)

• Rule-based Accessibility Validation Environment (RAVEN)：IBMがEclipseのプラグインとして開発したJavaのGUIアプリケーションのアクセシビリティ評価ツール。[15]
• RAVENは、Aspect Oriented プログラミング技術に依存していて、アクセシビリティ評価の、非invasive（侵入）な自動あるいは半自動な手法を提供する。
• XMLで記述されたルールのセット。
• （略。渡辺：RAVENは まだ勉強していないので、要約するのが難しい。）

• RAVENはJava以外にも使える。
• ダイナミックHTMLにも対応した。ARIAに対応する計画もある[16]

5.2 Functional Web Accessibility Techniques and Tools

• イリノイ大学は、Webアクセシビリティのベストプラクティス（最良の実践事例）一式と、Functional Web Accessibility Evaluatorを開発。
• Functional Accessibility Evaluator （FAE）：このベストプラクティスに基づいて、Webサイトを評価。[17]
• アクセシビリティのベストプラクティスは五原則に基づく：
  1. Navigation and Orientation（ナビゲーションとオリエンテーション）
  2. Text Equivalents（代替テキスト）
  3. Scripting and Automation（スクリプトと自動化）
  4. Styling（スタイル）
  5. Standards Coding（標準に沿ったコーディング）
• 既存のツールがタグや属性ベースで判断しているのに対し、FAEは最良と思われるコーディング技術に基づいて評価する。

• イリノイ大学は、Mozilla/Firefox Accessibility Extensionも開発している。
• このアドオンは、Webにある情報のアクセシビリティに関して視覚的なフィードバックをア与え、FAEと一緒に使うことも出来る。
• 開発者や評価者やユーザーは、画像やCSSなどを切ったり入れたりすることが出来る。
• 見出しや代替テキストやラベルを視覚的ハイライトしたりダイアログウィンドウに表示したりもできる。
• DOMに問い合わせをすることにより こうした機能を実現しているので、Webアプリケーションをダイナミッにテスト可能。
• 正しい実装方法やARIA技術の情報も表示。

ARIAに対応した開発・テストツールを持っていると言うことが、こうした仕様の適用を促進し、アクセシブルなWeb 2.0を実現する重要な鍵である。

6. SUMMARY

略

Related information

WAI-ARIA:

Roadmap for Accessible Rich Internet Applications

Dojo:

The Dojo Book, Chapter 8: Internationalization and Accessibility

RAVEN:

Feigenbaum and Squillqance, (2006) Accessibility Validation with RAVEN

BeckyのARIA関連のWebサイト

WebA11y - Adventures in Web Accessibility

W4A2007の発表スライド

Slideshareで公開されている発表スライド

渡辺のAjaxお遊び

Aptanaで作ったDojoライブラリ利用のAjax