WAI-ARIA入門書

1 はじめに

SecuritySpaceが発行する技術普及報告書（Technology Penetration Report）によると、今日のウェブサイトの55％以上はJavaScriptを含んでいて、障がいのある人のウェブコンテンツへのアクセス能力に大きな影響を及ぼしている。新しいリッチ・インターネット・アプリケーションは、カスタムウィジェットをレンダリングして、リッチなデスクトップコンポーネントを模倣することによって、ページ全体をリロードしなくてもUIを更新できるという、GUIによく似た環境を実現している。レガシーGUIのアクセシビリティフレームワークは、包括的なアクセシビリティ・アプリケーション・プログラミング・インタフェース（API）とインフラストラクチャを介してこれらの問題に対応することで、支援技術との相互運用性を達成している。これらのAPIは、スクリーンリーダーなどの支援技術とアプリケーションとの間に規約を構成することで、必要とされる適切なセマンティクスを持ったリッチで動的なコンテンツに対し、支援技術がアクセスして使用可能な代替物を生成できるようにする。しかし現状では、リッチ・インターネット・アプリケーションと支援技術の間にこのような規約が存在しないために、障がいのある人にアクセシビリティギャップをもたらしている。

残念ながら、HTMLとその他のマークアップ言語は、アクセシブルな動的コンテンツに適切なサポートを提供していない。これまでのところ、W3CのWAIでは、JavaScriptを使用しないよう呼びかけ、それをウェブ・コンテンツ・アクセシビリティ・ガイドライン（WCAG）1.0（[WCAG1] 、チェックポイント6.1）にも盛り込んできた。W3Cでは、数々のイニシアティブを立ち上げて、宣言的マークアップのアプローチを使ってこの問題に対応しようとしている。この入門書では、現行のHTMLとXHTMLのマークアップに適切なメタデータを組み込んで現在のアクセシビリティAPIをサポートすることによって、現在の支援技術が抱える相互運用性の問題に対応する手段を説明していく。さらに、ARIAの概念的な理解をウェブ開発者にもたらすことによって、WAI-ARIA仕様 [ARIA] への準備とすることを意図している。WAI-ARIAは、（X）HTMLの開発者がマークアップ内で使える幅広い技術を作ることによって、デスクトップの高度なアクセシビリティ機能をウェブにもたらすものだ。これらの技術がもたらすメタデータは、GUIウィジェットや文書構造を記述し、支援技術のベンダーがアクセシブルでユーザブルなソリューションを提供するのを助ける。W3CのWAI内に作られたPFWGでは、ユーザーエージェントのメーカーや支援技術のベンダー、さらにはアクセシビリティツールのプロバイダなどと協力して、エンド・トゥ・エンドの実用ソリューションを確立する作業に取り組んでいる。

WAI-ARIAの導入としては、アクセシブル・リッチ・インターネット・アプリケーション・スイート（WAI-ARIA）概要を参照できる。このWAI-ARIA入門書は、WAI-ARIA仕様をサポートする一連のリソースの1つであり、ARIAの背後にある概念と理由について基本的な説明を加えることを目的としている。一方、WAI-ARIAベストプラクティス [ARIA-PRACTICES] では、ウェブコンテンツ開発者のための推奨使用パターンを説明する。WAI-ARIAスイートは、ARIAのためのロードマップ（WAI-ARIAロードマップ） [ARIA-ROADMAP] で指摘されたギャップを埋めるものである。これらの文書は、明確な定義や説明がないと思われるトピック分野において、それを明確にするという重要な役割を担っている。

2 問題

伝統的なHTMLは、複数の側面において、動的なコンテンツのアクセシブルなサポートを難しくしている。例えば、以下の点が挙げられる。

1. アクセシビリティが、コンテンツと表現的な情報の両方から得られる抽象的なセマンティクスに依存している。現行のHTMLコンテンツからセマンティクスのキューを抽出する過程では、そのキューがタグ要素の名前に限定されているため、抽出結果の信頼性が一般に低い。
2. セマンティクス情報を伝える手段を提供しないままコンテンツを表現的にフォーマット化することを、HTMLが認めてしまっている。よくある例としては、スタイルシートではなくテーブルを使ってコンテンツをフォーマット化している例がある。
3. HTMLでは、スクリプトとCSSを併用することによって、動的なカスタムコンポーネントを作ることができてしまい、GUIコンテンツをサポートするために作られたネイティブのアクセシビリティアーキテクチャに対して、セマンティクス情報を伝える手段が提供されないことがある。
4. 文書構造について意味のあるメタデータを追加する機能が、HTMLにはない。
5. HTML要素を本来の目的以外の用途に使ってカスタムコンポーネントを作ることによって、キーボードではアクセスできないコンポーネントができてしまう。

