ページの本文へ

Hitachi

企業情報研究開発

2011年10月31日更新

RIAとアクセシビリティ

アプリケーションをどこからでも操作したいというニーズが高まっています。ブラウザ上で動かすことが可能な技術を用いればこのニーズを満たすことができますが、従来のHTMLをベースとした技術では、デスクトップアプリケーションと同等の操作が実現できないため、Ajax、Flex®、Silverlight®などの技術(以下、RIA技術)が台頭してきています。しかし、RIA技術によって開発されたリッチインターネットアプリケーション(以下、RIA)は、その多くがスクリーンリーダー(注)によって利用できないという課題が残されています。視覚障がい者にとって本来パソコンは、スクリーンリーダーを用いることによって、他の人の手を借りることなく操作が可能な利便性の高い情報機器であるといえますが、業務用アプリケーションがスクリーンリーダーで利用できない現状に不満を抱きつつも、他の人の手を借りるなどして業務をこなしている実態もあります。
アプリケーションに関わる各団体は、それぞれこの課題に取り組んでいます。例えばW3CのWAIは、WAI-ARIAと呼ばれる仕様を、Ajaxで開発するRIAをアクセシブルにするために策定中で、その一部はすでにWCAG 2.0(ウェブ・コンテンツ・アクセシビリティ・ガイドライン 2.0)を達成するためのTechniques for WCAG 2.0の中で示されています。Flash®による達成方法はすでにそこで示されており、Silverlightによる達成方法は、そのドラフト(2011年6月21日版)の中で示されている状態です。このように、RIA技術を開発する団体はTechniques for WCAG 2.0にWCAG 2.0の達成方法を示すことによって、またスクリーンリーダーやブラウザを開発する団体はTechniques for WCAG 2.0をサポートすることによって、それぞれRIAアクセシビリティの課題に取り組んでいます。そして日立のようなRIAを開発する団体は、Techniques for WCAG 2.0の中で示されている達成方法の中から開発するインタフェースに適しているものを選択し実装することで、スクリーンリーダーでも利用可能なRIAを開発することができます。

スクリーンリーダーとは主に視覚障がい者が用いる、画面の情報を音声で読み上げることが可能なソフトウェアです。

FlexとFlashは、米国Adobe Corporationの米国およびその他の国における登録商標または商標です。

Silverlightは、米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。

日立が考えるRIAアクセシビリティの課題

RIAをスクリーンリーダーで利用可能とするために同じ方向を向く必要がある団体

しかし現時点では、多機能でインタフェースのパーツが多く含まれるようなRIAを考えたときに、現状Techniques for WCAG 2.0(ドラフト含む)で示されている実装方法や勧告候補のWAI-ARIAだけでは、スクリーンリーダーユーザーにとって使いにくいものになってしまうのではないかと、日立は考えています。ここでは、その想定している課題のうち、コンテンツの実装だけでなく、RIA技術そのものや、ブラウザ、スクリーンリーダーの実装側にも関係しそうな課題を紹介します。

なお、想定課題1〜3については、独自の実装をしたRIAのプロトタイプを使って検証を行いました。具体的には、スクリーンリーダーユーザーらにできる限り自力でタスクを実行してもらいました。その後、プロトタイプの仕様に関するインタビューも行いました。それらの結果を考察した結果も踏まえ、確かな課題として捉えています。

これらの課題の解決策を、次のページで提案しています。

また、実装する立場にある団体間で実装方法を議論する場を設けるとともに、解決策を広める活動を行っています。

想定した画面レイアウト


想定したアプリケーションの典型的なレイアウト

画面上部(以下、ヘッダー)にロゴやタイトルが、画面左側(以下、メニューエリア)に機能を切り替えるためのメニューが、画面右側(以下、メインコンテンツエリア)に選択した機能のコンテンツが表示される、典型的なレイアウトの業務用Webアプリケーションを想定しています。なお、スクリーンリーダーで操作可能であるためには、キーボードだけで操作できる必要がありますが、すでに多くのRIA技術で実現可能であるため、ここではキーボードだけで操作可能であることを前提にしています。

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

想定するWebアプリケーションでは、メインコンテンツの中にキーフォーカスが当たるUI要素が多く存在します。このため、仮にメインコンテンツの下部にキーフォーカスを当てたい場合に、Tabキーを何度も押さなければならないという事態が起こり得ます。WCAG 2.0の2.4.1項「Bypass Blocks」では、メインコンテンツに素早く移動できるよう、複数のページ上で繰り返し存在するコンテンツをスキップできるようにすべきと述べられています。

しかし2.4.1項の達成方法を参照しても、想定するWebアプリケーションのメインコンテンツエリアの中を素早く行き来させる方法としては、適したものが見つかりません。特に、アプリケーションにおいては必要となってくる「キーフォーカスの行き来」を想定した達成方法が見つけられないのです。HTML5のSectionsの各要素WAI-ARIAのLandmark Rolesは、エリアのセマンティックスを定義するためのものであり、これらの中から適切なものを選ぶ方法が今後達成方法に挙げられる可能性も考えられます。しかし文書構造を定義するものが多いことと、アプリケーションにおいては様々な意味合いのブロックが想定されることから、これらで定義されたエリアだけで十分なブロックを作り上げるのは難しいと考えています。全ての機能にショートカットキーを設ける方法も考えられます。しかしショートカットキーのみで操作していたといえるCUIに対して、GUIが誕生した理由のひとつには、全てのコマンドをユーザーが覚える必要をなくすことにあったといえます。つまり、ショートカットキーだけで操作をさせるものではGUIの良さをスクリーンリーダーユーザーに提供することができません。

