ページの本文へ

Hitachi

企業情報研究開発

ここでは、日立が考えるRIAアクセシビリティの課題に対して、Ajax (HTML5 & WAI-ARIA)での解決策を提案します。W3CのWAIは、WAI-ARIA(注)と呼ばれる仕様を、HTMLベースで開発するRIAをアクセシブルにするために策定中です。想定課題3は、WAI-ARIAによって解決できることが明らかといえます。

2011年10月31日更新

最新の更改内容は次のURLでご確認ください。
http://www.w3.org/TR/wai-aria/

想定課題1. 操作したいところへ移動するのに時間がかかる

想定課題1に対して日立は、ブロックごとにキーフォーカスを当てていき、必要に応じてブロックの中に入れるようなユーザインタフェースを提案しています。ひとつのブロックの中には、機能的意味が似た複数のUI要素を配置します。Ajax (HTML5 & WAI-ARIA)では、div要素にWAI-ARIAのgroupのroleを割り当てることで実現が可能です。div要素の代わりにHTML5のSectionsの中のsection要素を使う方法も考えられます。その場合、WAI-ARIAのgroupのroleは割り当てる必要がないものと思われます。ただ、section要素はアプリケーションにも適用可能と仕様(2011年5月25日版)には書かれていますが、実装する側では文書のためのものだという解釈が広がっていることから、日立はWAI-ARIAのgroupのroleを用いる方法を提案します。以下にコード例を示します。

<body role="application">
<div role="group" aria-label="block name" aria-describedby="Bypass_Blocks" tabindex="1">
<!-- Some UI elements are put here-->
</div>
<ul id="Tutor_Messages">
<li id="Bypass_Blocks">Press Ctrl+comma keys to shift to the previous block and Ctrl+period keys to shift to the next block.</li>
</ul>
</body>

ブロック間キー操作の実装はブラウザ側で行われることを望んでいます

ブロック間の特別なキー割り当ては、コンテンツ開発者側でも実装は可能ですが、もしブラウザで実装されれば、コンテンツ開発者はJavaScriptを用いることなく、簡易なマークアップ言語だけで想定課題1を解決できるようになります。そのため日立は、WAI-ARIAのUser Agent Implementation Guideに掲載されるよう提案活動を行う予定です。

代替テキストの実装について

groupのroleを割り当てたdiv要素には、aria-labelにどのような機能が集まったブロックであるかを記述します。すでに現時点で、WAI-ARIAにおけるapplicationのroleを宣言した中であれば、この方法で実装したブロックのブロック名称を読み上げ、かつブロック化したものであることも読み上げてくれるブラウザとスクリーンリーダーの組み合わせが存在することを確認しています。

想定課題2. キー操作方法が分からない

想定課題2に対して日立は、キー操作方法を記述するための特別な代替属性が必要という主張をしていますが、現状の仕様の範囲で対応するには、WAI-ARIAのaria-describedby属性にキー操作方法を記述することを提案します。キーフォーカスが当たったUI要素について、ラベル、UI要素のタイプ、状態、そしてaria-describedbyの順で読み上げることが一部のブラウザとスクリーンリーダーの組み合わせで確認できています。この順でキー操作方法が読み上げられることで、ユーザーは自力で操作できるようになるということがSilverlight®によるプロトタイプを使ったユーザーテストを通して確認できています。一方で、キー操作方法を聞くまで待てず、次のUI要素にキーフォーカスを移動してしまい、その結果しばらく操作方法に迷ってしまうケースも見られました。ユーザーからは、以下のようなご意見をいただいています。

  • 知りたいときに、キー操作方法だけが読み上げられる操作があると嬉しい。
  • 最初はとても良いけど、慣れたらキー操作方法は読み上げられなくなるようにしたい。

これらのご意見には、それぞれ以下のような機能によってある程度応えられると思われます。

  • aria-describedbyを読み上げるかどうかがユーザー自身で設定できる。
  • 何か特定のキーを押すと、キーフォーカスが当たっている箇所のaria-describedbyだけが読み上げられる。

ただ、aria-describedbyは本来、ラベルを補足する目的で用いられることを想定した代替属性です。また、キー操作方法を読み上げるかどうかの設定は、スクリーンリーダーのひとつであるJAWS®であれば「Tutor Messages(注)」と一緒に設定できるようになるのが望ましいといえます。そのためには、キー操作方法を記述するためだけの属性が用意されている必要があるのです。もしもそのような属性が用意されれば、ブラウザはキーフォーカスが当たった状態のときだけ、それに記述されている内容を画面に表示させる機能を実装して欲しいと考えています。画面を見ながらキーボードだけで操作するユーザーに対しても、キー操作方法が伝えられるからです。

世界中で使われているスクリーンリーダーのひとつであるJAWSは、WAI-ARIAのWidget Rolesで定義されているような規定のUI部品(例えばボタン)にフォーカスが当たったときに、それを操作するための方法(ボタンであればスペースキーで押下)を自動的に読み上げる機能を有します。読み上げないように設定することもできます。

想定課題3. キーフォーカスは移動しないが表示情報が変化した場合に、そのことが伝わらない

想定課題3に対しては、Ajaxの場合であればWAI-ARIAのLive Regionを用いることが求められます。すでにFirefox®とJAWS®やNVDA(NonVisual Desktop Access)の組み合わせではLive Regionがサポートされています。検索条件を指定して検索ボタンを押したときの実装例としては、検索結果が示されているテキストにLive Regionを指定してあげることになります。なお、Live Regionを指定するテキストは、それが画面を見ることができるユーザーにとって不要といえるものであれば、必ずしも画面に表示する必要はありません。
Live Regionにはいくつか属性が用意されています。これらの属性の値によって、スクリーンリーダーが読み上げるタイミングが変わりますので、どのプロパティをどの値に指定するのが適切か、スクリーンリーダーの実装の仕方を見ながら良く考えて選ぶ必要があるのが現状です。

コード例:

<span aria-live="polite" aria-atomic="true" aria-relevant="text">XXX</span>

  • ※XXXは検索結果を示すテキスト。JavaScriptによって制御することとなる。
「変更」ボタンを押すと、画面上で何件目から何件目が表示されているかを示している、Live Region指定部が読み上げられます