JavaScriptで生成されるコンテンツを開発する開発者は、テーブルや順序の決まったリストのように実際のユーザーインタフェースを定義する標準的なタグ要素だけに縛られることを好まない。DIVタグのような要素を幅広く使って、スタイルシートや動的なコンテンツ変化も利用しながら、UIを動的に実現させている。しかし、HTMLのDIVタグは、セマンティクス情報を提供するものではない。例えば、ポップアップメニューや順序の決まったリストなどの開始を定義するために、DIVが使われるかもしれない。が、HTMLには、以下の点を達成するメカニズムが存在しない。

• このDIVのロール（role）をポップアップメニューであると特定する。
• これらの要素にフォーカスが置かれることを、支援技術に対して警告する。
• ポップアップメニューが折り畳まれているのか展開されているのかといった、アクセシビリティのプロパティ情報を伝える。
• この要素に対してどんなアクションが取れるのかを、イベントハンドラのタイプ（onmouseoverやonclickなど）を介する以外の、機器に依存しない手段で定義する。

つまり、JavaScriptには、ネイティブプラットフォーム上のアクセシビリティフレームワークに対してユーザーエージェントがソリューションをマッピングするためのアクセシビリティアーキテクチャが必要ということだ。

図1.0：JavaScriptを伴わないDOMノードのアクセシビリティ相互運用性

図1.0は、モデル・ビュー・コントローラ（MVC）のアーキテクチャにおける典型的なDOMノードを示している。このノードでは、データ、つまり「モデル」にセマンティクス情報が含まれていて、これはユーザーインタフェースの表現、つまり「ビュー」とは分離されている。ここでは、文書要素がユーザーエージェントによって管理されていて、それは要素のデフォルト動作に基づいている。文書要素におけるユーザーエージェントのデフォルト動作は、コントローラを形成する。DOMノードと支援技術の間に置かれているのが、ユーザーエージェントから支援技術に提供される規約を含んだボックスだ。このデータには、アクセシブルなGUIプラットフォームの多くに対応するアクセシビリティAPIに見られる典型的なアクセシビリティ情報（ロール（role）、ステート（state）、キャレット、選択、テキスト、ハイパーテキスト、名前記述、親/子情報、関係）が含まれている。HTMLと他のW3Cのマークアップでは、要素のタグ名とそのタグにマッピングされるアクセシビリティ属性だけに基づいて、アクセシビリティ情報が提供される。例えば、テーブルのアクセシブルなロール（role）はtableだ。そして、開発者は、title属性を割り当てることによって、アクセシブルな記述を提供する。

図2.0：JavaScriptを伴ったDOMノードのアクセシビリティ相互運用性

図2.0は、図1.0と同じDOMノードだが、新しいコントローラとして機能するJavaScriptを伴っている。JavaScriptは、このDOMノードにおいて、ユーザーエージェントのデフォルト動作を上書きする。ユーザーによるインタラクションの結果として起きるイベントに応答して、JavaScriptがデータ、コンテンツ、スタイルを操作し、カスタムウィジェットを作り出す。この状況では、デフォルトのアクセシビリティ情報は有効ではなくなり、規約も無効となる。図2.0では、規約内のロール（role）、ステート（state）、アクション、値、イベント変更、関係にアスタリスクが付いているが、これは、アクセシビリティにエラーが起きる可能性があること、ベースマークアップにギャップが生じる可能性があることを示している。これらのギャップは、規約をサポートするのに必要な新しいセマンティクスデータを開発者が提供しなかった結果として起きている。

3 要件

アクセシブルなリッチ・インターネット・アプリケーションの作成を支援するソリューションはすべて、以下の要件を満たさなければならない。

セマンティックウェブ技術を使って、カスタムUIコンポーネントの発見を可能にすること。

ウェブオントロジーによって、オブジェクトに関するセマンティクス情報と、オブジェクトがオントロジー内で他のオブジェクトとどのようにかかわるかに関する情報が、保存できるようになる。

現在のアクセシビリティアーキテクチャをサポートすること。

現在のアクセシビリティアーキテクチャは、オブジェクト技術を中心に成り立っている。アプリケーションまたは文書内の各オブジェクトが、そのアクセシブルなプロパティを支援技術に対して開示する。

コンテンツと表現の分離を可能にすること。