この想定課題の解決策の提案内容は次のリンクを参照してください。


想定レイアウトに基づいて開発したWebアプリケーションのプロトタイプ。想定する課題に配慮せず制作してしまうと、例えば選択したリストに対して何かコマンドを実行しようと思ったときに、その箇所までキーフォーカスを移動させるために何度もTabキーを押さなければなりません。

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

例えばタブパネルツリーのように、WAI-ARIAのrolesで定義可能なUIコンポーネントのタイプであれば、それ自体、一般的に良く使われているものでもあるため、ユーザーはキー操作方法をすでに知っている可能性が高いと考えられます。またスクリーンリーダーは、それがどのタイプのUIコンポーネントであるかが判別できるため、キー操作方法をユーザーに伝えることが可能です。例えばスクリーンリーダーのひとつであるJAWS®は、自動で判別したキー操作方法を読み上げる「Tutor Messages」と呼ばれる機能を搭載しています。
そのため、できる限りWAI-ARIAで定義されているUIコンポーネントのタイプだけでアプリケーションを構築するのが本来ならば望ましいのですが、多機能なRIAはそれが難しいこともあり、全てキーボードだけで操作可能にしようとすると、一般的とはいえないキー操作方法が生じてしまうケースがあります。その場合、キー操作方法が分からないだけでなく、ユーザーやスクリーンリーダーが判別したキー操作方法と、実際のキー操作方法が異なってしまい、ユーザーを混乱させてしまう恐れもあります。

この想定課題の解決策の提案内容は次のリンクを参照してください。

JAWSは、米国 Freedom Scientific, Inc.の米国およびその他の国における登録商標または商標です。

タブが2段に分かれているタブパネルの例
例えばタブパネルのキー操作方法はWAI-ARIAでも定義されていますが、まだ一般的によく知られているとはいえません。また、OSやブラウザのタブパネルとWeb画面中のタブパネルでは、キー操作方法が異なります。

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

例えばメニューを選択したときに、キーフォーカスは選択したメニューに位置させたまま、メインコンテンツに表示される内容を瞬時に切り替えられるというのもRIAの特徴のひとつといえます。しかし瞬時に切り替えてしまうと、変化したことに気付きにくくなってしまうという問題も生じ得ます。画面を見ることができるユーザーに対しては、フェードインさせるなどして、あえて徐々に変化を示すという工夫が考えられます。この工夫が施せるのもまた、RIAの特徴のひとつですが、画面を見ることができないスクリーンリーダーユーザーにとっては、それだけでは意味がありません。従来の静的なHTMLの場合、メインコンテンツに表示される情報が切り替わるとキーフォーカスがページの先頭に移動するので、そのことでスクリーンリーダーユーザーは、どこかの情報が変化したということに気付くことができます。しかしキーフォーカスが移動しないと、そうやって気付くこともできなくなります。

この想定課題の解決策の提案内容は次のリンクを参照してください。

検索ボタンを押すとその結果が実行結果表示エリアに反映される
画面を見ることができない視覚障がい者は、例えば検索条件を指定して検索ボタンを押したときに、その結果が表示されたかどうか不安に思うということがユーザーテストを通して明らかになっています。

想定課題4. スクリーンリーダーの2つの操作モードにユーザーが混乱する

スクリーンリーダーには、キーフォーカスモードと仮想カーソルモードが存在します。キーフォーカスモードと呼んでいるのは、スクリーンリーダーを立ち上げていないときと同じ状態を指しています。この状態では、特別なことをしない限り、テキストにフォーカスを当てることはできません。しかし、それではスクリーンリーダーユーザーがテキストを読み上げるのが大変になるため、仮想カーソルモードが存在します。仮想カーソルモードにすると、例えばキーフォーカスの当たらないテキストであっても1行ずつ読み上げることが可能になります。スクリーンリーダーユーザーは、文章が多いWebサイトでは、仮想カーソルモードで操作する場合が多いようです。しかし、想定する業務アプリケーションでは、仮想カーソルモードでは操作できない箇所が多く存在します。そのため基本的にはキーフォーカスモードで操作し、文書を読む場合のみ仮想カーソルモードに切り替えてもらうことを想定しています。この場合に、ユーザーがキーフォーカスモードと仮想カーソルモードの両方を混乱なく使い分けられるようにするには、どうあるべきかを検討したいと考えています。

※この想定課題の解決策は今後検討したいと考えている内容です

ナビゲーション、データグリッドエリアはアプリケーションモード、プレビューエリアはドキュメントモードに設定
例えば選択したリストの本文を示すプレビューエリアは、大量の文書が表示される可能性もあるため、仮想カーソルモードで操作してもらうことを想定していますが、そこ以外はアプリケーションモードで操作してもらうことを想定しています。