ページの本文へ

Hitachi

企業情報研究開発

ここでは、日立が考えるRIAアクセシビリティの課題に対して、Silverlight®での解決策を提案します。

2011年10月31日更新

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

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

想定課題1に対して日立は、ブロックごとにキーフォーカスを当てていき、必要に応じてブロックの中に入れるようなユーザーインタフェースを提案しています。ひとつのブロックの中には、機能的意味が似た複数のUI要素を配置します。Ajax(HTML5 & WAI-ARIA)では、HTML5のdiv要素にWAI-ARIAのgroupのroleを割り当てることで実現が可能と考えていますが(Ajaxによる解決策はこちら)、Silverlightの場合、現時点ではプログラミング言語によって解決を図っています。

注:このプロトタイプは、UIオートメーションと呼ばれるアクセシビリティAPIが利用できることを前提にしてスクリーンリーダー対応を図っています。そのため、Windows XP以前では、スクリーンリーダーでは十分な情報が読み上げられない場合があります。

キー操作方法

提案としては、ブロック間をCtrl+,(<)およびCtrl+.(>)で移動、要素間はTabとShift+Tabで移動する

上のリンク先のプロトタイプでは、Tabキーを押し続けるとブロックごとにフォーカスが移ります。ブロックにフォーカスが当たった状態で、→(右)のカーソルキーを押すと、ブロックの中に入ることができ、ブロックの中は←→(左右)のカーソルキーで移動できます。しかしユーザーテストを実施した結果、この操作方法に慣れないユーザが、操作を間違えてしまう問題が頻繁に発生しました。そこで日立は、ブロック間のフォーカス移動に特別なキー割り当てをすることを提案します。

具体的には、Ctrlと「,(<)」キーまたは「.(>)」キーを同時に押すと、ブロック間の行き来ができるようにすると良いと考えています。「,(<)」でひとつ前のブロックに戻り、「.(>)」でひとつ後のブロックに進みます。この提案は、各種ブラウザやスクリーンリーダーでショートカットキーとして用いられていないということを踏まえたものです。また、"<"と">"が、前後に進む操作として直感的だという意見が多かったのも理由です。日本アクセシビリティ実装ベンダー会での議論の結果が反映されています。

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

ブロック間の特別なキー割り当ては、コンテンツ開発者側でも実装は可能ですが、もしプラグイン(Silverlight)で実装されれば、コンテンツ開発者はプログラミング言語を用いることなく、簡易なマークアップ言語だけで想定課題1を解決できるようになります。

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

ブロックには、AutomationProperties.Name(Name属性)にどのような機能が集まったブロックであるかを記述します。

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

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

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

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

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

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

注1
HelpText属性は、UIオートメーションと呼ばれるアクセシビリティAPIが利用できる場合のみスクリーンリーダーが情報を取得することが可能です。そのためWindows XP以前では、スクリーンリーダーでは十分な情報が読み上げられない場合があります。
注2
世界中で使われているスクリーンリーダーのひとつであるJAWSは、WAI-ARIAのWidget Rolesで定義されているような規定のUI部品(例えばボタン)にフォーカスが当たったときに、それを操作するための方法(ボタンであればスペースキーで押下)を自動的に読み上げる機能を有します。読み上げないように設定することもできます。

Silverlightで用意されている代替テキストとして用いることのできる属性

次の表に示すのは、キーフォーカスが当たる箇所に関して、スクリーンリーダーユーザーがRIAを操作するために必要であると日立が考える情報と、それらに対してSilverlightで用意されている属性やクラスです。RIA開発者はこれらの情報がスクリーンリーダーユーザーにとって適切に提供されているかどうかを意識する必要があります。しかし、RIA開発者がこれらの属性やクラスをどのように用いて情報を提供すべきか、またスクリーンリーダーはこれらの属性やクラスをどの順番でどのように読み上げるべきかについては、定められていません(2011年10月現在)。例えば、スクリーンリーダーの製品ごとにその読み上げ方が異なると、RIA開発者は製品ごとに対応をしなくてはならず、過度の負担がかかってしまう心配があります。このような事態を回避するためには、最低限のガイドラインが必要です。

スクリーンリーダーユーザーが必要な情報
ID 情報の種類 Silverlightで用意されている
属性とクラス
画面表示の
有無
A ラベル(Name) Content属性有(ラベルとして表示)
AutomationProperties.Name
(以下、Name属性)
無(音声読み上げ用)
AutomationProperties.LabeledBy
(以下、LabeledBy属性)
無(ラベルとの関連付け)
B 型(Role)
例:ボタン、コンボボックス
ControlTypeクラス
(以下、ControlType)
無(音声読み上げ用)
C 状態(State)
例:チェック有/無
Control Patternsクラス
(以下、Control Patterns)
無(音声読み上げ用)
D 補足説明 ToolTipService.ToolTip
(以下、ToolTip属性)
有(ツールチップとして表示)
AutomationProperties.HelpText
(以下、HelpText属性)
無(音声読み上げ用)
E キー操作方法
(独自のキー操作のみ)
特になし
F ショートカットキー
(存在する場合のみ)
AutomationProperties. AcceleratorKey
(以下、AcceleratorKey属性)
無(音声読み上げ用)
AutomationProperties.AccessKey
(以下、AccessKey属性)
無(音声読み上げ用)

ガイドライン案

1. 属性とクラスの読み上げ順序について

スクリーンリーダーは、UI要素にフォーカスが当たったときに、そのUI要素に与えられているXAMLの属性またはUIオートメーションのクラスの値を表「スクリーンリーダーユーザーが必要な情報」のAからFの順に読み上げる。