動的なコンテンツの開発者は、その文書がどのようにレンダリングされるかに依存しない方法で、アクセシブルなメタデータを文書内に保存できなければならない。

支援技術によるアプリケーションの受動的なモニタリングを許可すること。

アクセシビリティ情報の変化に対応するアプリケーションを、支援技術のベンダーが要求されるべきではない。

W3Cが進めている問題解決のための新たな活動を利用すること。

この問題は、すぐにも解決されなければならない。最小限の変更で必要なレベルに到達することを目指して、数々の活動が行われている。

軽量であること。

ソリューションは、ウェブ開発者による採用を促すため、軽量でなければならない。

スケーラブルであること。

ソリューションは、スケーラブルでなければならない。複雑なことを可能にする一方で、シンプルなことを簡単にしなければならない。

国際化が可能であること。

他のウェブソリューションと同様、私たちのソリューションも国際化が可能でなければならない。

ユーザーエージェントのサポートを最初に保証すること。

ユーザーエージェントのメーカーが最初から介入して、仕様が完成した暁には、ソリューションのサポートを確実にしなければならない。

支援技術のベンダーを最初から介入させること。

相互運用性を確立するため、支援技術のベンダーが最初から参加しなければならない。開発過程では、支援技術ベンダーからのサポートを生かして、仕様が完成した暁には、トータルなソリューションが作られるようにする。

その過程で開発者ガイドラインを作成すること。

これは、新しいアクセシビリティモデルの作成に携わる人が犯す重大な間違いだ。開発者が早い段階から介入して、フィードバックを出せるようにし、実用に適したソリューションを早くから作り始められるようにしなければならない。

4 ソリューション

問題点の説明から明らかに分かるのは、適切なアクセシビリティ情報をマークアップで提供し、それによってターゲットとするプラットフォーム上のアクセシビリティAPIをサポートする手段が、開発者にはないという点だ。この問題は、HTMLだけに限ったことではなく、スケーラブル・ベクター・グラフィックス [SVG] などの他のマークアップにも及んでいる。この入門書では、デスクトップブラウザに出力されるウェブコンテンツの問題に対応して、HTMLとXHTMLの両方に使える共通の拡張機能を紹介する。それが、アクセシブル・リッチ・インターネット・アプリケーション（WAI-ARIA）バージョン1.0 [ARIA] だ。目標は、これをHTML 5の標準機能とすることにある。

5 デスクトップブラウザに出力されるコンテンツのギャップへの対応

W3C WAIのPFWGによる現在の取り組みは、W3C ARIAをHTML 5への移行パスとともに提供し、ホスト言語を拡張することによって、HTML 4.01とXHTML 1.xに拡張機能をもたらすことに、主な焦点を置いている。この成果は、アクセシブル・リッチ・インターネット・アプリケーション [WAI-ARIA] 仕様に盛り込まれるだろう。WAI-ARIAが提供する拡張機能によって、アクセシビリティAPIのインフラストラクチャと動的な（X）HTMLコンテンツをサポートするために埋めなければならないギャップのほとんどは埋められるだろう。WAI-ARIAの策定に使われた（X）HTMLの総合的なギャップ分析、およびWAI-ARIAがこれらのギャップをどのように埋めるかは、表1.0に示したとおりだ。将来的には、ARIAを多くのホスト言語に統合して、アクセシビリティを向上させたいと考えている。支援技術との高い相互運用性を通じて動的なウェブコンテンツをアクセシブルにするのに必要とされる重要な拡張機能は、以下のように要約できる。

ステート（state）およびプロパティ属性 ― これは、完全なキーボードフォーカスを提供するために必要な（X）HTMLの属性変更だ。ステート（state）とプロパティがプラットフォームのアクセシビリティAPIに直接的または間接的にマッピングされることによって、ARIAに対する支援技術の完全な相互運用性が実現する。

ロール（role）属性 ― ロール（role）属性は、XHTML Role属性モジュール [XHTML-ROLES] から借用された概念で、これにより開発者は、要素の目的に関するセマンティクス情報を機械的に抽出できるかたちで、ホスト言語に注釈として付けられるようになる。アクセシビリティ、機器適応、サーバーサイド処理、複雑なデータ記述などを目的としている。図2：JavaScriptを伴ったDOMノードのアクセシビリティ相互運用性に見られるように、ARIAでは、支援技術に対してロール（role）情報をもたらす目的でロール（role）属性を使っている。

