WAI-ARIA 1.1のブラウザー対応状況（2014年11月）
この記事は、Web Accessibility Advent Calendar 2014、2日目の記事です。
2014年3月にWAI-ARIA 1.0（日本語訳）が勧告に達しましたが、W3Cでは次期WAI-ARIA 1.1（Editor's Draft）の標準化が進んでいます。WAI-ARIAは、Webで必要とされているセマンティクスと実際に使えるセマンティクスのギャップを埋める仕様であるため、必要とされるものが変われば、それを取り込んでいく（セマンティクスをより自然に表現できるようにする）必要があるのだと思います。
また、WAI-ARIAはその性質上Polyfillを作るのが難しく、どうしてもブラウザーや支援技術の実装に左右されがちです。実際のブラウザーを見ると、すでに対応は始まっていますので、この記事では2014年11月時点でのブラウザーにおけるWAI-ARIA 1.1の対応状況を見ていきます。
role="none"
WAI-ARIA 1.0には様々なロールがありますが、中でもわかりにくいのがpresentationロールだと思います。このロールは、要素のセマンティクスを削除します。ものすごく乱暴に言ってしまうと、どんな要素であってdiv要素やspan要素のように支援技術に見せます。なお、presentationロールの説明はUsing WAI-ARIA in HTML（日本語訳）がわかりやすいです。
しかし、「presentation」という名前は「この要素は装飾なので支援技術には見せないで」を意味しているかのように見えてしまいます（その場合はaria-hiddenを使います）。そこで、WAI-ARIA 1.1ではpresentationロールの別名としてnoneロールを設けることが検討されています。
<table role="none presentation">
<!-- これはレイアウトテーブルです -->
</table>
WAI-ARIAのrole属性は、複数の値を半角空白で区切って指定できます。複数指定された場合、ブラウザーは、自身が認識できる最初の値を使います。そのためrole="none presentation"という指定は、noneロールに対応している環境ではnoneロール、対応していない環境ではpresentationロールと認識されます。ただし、WebKitは複数指定に長らく対応していませんでした（Bug 133163 – AX: WebKit does not recognize ARIA 1.1 tables）。
WebKitとChromiumはnoneロールの対応を行っています。
role="text"
また、presentationロールは指定された要素だけではなく、子孫の要素にも影響を与える場合があります。これは、表–行–セルや、リスト–リスト項目のようにセマンティクスに強い親子関係がある要素ではpresentationロールの指定が継承される、というものです。例えばtable要素にrole="presentation"を指定すると、table要素に属するtr要素やtd要素、th要素などのセマンティクスも削除されます。これについては、やはりUsing WAI-ARIA in HTML（日本語訳）にわかりやすい例があるので、そちらを参照していただくことにして、ここでは本題のtextロールについてみていきたいと思います。
textロールは、presentationロールを超強力にしてしまったロールのようなもので、自分と子孫要素のセマンティクスをすべて削除し、支援技術にテキストとして見せます。子孫要素に表–行–セルのようなセマンティクスの関係があるかどうかに関わらず、子孫のセマンティクスを削除します。
<!-- https://rawgit.com/w3c/aria/master/aria/aria.html#text に出てくる例を日本語にしてみましたたが、HTMLとして破綻しているのでは… -->
<div role="text">
<p>私は</p>
<p>カメが</p>
<p>好き</p>
</div>
このような強すぎるロールを使う局面が実際にあるのか疑問も感じるのですが、WebKit（とChromium）はかなり以前からサポートしています。
aria-modal
dialog要素を使えば、ダイアログがモーダルとして開くどうかを明示的に指定できますが、dialog要素を使わない場合、モーダルかどうかを指定する方法はありませんでした。WAI-ARIAのdialogロールを使ってダイアログを作る場合、モーダルかどうかはJavaScriptで挙動をどう実装するかでしかありません。ダイアログがモーダルの場合、フォーカスや仮想カーソルがダイアログの中にとどまるのが一般的ですが、これを厳密な意味でJavaScriptで実装することは困難でした。そのため、例えば、CSUN 2014でのThe Paciello Groupの発表、Lessons Learned: Accessibility Theory vs. Implementation Realityにはダイアログの先頭と末尾に「ダイアログの先頭」「ダイアログの末尾」というテキストを入れる例がでてくるほどです。
この問題の本質はモーダルかどうかをあらわすセマンティクスが存在していないことですので、WAI-ARIA 1.1ではモーダルかどうかを表現するプロパティ、aria-modalを追加することが検討されています。これを使えばダイアログがモーダルであればaria-modal="true"、そうでなければ指定なし（もしくはaria-modal="false"）とマークアップできます。
<!-- dialog要素を使わずにモーダルダイアログを実装する場合 -->
<div role="dialog" aria-modal="true">
<!-- モーダルダイアログの中身 -->
</div>
aria-orientation
メニューなどのウィジットでは、水平方向に操作するか、垂直方向に操作するかが重要な場合があります。例えば、メニューバーでは左右の矢印キーで隣りの項目に移動し、上下の矢印キーで子供のメニューを開閉します。子供のメニューは、上下の矢印キーで隣りの項目に移動し、左右の矢印キーで子供のメニューを開閉します。
aria-orientationは要素が水平方向に置かれているか、垂直方向に置かれているかをあらわすプロパティです。WAI-ARIA 1.0のaria-orientationの初期値はhorizontal（水平方向）でしたが、WAI-ARIA 1.1のaria-orientationではundefined（未定義）に変更することが検討されています。
| 値 | WAI-ARIA 1.0 | WAI-ARIA 1.1（2014年11月時点） |
|---|---|---|
| 取りうる値 |
|
|
| 初期値 | horizontal | undefined |
ただし、ロールによってはaria-orientationの初期値が別途定義されています（memubarロールはhorizontal（水平方向）、menuロールはvertical（垂直方向））ので、実際に利用する場合には、やはり仕様を確認する必要があります。
さて、ChromiumとGeckoはこの変更に対応しています。
まとめ
WAI-ARIA 1.1はまだ標準化の途上におり、ここで取り上げたもの以外の変更もありますし、ここで取り上げたものが変更されたり、削除される可能性もあります。また、Editor's Draftにも「WAI-ARIA 1.1ではtableロールを導入する予定」とありますが、まだtableロールのセクションはないなど、仕様としても初期段階にあります。しかし、冒頭にも述べましたが、WAI-ARIAはPolyfillを作ることが困難ですので、標準化と実装が歩調をそろえて進んでいってくれたらなと思っています。
なお、標準化を行っているW3CのProtocols and Format Working Groupは、次のWorking Draftを来年3月初旬のCSUN 2015期間中に公開したいと考えてるようです。