2. 属性とクラスの読み上げ方法について

スクリーンリーダーは、表「スクリーンリーダーユーザーが必要な情報」のAからFの各情報を次の通りに読み上げる。

A. ラベル(Content属性、Name属性、LabeledBy属性)
スクリーンリーダー Name属性値を読み上げる。ただし、Name属性に値がない場合はContent属性値を代わりに読み上げる。
ラベルとして付されているTextBlockなどのコントロールがLabeledBy属性で関連付けられている場合は、関連付けられているラベルを読み上げ、Name属性とContent属性は値があったとしても読み上げない。
開発者 Content属性に書かれている情報が画面を見ることのできない人にとって十分ではない場合、あるいはContent属性がない場合は、Name属性に十分な情報を記述するか、ラベルとしての十分な記述がされているTextBlockなどのコントロールとLabeledBy属性で関連付ける。
B. ControlType(Role)
スクリーンリーダー ControlTypeの値をもとにRoleを判断し、例えば“ボタン”など、適切な名称に変換して読み上げる。
開発者 ControlTypeの値が当該UI要素のRoleとして適切なものになるようにする。

ControlType(Role)はテキスト値ではなく、ID値で指定します(注1)。UIオートメーションでは、いくつかのRoleはあらかじめ定義されていますが(注2)、定義済のRoleに当てはまらないコントロールを開発した場合のために、カスタム用のID値も用意されています(注3)。ただし、カスタム用のID値を、スクリーンリーダーがどう変換して読み上げるかについてのルールはありません。NVDAの場合は、2010年6月現在、「未定義オブジェクト(Unknown Object)」と読み上げます。
コントロールを開発した場合、まずは定義済のRoleに当てはまるかどうかを確認し、当てはまるものがあればそのRoleをControlTypeで指定します。定義済のRoleに当てはまらないコントロールを開発した場合はカスタム用のID値を指定しますが、それが何であるかをスクリーンリーダーユーザーに伝えることが困難であるため、日立はこのことを1つの課題として捉え、UIオートメーションの開発者であるMicrosoftに解決策を提案しています。

C. Control Patterns(State)
スクリーンリーダー 各UI要素のStateは、Control Patternsをもとに判断し、例えばチェックボックスであれば、“チェック有/無”などと読み上げる。
開発者 Control Patternsの値が当該UI要素のStateとして適切なものになるようにする。
D. 補足説明(ToolTip属性、HelpText属性)
Microsoft 2010年6月現在、XAML言語のToolTip属性は仕様上、読み上げることができないため、読み上げられるようにすることを日立はMicrosoftに提案中です。
スクリーンリーダー ToolTip属性とHelpText属性に書かれている内容が全く同じ場合は、どちらかのみを読み上げる。書かれている内容が異なる場合は、ToolTip属性を最初に、次にHelpText属性を読み上げる。
開発者 ツールチップで画面に表示させる必要はないが、スクリーンリーダーユーザーにとって必要な情報をHelpText属性に記述する。
E. キー操作方法(2010年6月現在、専用属性なし)
Microsoft 2010年6月現在、専用属性がないため、日立はMicrosoftに専用属性を追加することを提案しています。
スクリーンリーダー 専用の属性が追加された場合、その値が記述されていればデフォルトのキー操作説明の代わりに読み上げる。
開発者 独自のキー操作を割り当てた場合には、必ずその操作説明を提供する。2010年6月現在の仕様の範囲内で対応する際は、HelpText属性に記述する。
F. ショートカットキー(AcceleratorKey属性、AccessKey属性)
スクリーンリーダー AcceleratorKey属性やAccessKey属性に値がある場合、それがショートカットキーであることを前提として読み上げる。
開発者 ショートカットキーを割り当てた場合は、そのキーの組み合わせをAcceleratorKeyまたはAccessKeyに記述する。
注:2010年6月現在、NVDAはAccessKey属性のみ読み上げる。

より使いやすくするためにスクリーンリーダーに望むこと

このようなガイドラインを作成すると、スクリーンリーダーベンダーからは他社製品との差別化が図れなくなるという話が聞かれます。しかし、より使いやすくするための工夫はたくさん残されていると考えます。例えば以下のような工夫が考えられます。

  • キー操作方法のための専用属性に値がない場合は、当該RoleとStateにおけるデフォルトのキー操作方法を読み上げるようにする
  • 使い慣れたユーザーにとっては、D(補足情報)、E(キー操作方法)、F(ショートカットキー)のための情報は常には必要でない。そのため、これらの情報のための各属性ごとに、読み上げるかどうかの設定ができるようにする
  • 各属性だけを読み上げるためのキーを用意する
    例:
    ユーザーがキーボード操作方法を最初に知りたいと思ったときのために、あるキーを押すとキーボード操作方法が記述された属性だけが読まれるようにする

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

想定課題3に対しては、Ajaxの場合であればWAI-ARIAのLive Regionを用いることが求められます。日立は、Silverlightにおいてもこのような仕様が必要だと考えています。現状のSilverlightの仕様の中でも、キーフォーカスを画面に表示されていないコントロールに移すことによって、解決することはできます。想定課題3の例では、検索の実行ボタンが押され、検索が実行されたタイミングで、画面に表示されていないコントロールにキーフォーカスを移し、すぐにまた検索の実行ボタンに戻します(このとき画面上では、キーフォーカスは検索の実行ボタンに当たったままに見えます)。こうすると、検索が実行されたタイミングで、スクリーンリーダーはキーフォーカスが一瞬移ったコントロールのName属性に記述された内容を読み上げることになります。しかし日立は、この方法を一般化させることは難しいと考えています。