文書ランドマークのロール（role）値 ― これらの値も、やはりXHTML Role属性モジュール [XHTML-ROLES] から借用されていて、ロール（role）属性の標準値を提供する。これにより、文書の適切な部分（ランドマーク）がアクセシビリティ目的で定義される。ユーザーエージェントは、例えばデスクトップのユーザーエージェントであればキーマッピングなどによって、文書内のこれらのセクションをナビゲートできるかもしれない。

ARIAのロール（role）値のタクソノミー ― このタクソノミー（系統的な階層分類）には、WindowsおよびLinuxのアクセシビリティAPIに見られる中心的な必須のロール（role）と、文書構造を表現するロール（role）が含まれる。文書構造を使用することは、支援技術が複雑な文書をナビゲートし、ウェブページ内のアクティブなエリア、例えばスクリプトで動的に生成されたウェブアプリケーションなどに入った場合にそれを理解するために必要だ。このタクソノミーは、ロール（role）がサポートしているプロパティをユーザーエージェントやオーサリングツールが判断するのを助け、これらのプロパティのアクセシビリティAPIへのマッピングを支援する。タクソノミーは、クラスの階層構造に似ていて、セマンティクスと構造を伝えるのに使われ、また各ロール（role）に関する情報を説明する。現時点では、このタクソノミーは、RDF/OWLをモデルとして作られている。

つまり、WAI-ARIAは、スクリプトで生成される動的なウェブコンテンツ、特に（X）HTMLマークアップにJavaScriptを使ったウェブコンテンツのアクセシビリティを修正するのに使われるだろう。幅広い用途を意図しており、SVGなどの他のマークアップにも適用できるはずだ。また、（X）HTMLのアクセシビリティにとっての重要性という点ではやや低いものの、やはり有益なものとして、XMLイベントへの記述拡張と新しいAccess要素が挙げられる（リンクを入手するには、この文書が公開ワーキングドラフトに組み込まれなければならない）。ウェブ・コンテンツ・アクセシビリティ・ガイドライン2.0では、ARIAのプロパティを要求しており、これに関連した記述が、ガイドライン4.1「現行および未来の支援技術を含むエージェントとの互換性を最大化する」（ロール（role）、ステート（state）、プロパティ、値）、およびガイドライン1.3「情報や構造を失うことなく、様々な形式（音声読み上げやシンプルなレイアウトなど）で表現できるコンテンツを作成する」（関係）に見られる。

次のセクションでは、どのようにしてこれらの仕様を一緒に使うのか、またHTML 4に実装するのかを説明する。

<?xml version="1.1" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 
    http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"
>
    <body>
        <div role="menu">
            File
        </div>
    </body>
</html>

<?xml version="1.1" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 
    http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">



>
        <body>
            <div role="menu" aria-haspopup="true">
                File
        </div>         
    </body>
</html>

<?xml version="1.1" encoding="us-ascii"?>
   <!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 
    http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">



>
    <body>
        <div role="menu" aria-haspopup="true" tabindex=-1>
            File
        </div>
    </body>
</html>

<html lang="en">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
  </head>
    <body>
        <div role="menu" aria-haspopup="true" tabindex=-1>
            File
        </div>
    </body>
</html>
                        

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">    
<html xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>    
  <title>application/xhtml+xml: Navigation Roles Example 1</title>        
  <link rel="stylesheet" href="css/nav1_xhtml.css"  type="text/css" ></link>    
  <script type="text/javascript" src="../js/globals.js"></script>    
  <script type="text/javascript" src="../js/widgets_xhtml.js"></script>  <link rel="icon" href="http://www.cites.uiuc.edu/favicon.ico" type="image/x-icon" />    
  <link rel="shortcut icon" href="http://www.cites.uiuc.edu/favicon.ico" type="image/x-icon" />    
</head>    
<body onload="widgets.init()">
.
.
.    
<div id="leftnav">         
<h2 class="nav" id="leftnav_label">Career Center Services</h2>         
 <ul title="Career Center Services" role="navigation" aria-labelledby="leftnav_label">        
   <li><a href="http://www.uiuc.edu/">Career Home</a></li>  
   <li><a href="http://www.uiuc.edu/">Career Counseling</a></li>        
   <li><a href="http://www.uiuc.edu/">Pre-Health Advising</a></li>        
   <li><a href="http://www.uiuc.edu/">Services</a></li>        
   <li><a href="http://www.uiuc.edu/">Workshops</a></li>        
   <li><a href="http://www.uiuc.edu/">Resource Center</a></li>        
   <li><a href="http://www.uiuc.edu/">Question Board/FAQ</a></li>  
 </ul>

...

</body>

