- 著者: Gez Lemon
- 件名: Introduction to WAI ARIA
- 日付: 2008年8月1日
- URL: http://dev.opera.com/articles/view/introduction-to-wai-aria/
- 訳者: Arata Kojima
- 著作: This article is licensed under a Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.
WAI-ARIA導入
ARIAにはじめて触れる人たちのためにこの記事は書かれている。障害を持つ人たちがWebを使うにあたってぶつかる潜在的な難しさとHTMLの理解を必要とする。ユーザを観察すると、いくつかのRIAと親和性が高いことが分かるだろう。
この記事を読んだあと、ARIAが何の役に立つか、Webサイトにどのように組み入れるか、そして非常にシンプルなWebサイトをもっとアクセシブルにするための方法を学べるだろう。
この記事はスペイン語、フランス語、ドイツ語で読める。翻訳記事はOperaとは無関係であることをメモしておく。
2008年10月8日更新：仕様の変更を反映させ、文書のランドマークロールのリストを更新した。
2009年4月1日更新：仕様の変更に応じ、aria-channelの章とaria-live="rude"の値を除外した。どちらも仕様から取り除かれている。
導入
HyperText Markup Language (HTML)は、そもそもWebアプリケーションを作るためにデザインされたわけではない。HTMLはインターフェースをコントロールするための十分な機能を持っていないし、シーケンスクライアントサーバコミュニケーションモデルを基盤としている。自分たちのコンポーネントやウィジェットを作り、ウィジェットに振る舞いを与えるためにJavaScriptを追加することで、Webアプリケーションの開発者たちはHTMLの制約を乗り越えている。
不幸にもその制約に打ち勝とうとするテクニックはアクセシブルではない。通常のデスクトップアプリケーションウィジェットのようにカスタムウィジェットは見えるし振る舞いもする。しかし、ツリービューを例にすると、役割（ウィジェットが行うこと）、状態（checkedのようなユニークな状態）やほかの重要ないくつかのプロパティはスクリーンリーダーのような支援技術では使えない。見出し要素のようにデザインされたものが実際には見出しではないというのと同じようなものだ。プレーンなテキストは見出しのようには見えるが、支援技術は見出しと見なさない。
支援技術を使う人たちは更新に気づかないことが多い。リンクやフォームの送信のように、ナビゲーションイベントに応じてWebコンテンツが変化するよう、支援技術は一般的には期待する。バックグラウンドでコンテンツを静かに更新するため、WebアプリケーションはAJAXのような技術を使い、それをときどき支援技術は見逃してしまう。たとえ支援技術がその変化に気付いたとしても、ユーザはその変化に気付かないかもしれないし、どこが更新されたのかが分からないかもしれない。
WAI-ARIAとは、支援技術によってカスタムウィジェットが認識され、使えるようになるために、ロール（role）やステート（state）、プロパティ（proparty）の意味を提供する仕様である。アプリケーションが更新されたことを支援技術のユーザに気付いてもらうようにするためのメカニズムもWAI-ARIAは提供する。
HTMLの簡単な歴史
リンクされた文書を構造化し共有するためのハイパーテキストシステムとして、元々HTMLはデザインされた。テキストベースの文書に構造を付加するために、初期のHTMLの草案は見出しや段落、リスト、リンクなどのタグを定義した。IETFによるHTMLの最初の提案はインラインで画像を表示するためのimg要素も含んでいた。初めての公式なHTMLの仕様はHTML 2であり、初期のHTMLの草案を基盤としていた。この仕様では、formを導入し、編集可能なボックスやボタン、チェックボックス、ラジオボタン、ドロップダウンリストなど、インターフェースのためのコンポーネントをいくつか定義した。HTML 2で定義されたいくつかのインターフェースのコンポーネントは、私たちが現在使っているHTML 4.01と比較してもほとんど変わっていない。
HTMLのコミュニケーションモデルはクライアントサーバモデルに立脚している。クライアントサーバモデルにおいて、クライアントがリクエストを送信し、レスポンスを受け取る。サーバはリクエストを受け、サーバ上で処理し、クライアントにレスポンスを返す。HTMLは振る舞いのレイヤーを持っていないので、コミュニケーションはシーケンスを意図している。つまり、クライアントはサーバからページを要求する：サーバはリクエストを処理し、ページをクライアントに送信するという一連の流れである。
Webアプリケーション
Webアプリケーションがデスクトップアプリケーションの単なる1つに過ぎないということ、つまりブラウザのことだが、その事実を除いて、Webアプリケーションは普通のデスクトップアプリケーションを真似ようとしている。HTMLとそのコミュニケーションモデルをデスクトップアプリケーションと比べると本質的な違いが2つある。
- デスクトップアプリケーションは振る舞いのレイヤーを持っているため、サーバにリクエストすることとは関係ない。
- デスクトップアプリケーションはインターフェースのコンポーネントをはるかに豊富に持っている。
デスクトップアプリケーションを見習う
バックグラウンドサーバリクエスト
デスクトップアプリケーションに近づくためには、振る舞いのレイヤーを持つために、WebアプリケーションはJavaScriptを使う。たとえば、ユーザがメニューを伸縮させるときにJavaScriptが使われるかもしれない。
ときおりデータをサーバが要求するかもしれない。たとえば、現在のページを更新するためにサーバのデータベースからレコードを取ってこないといけないかもしれない。そのときにWebアプリケーションはサーバと通信しなければならないので、バックグラウンドで静かにサーバとやり取りするために、Ajaxやiframe要素の隠し通信のようなテクニックを使うのだ。
見た目や雰囲気とアクセシビリティの問題が衝突する
見た目にもリッチなコンポーネントを真似し、バックグラウンドでリクエストをサーバに送ることはよりリッチな体験をユーザができる。不幸にも、これはアクセシビリティにおける問題を生み出す。スクリーンリーダーのユーザのような、特に支援技術のユーザにはよろしくない。
WAI-ARIAが解決へ
幸運にも、上記で述べたすべての問題は、WAI-ARIA（Web Accessibility Initiative’s Accessible Rich Internet Applications）の仕様で解決される（以下、ARIAと短縮する）。ARIAは実用的であり、技術に特別な力を与える。つまり開発者ができないと言うよりも、ARIAが開発者にリッチなWebアプリケーションを作らせてくれるのだ。その上、ARIAは実行がとても容易である。
キーボードナビゲーション
テキストを持たないオブジェクトに対して代替テキストを与えるのと同じように、キーボードのみでインターフェースの要素にアクセスできることはもっとも基本的なアクセシビリティの条件の1つである。アクセシビリティを理解している開発者は、input要素のtype属性にimageの値（input type="image" ...）を与えるようにフォーカスを受け取ることができるカスタムウィジェットを作るかもしれない。不幸にも、ほとんどのウィジェットはキーボードでアクセスできるように作られていない。しかし、img要素のような要素、またはdiv要素のようなコンテナを必要とする複合的な要素で成り立つウィジェットはキーボードでフォーカスできない。
a、area、button、input、object、selectとtextarea要素にHTML 4はtabindex属性を導入した。HTML 4からのtabindex属性は0から32767までの正の値を持つことができる。最も低い数字を持つ要素からナビゲーションがスタートし、最も大きな数字を持つ要素まで進む。0の値を持つ要素はマークアップの順番で進んでいく。マークアップが論理的な構造を持っていれば、キーボードのタブの順番にインターフェースの要素が配置されるため、tabindex属性は必要とされない。
ARIAはtabindex属性を拡張するので、すべての目に見える要素で使うことができる。ある要素をキーボードのタブの順番に出現させたくなければ、その要素にARIAでマイナスの値を指定すればよいが、プログラム的にフォーカスされうる（スクリプトで要素にフォーカスすることはできる）。負の数字の実数は重要ではないので（その要素はキーボードのフォーカスを受け取らない）、タブの順番に含みたくはないが、プログラム的にフォーカスされうる必要がある要素に対して、-1の値は典型的に用いられるだろう。例えば、あなたがメニューウィジェットを作ったとしよう。メニュー自体はタブの順番に含まれており、タブを押すことによってメニューにはアクセスできる。しかし、そのメニューのアイテムはキーボードのタブの順番には含まれていない。代わりに、メニューのアイテムはプログラムされ、カーソルキーを使うことでナビゲートできる。ユーザがすべてのメニューをタブで1つずつアクセスする必要をなくし、このページでよりよりナビゲーションができる。例えばツリーのような一連のコンポーネントキーボードのアクセスを必要とするすべてのウィジェットで正しいことである。
普通のタブの並び順を追加する
次の例は0の値のtabindex属性を用いている。div要素にタブの順番を与えられるので、その要素にキーボードユーザはアクセスすることができる。
<div tabindex="0"> ... </div>
負の値のtabidenx
次の例では負の値を持つtabindex属性を使うので、プログラムでその要素にフォーカスできる。
<div id="progaccess" tabindex="-1"> ... </div>
この例ではdiv要素はタブの順番に含まれない。しかし、-1の値を持つtabindex属性はプログラムでフォーカスできる。次のJavaSciptのコードサンプルでは上の例で定義された要素を選択し、その要素にフォーカスするためにフォーカスメソッドを用いる。
var objDiv = document.getElementById('progaccess'); // Focus on the element objDiv.focus();
私はなんだ？
ARIAは、スライダーのようなウィジェットやナビゲーションセクションのような紹介するページの構造を定義する手助けをrole属性で行える。Webアプリケーションにおける主要な問題の1つは、どの要素でもウィジェットをなり得るということだ。あらかじめ定義づけられた役割をHTML要素は持っている。役割を担うのはその役割を与えられた要素である。その一部は構造で役割を果たす。例えば、支援技術にとって見出しの役割はよく知られている。ウィジェットが現存する要素で作られるとき、その要素の役割は視覚的に見えるようにすることよりも、支援技術に知らせるということである。例えば、スライダコントロールの指のつまみが適切な代替テキストとともに画像で作られているとすると、そのときスクリーンリーダーはおそらく「画像、指」とそのコントロールを読み上げるだろう。しかし、対照的にもっと意味のあるものは「スライダ、値16%」ということであるはずだ。
図3：典型的なスライダコントロールのつまみ
role属性を指定されたものの役割は元々の要素の役割を伝えることなのだ。次の例では、input要素がsliderという値のrole属性を持っている（この記事であとからほかのARIAのプロパティも見てみよう）。inputであるということよりも、sliderであるということを支援技術に教えることが役割である。
<input type="image" src="thumb.gif" alt="Effectiveness" role="slider" aria-valuemin="0" aria-valuemax="100" aria-valuenow="42" aria-valuetext="42 percent" aria-labelledby="leffective">
この要素がフォーカスを受けるとき、このウィジェットが果たす役割をスクリーンリーダーは理解する。ARIAの仕様ではroleのリストを議論している。
ドキュメントランドマークロール
定義付けされたウィジェットを手伝うroleと同様に、文書の構造の定義付けを手伝うroleもある。ドキュメントランドマーク（Document landmarks）は通常のroleのサブセットであり、roleの場所や意味を正しく理解するスクリーンリーダユーザを助けるものである。
図4：ヘッダー、サイドバー、メインコンテンツエリアがある典型的なページ
ARIAは次のdocument landmark rolesを定義している。
article- ブログの投稿記事、ブログのコメント、フォーラムの投稿など、それだけで意味をなすものである。
banner- ページのタイトルやロゴのようなページの中心をなすもの。
complementary- メインコンテンツのためのコンテンツ、しかしメインコンテンツとは切り離しても意味をなすもの。たとえば、ポータルサイトの天気など。
contentinfo- フットノートや著作権、プライバシーポリシーへのリンク、プリファレンスのリンクなどのコンテンツである。
main- 文書の中心のコンテンツに直接関係している、もしくは展開しているものである。
navigation- 文書をナビゲートしたり、関係したりするリンクを含んでいる。
search- サイト内を検索するための検索フォームを含む。
次の例では、図4で示したページ構造を作るためにbanner、navigation、mainにlandmark rolesが指定されている。
<div role="banner"> ... </div> <div role="navigation"> ... </div> <div role="main"> ... </div>
ARIAステート（states）とプロパティ（propaties）
ARIAステートとプロパティは、ユーザとウィジェットがどのようにやり取りするのかについて支援技術に情報を与えることができる。ステートは、オブジェクトが持つ単一の情報を認識するためのものである。例えば、aria-checkプロパティは、true、false、mixedという3つのステートの値を持っている。先ほどのスライダの例では、あとから紹介するようないろいろなプロパティを与えることによって、支援技術がウィジェットを描写できるようにする。
aria-valuemin- ある一定の幅で最低の値を持つ
aria-valuemax- ある一定の幅で最大の値を持つ
aria-valuenow- ある一定の幅での現在値
aria-valuestext- ユーザがコンテキストを理解できるように読むことができるテキストを持つ。例えば、"30ドル"
aria-labelledby- ウィジェットと適切なやり取りをするためにウィジェットが持つid属性をテキストで有する
いくつかのプロパティはスクリプトを通じて改訂されることもある。例えば、スライダのウィジェットのプロパティであるaria-valuenowとaria-valuetextは指が動いたときに改訂されることもある。
// Set the ARIA property values when the thumb is // moved on the slider objThumb.setAttribute('aria-valuenow', iValue); objThumb.setAttribute('aria-valuetext', iValue + ' %');
Ariaのロールやプロパティを追加すると、HTML 4.01やXHTML 1.0でバリデートしない。しかしそれでもよいのだ。ARIAは重要な情報を昔作られた仕様書に入れるのだから。XHTML 1.1のようにモジュールのXMLと共に使えるDTDを策定している最中である。アクセシブルなウィジェットを作るためにARIAの仕様で定められたステートとプロパティの一覧も参考にしてほしい。
Live Regions
ユーザがある対象にフォーカスせずとも何かしらの変化があったときに、そのことを伝えるのがlive regionの役割である。live regionは、ユーザがどのページにいるのかを惑わせずに更新できるということだ。例えば、チャットのアプリケーションを考えてみよう。会話を入力するためのテキストフィールドから移動することなく、相手からのレスポンスを伝えられるのだ。
aria-live
更新されたコンテンツを発見するというのは、スクリーンリーダーユーザにとって最も大きな障害の1つである。ARIAはaria-liveプロパティによって、その領域がどのように振る舞うかを指定することができる。aria-liveプロパティで使われる値は次のものだ。
off- これがデフォルトの値であり、その領域はユーザに何も提示しない。
ul aria-live="off" polite- これはlive regionにとって一般的なオペレーションであり、動作を要求する。ユーザが現在のアクティビティを完了してから動作する。
ul aria-live="polite" assertive- この値は通常より高い優先順位にあるが、ユーザの行動を必ずしも邪魔するわけではない。
ul aria-live="assertive"
live regionにはほかにも重要なプロパティがあるので、それらも紹介しよう。
aria-atomicプロパティ
aria-atomicプロパティはlive regionの任意のプロパティであり、trueかfalse（このプロパティが指定されていないときは、falseがデフォルト）の値を持っている。領域が更新されたときに、すべて、もしくは一部が変化したことをユーザに支援技術が伝えるようにするのが役割である。このプロパティがtrueにセットされていれば、総じて全体の領域を支援技術は提示する。一方で、変化した一部の領域が変化したことを自ら告げることもある。
次の例では、aria-atomicプロパティを含む一連のものをほかの要素が上書きしなければ、順不同リストとそれに内在する全ての要素がその変化を告げることになる。
<ul aria-atomic="true" aria-live="polite">
aria-busyプロパティ
aira-busyプロパティはlive regionの任意のプロパティであり、trueかfalse（このプロパティが指定されていないときは、falseがデフォルト）の値を持っている。ユーザに変化を伝える前にlive regionの複数の部分をロードする必要があるとすると、aria-busyプロパティは最後の部分をロードするまではtrueをセットしておき、更新が終わったその時にfalseをセットする。このプロパティのおかげで支援技術は更新が完了してから変化したことを知ることができるようになる。
<ul aria-atomic="true" aria-busy="true" aria-live="polite">
aria-relevantプロパティ
aria-relevantプロパティはlive regionの任意のプロパティであり、ある領域内で関係する変化があったことを示す。aria-relevantプロパティはスペース区切りのリストとして次のプロパティの値を有する：
additions- 領域内のDOMにノードが加えられる。
removals- 領域内のDOMからノードが取り除かれる。
text- ノードが加えられるか、取り除かれるか。
all- すべて（additions removals text）がこの領域に適用される。
aria-relevanプロパティが指定されていないときは、文字の変化とadditions（aria-relevant="text additions"）がデフォルトになる。領域内のノードにDOMが加われば、次の例では変化は告げられる。もしテキストの変化があったり、領域内からノードが取り除かれても、ユーザには通知されないだろう。
<ul aria-relevant="additions" aria-atomic="true" aria-live="polite">
ARIAはいつから使えるか？
ARIAを使うことにデメリットは何もない。だから、いますぐに使い始めることができる。4つのメジャーブラウザはRIAをサポートし始めているし、サポートを表明しているところもある。Opera 9.5とFirefox 1.5+はすでにARIAのサポートしている。Internet Explorer 8 BetaはARIAをサポートし、Webkit（Safariが支援するオープンソースのアプリケーションフレームワーク）はARIAをサポートすることを表明している。支援技術でもARIAは広くサポートされるようになっている。JAWS 7.1+、Windows-Eyes 5.5+、NVDA、Zoomtext 9+、そのほかいろいろな支援技術がARIAの基本的なサポートをしており、その状況も改善されていくことになるだろう。
アーリーアダプターになれ
ARIAを使うことにデメリットは何もなく、サポートも準備万端なのだから、アーリーアダプターになることによって失うものはなにもない。そして多くのものを得る。たとえ本当にシンプルなWebサイトであったとしても、ユーザのナビゲートをよりよくするためにドキュメントランドマークを追加することでもよく、それはコンテンツをよりよいものにするのだ。
ドキュメントランドマークを使ってみよう。
私のパーソナルサイトには、main、navigation、search、secondaryにドキュメントランドマークを入れている。次の文書構造を考えてみよう。
<div id="ads"> ... </div> <div id="nav"> <form id="searchform" ...> ... </form> ... </div> <div id="content"> ... </div>
ドキュメントランドマークでマークアップの中にrole属性を直接書き込むことができる。
<div id="ads" role="banner"> ... </div> <div id="nav" role="navigation"> <form id="searchform" role="search" ...> ... </form> ... </div> <div id="content" role="main"> ... </div>
また、ほとんどのページは構造化され、CSSで装飾されているので、JavaScriptのfunctionで渡すことができるid属性でページは構造化されているだろう。次はJavaScriptのfuntcionの簡単な例だ。functionは要素のid属性を受け取り、つまりrole属性を受け取り、role属性に対応する要素をセットする。
function addARIARole(strID, strRole) { // Find the element to add a role property to var objElement = document.getElementById(strID); if (objElement) { // Add the role property to the element objElement.setAttribute('role', strRole); } }
セクションのid、つまりセクションのためのドキュメントランドマークと共にfunctionはコールされる。だから、上の文章構造を考えると、マークアップの中に入れるよりもrole属性を挿入するためにJavaScriptのfunctionを使ってもよいかもしれない。
function setupARIA() { // Add ARIA roles to the document addARIARole('content', 'main'); addARIARole('nav', 'navigation'); addARIARole('searchform', 'search'); addARIARole('ads', 'banner'); } window.onload = setupARIA;
必須項目を指定する
必須項目を含むフォームを作る場合、aria-requiredプロパティを利用できる。フォームが送信される前に、ユーザが入力しなければならない項目をaria-reqiredプロパティは指示する。次の例は、aria-requiredプロパティを通常のinput要素に追加したものだ。
<label for="contactname">Name</label> <input type="text" id="contactname" name="contactname" size="30" aria-required="true">
ほかのプロパティも追加する
aria-labelledbyやaria-describebyなど、ARIAにはシンプルなサイトでも利用できるたくさんのプロパティがある。aria-labelledbyプロパティは1つもしくはそれ以上の要素をlabel要素と見なすように指定でき、aria-describedbyプロパティは1つもしくはそれ以上の要素をdescriptionと見なすようにも指定できる。
<h2 id="limg">Paragliding</h2> <p id="dimg"> A long description of our paragliding trip ... </p> <div> <img src="takeoff.png" alt="Getting ready to take off" aria-labelledby="limg" aria-describedby="dimg"> </div>
一歩進んだマークアップ
ARIAのマークアップはHTMLやXHTMLよりも優先される。aria-labelledbyがlabel for=""と並んで使われたとすると、aria-labelledbyが優先されるということである。ARIAを解釈できない古いブラウザをlabel要素はサポートし続ける。コンフリクトを避けるための簡単な方法はaria-labelledby属性を使うことだ。label要素に参照をつけるために。ARIAのサポート関係なく、label要素を使えるのだ。
<label id="lblef" for="effectiveness">Effectiveness</label> <input type="image" role="slider" id="effectiveness" aria-labelledby="lblef" ...>
ステートやプロパティのリストにも目を通してみよう。あなたのコンテンツをどのようにARIAがアクセシブルにするかについての解説がある。
HTMLとWAI-ARIAの共存
本来Webアプリケーションケーションを作るためにHTMLはデザインされたものではなかった。しかし、開発者は独自のカスタムウィジェットを作り、JavaScriptで振る舞いを与えるためにそうやってきた。この問題は、ウィジェットやページが更新されたことをロールやステート、プロパティでは支援技術に正確に届けられないことだ。開発者が細部までウィジェットを作ったり、文書構造を定義したり、ページが更新された範囲を定義づけることによって、ARIAの仕様はこれらの問題を解決する。
複雑なウィジェットや動的なセクションを持つ複雑なWebアプリケーションケーションを作るときでも、本当にシンプルなWebサイトを作るときであっても、障害があるユーザが便利に使えるようにあなたは今ARIAを使い始められるのだ。