6 WAI-ARIAとWCAG 2.0を採用する事業上の理由

リッチ・インターネット・アプリケーションの開発者が、1999年のWCAG 1.0標準に基づくアクセシビリティ順守条項をサポートしようとして、アプリケーションをディグレードさせ、ARIAの使用を避けることが多々ある。まずこれは、HTML 4またはXHTML 1.xを使って、ウェブページをキーボードでアクセスできるようにすることを意味する。WCAG 1.0では、キーボードでアクセスできるようにしなければならないと言っているが、使えるようにしなければならないと言っているわけではない。これをHTMLで行うには、アクティブな要素がリンクになるか、form要素がキーボードでアクセスできるようにならなければならない。また、これは、ホスト言語が提供する以上のセマンティクスが必要というわけではないことも意味する。さらに、ブラウザのCSSをオフにした状態でも使うことができなければならない。このことは、以下のようなユーザビリティ問題を引き起こす。

• キーボードでアクセスできるコントロールがすべて、formまたはanchorでなければならなず、ユーザーがナビゲートするには、Tabキーを押してウェブページ上のフォーカス可能な要素すべてを移動しなければならない。ページ上の最初のリンクから最後のリンクへ移動するのが、非常に長い道のりになり、ユーザビリティを悪化させる可能性がある。
• ARIAのセマンティクスを使わなければ、ユーザーに対して文脈の情報が提供できない。
• HTML要素を本来の目的以外で使っていると、新しいウィジェットに対して適切なロール（role）と文脈の情報が提供できない。文脈が分からないというのは、深刻なユーザビリティ問題だ。ARIAのセマンティクスを使うことによって、ユーザーに対して文脈の情報が提供できるようになる。
• CSSが絶対的なポジショニングのための使われていて、これを取り除けば、ポップアップメニューのようなウィジェットのユーザビリティ機能が失われてしまう。結果として、ファイルメニューを有効化したところ、そのメニューがページの一番下に表示されるというようなことが起きてしまうだろう。

図7.0：ツリーウィジェットのユーザビリティについて、WAI-ARIAのセマンティクスを実装したWCAG 2.0ガイドラインとWAI-ARIAを使わないWCAG 1.0を比較したモデル

図7.0は、ツリーウィジェット内のツリー項目のための「アクセシブル」なウィジェットを示している。WCAG 1.0をARIAなしで使っていて、スクリーンリーダーに送られた段階では、「link folder PJ111」と読み上げられる可能性がある。このフォルダが閉じられている（expandedが「false」になっている）ことを示す情報は提供されていない。また、階層の深さ（aria-levelが「2」）、セット内のポジション、このレベルでのセットの大きさを示す情報もない。これらはすべて、目の見えるユーザーには当然と思われがちな文脈をもたらすものだ。これがツリー項目であることは、ロール（role）を使って示されていて、これにより、この項目がツリー項目のように動作し、キーボードでナビゲートできるべきであることが分かる。一方、ARIAのバージョンを使っているスクリーンリーダーは、「Closed Folder PJ111, Closed Folder one of four, Depth 2, unchecked」と読み上げる可能性がある。さらに、ARIAのバージョンでは、ツリー項目が矢印キーでナビゲートでき、ウェブページ全体を統制するTabキー送りのスキームの一部としてナビゲートすることは要求しない。これはそもそも、ツリーウィジェットに対してユーザーが期待することではないだろう。さらに、ウェブページ上のすべてのウィジェットがリンクだと言われたら、いったいどれほどのユーザビリティだろうか。

ここで問わなければならないのは、次の質問だ。「なぜアクセシビリティに投資が必要なのか、なぜ非生産的なユーザーを作り出す必要があるのか」。デスクトップのユーザー全員が、ARIAから恩恵を受けるだろう。

7 結論

この入門書は、スクリプトで生成される動的なウェブコンテンツを今日のブラウザでレンダリングする際のアクセシビリティに対応するとともに、W3Cが策定するXHTML 2のような宣言的な標準の未来に対して効果的な架け橋を築くために作られている。XHTML 1.xのために作られた拡張機能は、幅広い対象を視野に入れている。この入門書では、WCAG、ATAG、UAAGが共通戦略の中核を成すべきだと、明らかに述べている。すべての作業部会が、互いに依存していて、影響を受け合っている。さらに、HTML、CSS、機器非依存などメインストリームの作業部会と密接に協力することで、実用的なソリューションというのみならず、XHTMLだけに留まらない幅広い影響力のある実用的なソリューションができるだろう。

8 補足資料