視覚障碍者向けソフトUI雑考

(0)はじめに

ここでは「視覚障碍者向けソフトUI雑考」と題して、私が視覚障碍者向けソフトの開発に携わってから考えてきた"ユーザーインターフェースはどうあるべきか"というところを思いつくまま書いていこうと思います。同じように障碍者に配慮したソフトウェアを作成しようというかたの参考になればと思いますし、あるいはパソコン利用をサポートする立場のかたが、障碍者のパソコン利用上どのような困難があるのかについて知るためのヒントになればと思います。あくまで個人的な見解ですし、間違いもあるかもしれません。また既存の方式や特定の製品をおとしめようという意図は全くありませんので、その旨、ご承知置きください。また、ここに書く文章で、OS環境に依存した具体的な記述をする場合には、実際の視覚障碍者のかたがたの利用状況に合うように、Windowsを対象とすることにします。

(1)メニューバーについて

最初のテーマとしては、標準的なWindowsソフトには大抵付いている「メニューバー」と呼ばれるユーザインターフェースを、取り上げようと思います。メニューバーはタイトルバーのすぐ下に並んでいるメニューのことです。ほとんどのソフトでは、おそらくメニューの一番左は「ファイル」メニューになっていることでしょう。ソフトにおいて重要な機能の多くは、このメニューバーのどこかに配置され、メニューを辿っていって、どれか一つを選択することで、その機能を利用することができるのです。

全盲の視覚障害者の場合は、マウスを使わずにキー操作だけで全てのソフトを使わなくてはなりません。キー操作でこのメニューバーにフォーカスを持っていくにはどうすればいいのでしょうか。キー操作ではAltキーを押すことで、メニューバーの一番左の項目、つまり多くのソフトでは「ファイル」メニューとなっている場所にフォーカスが移ります。メニューバーに配置されるメニューは階層化された構造となっています。１番上位の階層は横一列に並んでいます。例えば「メモ帳」を例に取れば、ファイル、編集、書式、ヘルプの４つの項目がトップ階層を形成しています。横一列に並んでいる訳ですから、この４つの項目を順番に移動していくには、左右の矢印キーを使えばできるだろうということは直感的に分かるでしょう。つまり最初にAltキーで「ファイル」項目に移動し、次に右矢印キーを押すと「編集」、もう一度押すと「書式」という具合に移動するのです。そして面白いことに、一番右の項目までいったときにもう一度右矢印キーを押すと、システムメニューという特殊なメニューに移動します。システムメニューというのは、ウインドウの移動やサイズ変更をキーボードで行うためのメニューで、どのアプリケーションにも存在するものです。そしてもう一度右矢印キーを押すと、今度は一番左の「ファイル」項目に戻るのです。一番右と一番左は、システムメニューを挟んでループして繋がっている訳です。ここまでの挙動は特に違和感なく受け入れられる部分だと思います。

しかしメニューバーというのはトップ階層だけで終わっていることはまずありません。多くの場合はトップ階層の下にプルダウン式のメニューが並んでいます。プルダウン式ですから今度は縦一列に並んでいるのです。縦に並んでいる訳ですから、項目を選ぶには上下の矢印キーを使わなくてはいけません。ここが重要なところです。トップ階層では左右の矢印キーで項目を選び、２番目の階層では上下の矢印キーを使うのです。これは視覚的な補助があれば理解することは難しくないでしょうが、全盲の人にはなぜそのように一貫性のない操作方法になっているのかが分かりにくいことでしょう。では１階層目と同様に、一番下まで項目を移動したときに、下矢印キーを押すとどうなるでしょうか。これは予想できることですが、一番上の項目に移動します。しかし問題なのは、いつ一番上の項目に移動したのかに気付くことが難しいのです。下矢印キーを押していって、「何か聞いたことがあるような項目がいくつか出てきたぞ」と思って初めてループしたことに気付くのです。また、そのメニューに何個の項目があるかを知ることも難しいでしょう。しかしメニューのループに関する問題はユーザインターフェースの問題ではなく、スクリーンリーダの読み上げ方の問題ですので、読み上げ方を改良することで解決するでしょう。

ではさらに３階層目があった場合はどのように操作すればいいでしょうか。もっと話は複雑になります。３階層目があるかどうかは、視覚的には２階層目の項目の右側に三角マークがあるかどうかで決まります。三角マークがあれば３階層目があるのです。そしてその３階層目に移動する方法ですが、今度はまず１回だけ右矢印キーで右に移動して、新しいプルダウンメニューを出してから、下矢印キーで縦一列に並んでいる項目を選択するのです。つまり右に飛び出してから上下です。３階層目以降の階層は全てこの右に飛び出してから上下で選択するという方法となります。全盲の人にとって、この操作方法を頭で理解することは非常に困難であろうということが、容易に想像できるはずです。今、何階層目にいるのかを意識しながら、階層にあわせて変化するルールに従わなくてはいけないからです。

複雑なことはまだまだあります。「メモ帳」を例にとって説明します。編集メニューの「検索」という項目に今いるとします。つまり１階層目は２番目、２階層目は６番目の項目です。今は２階層目ですから項目は縦一列に並んでいて、項目の選択には上下の矢印キーを使わなくてはいけません。しかしこの時、左矢印キーを押したらどうなるでしょうか。なんと「ファイル」メニューの「新規」に移動するのです。つまり１階層目は１番目、２階層目も１番目に移動するのです。目が見えている人でも、こういう挙動をすることを予測できる人はあまりいないのではないでしょうか。ましてや全盲の視覚障碍者の場合ならなおさらです。

つまり結論として何が言いたいのかと申しますと、メニューバーというのは全盲の人にとって、非常に理解しがたいものだということです。文字までは読めなくてもぼんやりとメニューが見えている人は、まだ理解できるでしょう。しかし全盲の人は音声と想像力だけで理解しなければなりませんから、このルールを理解するのはとてつもなく困難なことでしょう。視覚障碍者向けのソフトウェアを作るに当たっては、このメニューバーが持っている問題を意識して、メニューバーに代わるユニバーサルなユーザインターフェースを用意するか、またはメニューバーを組み込むにしても、なるべく階層が深くなりすぎないように心がける必要があると思います。

(2)ショートカットキー入力について

第２回のテーマとしては、「ショートカットキー入力」を取り上げたいと思います。「ショートカット」というのは、メニューバー上に配置された機能を、Altキーや矢印キーでメニューを辿ることなく一発で実行する、つまりショートカットして使うためのユーザインターフェースです。これは熟練したユーザが効率的にソフトを利用できるように用意されている操作法です。しかしこの「ショートカット」による操作は、(熟練したユーザであるか否かに関わらず)視覚障碍者にとっても重要な意味を持ちます。視覚障碍者の多くはキーボードからの操作でアプリケーションを利用するからです。

キーボード入力による操作には、主としてメニューバーから選択する方法とショートカットを入力する方法の２種類が存在します。これらはどのように使い分けられるのでしょうか？メニューバーは、そのソフトにどのような機能があるのか分からない状態のユーザに、機能の存在を伝えられるというメリットがあります。メニューバーを辿ることで、何ができるソフトなのかを、おおよそ把握することができるのです。しかしメニューバーには前回お話ししたような全盲者にとっての問題がありますし、目的の機能を選択するまでに多くの入力と音声による確認が必要となるというデメリットがあります。従ってメニューバーだけでは、満足してソフトを利用することができないのです。そのデメリットを補うにはショートカットによる操作が不可欠です。

ショートカットによる操作は通常、修飾キーとその他のキーの組み合わせを１つのコマンドとして入力します。修飾キーとは、Ctrl(コントロール)キー、Shift(シフト)キー、Alt(オルト)キーの３つのキーのことです。一般的には２つ、または３つのキーを同時に押すことになります。例えば「メモ帳」で文字列のコピーをする場合は、文字列を選択した状態でCtrlキーを押しながらCキーを押します。このショートカットは「Ctrl+C」と表記します。これはCtrlキーを押しながらCキーを押すという意味です。修飾キーは必ず先に押さなくてはいけません。また、文字列をペーストする場合は「Ctrl+V」です。つまりCtrlキーを押しながら、Vキーを押すのです。ショートカットはメニューを辿ることなく一発で実行できるというメリットがありますが、デメリットもあります。それは「覚えにくい」ということと、「押しにくい」ということです。

まず「覚えにくさ」についてですが、メールソフトやブラウザなど、ある程度以上の規模のアプリケーションには数十個から数百個の機能があります。それらの多くにショートカットが割り当てられています。コピーやペーストなどのソフト間で共通のショートカットもあるにはあるのですが、多くのショートカットはそうではありません。アプリケーション毎に独自に定義された数多くのショートカットを覚えて、記憶し続けることは大変難しいことです。覚えにくいという問題は、視覚障碍者特有の問題でもあります。厚生労働省による平成１３年の障害者実態調査によれば、国内の視覚障碍者の７３％は６０歳以上の高齢者であることが分かります。高齢者が全て「もの覚えが悪い」というつもりはありませんが、数多くのショートカットを記憶することがあまり得意ではないだろうということが推測されます。

次に「押しにくさ」についてですが、キーボードを見ないで２つ以上のキーを同時に押すということは想像以上に難しいことです。私は文章を打つときには全くキーボードを見ずに打つことができます。いわゆるタッチタイピングです。しかしショートカットを入力するときには、ついキーボードを見てしまいます。２つ以上のキーをキーボードを全く見ないで入力することが不安だからです。テキストの編集などの取り消しややり直しが利く操作の場合は、失敗してもどうということはありませんが、ショートカットに割り当てられた機能の全てがやり直し可能なわけではありません。そうでない場合の方が多いです。ですからつい慎重になってキーボードを見てしまうのです。しかし視覚的に入力操作を確認することができない視覚障碍者の場合は、不安を感じながら２つ以上のキーを押すことになるのです。

「覚えにくさ」と「押しにくさ」、ショートカットにまつわるこの２つの問題はどのように解決できるでしょうか？まず一つの方法としては、複数のキーの組み合わせとせずに１つのキーをショートカットに割り当てる方法があります。これはDOS系やUNIX系のソフトウェアではよく使われている方法ですが、テキストの入力欄があるウインドウの場合はファンクションキーや一部の特殊なキーしか割り当てられませんので、使える状況がかなり限られてきます。しかしこれが使える状況なら、視覚障碍者にとっての「覚えにくさ」と「押しにくさ」の問題をある程度軽減することができます。

他にも効果的な方法はないでしょうか。とてもすばらしい解決方法がありました。アメディア社製の多くのソフトに採用されている「コマンド２度押し実行」の操作です。これは１回目の入力ではそのショートカット入力に割り当てられた機能名とその説明が音声で伝えられます。そして２回目の入力で実行されます。２段階の操作にすることによって、正しいショートカットを入力できたかどうかを音声で確認しながら実行することができるのです。これによって記憶が怪しいショートカットも自信を持って入力することができます。またいろいろなキーを押してみて、どのキーを押したらどんな機能が割り当てられているかを確認することができますので、記憶をリフレッシュするのにもとても便利です。このようにとても良い操作方法ですので、当方の開発したメールソフト、ボイスポッパーには早速組み込んでいます。この操作方法が、視覚障碍者向けソフトのスタンダードとなることを願います。

(3)UIにおけるニーズ(アクセシブルであるために)

前二回はいきなり具体的なユーザインターフェースの例を取り上げてしまいましたが、やっぱり最初はもっと範囲を広げて、全体的な話をしておかなければいけないと思いました。目の不自由なかたがソフトのユーザインターフェース(以下UIと記述)に対して、どのようなニーズを感じているだろうか、という話です。

現状のソフトウェアのUIに満足できるかといえば、もちろんそんなことはないはずです。なぜなら現状ではアクセシブルでないソフトが非常に多いからです。では何が理由でアクセシブルでないのか、ということですが、これには主に以下のような理由があると考えられます。

①スクリーンリーダの読み上げ能力に起因する問題。
スクリーンリーダの画面情報の読み上げ能力が低かったり、特定の開発環境(VBやDelphi等)で使用されるソフトウェアの一部の構成パーツが、一部のスクリーンリーダでは読み上げられないことがあります。読み上げられないパーツについては操作ができないため、そのパーツがソフトを使う上で重要な意味を持つものであれば、そのソフトを使うことはできなくなります。

②キーボード操作だけで使えるように作られていないソフトの存在。
一般の晴眼ユーザの多くはマウスを使って操作をするため、キーボードだけで全て操作できるように配慮されて作られていないソフトが多々あります。

③タブオーダーが適切に設定されていないソフトの問題。
タブオーダーというのは、ソフトウェアのフォーム上に配置された各種パーツ(エディットボックス、ボタン、ラベルなど）のフォーカスをタブキーによって切り替えるときの順番のことです。タブオーダーがアクセシビリティになぜ関係するのかというと、エディットボックスとラベルが対になっているケース、例えば名前の入力欄の場合、つまり「名前」というラベルとその入力欄であるエディットボックスが対になっているケースを考えます。スクリーンリーダの性質として、「名前」のラベルの次のタブオーダーが入力欄のエディットボックスになっていなければ、それが名前の入力欄であることを適切に読み上げることができません。しかしソフトの作者の大半はそのようなスクリーンリーダの動作原理を知りませんから、割といい加減なタブオーダーになってしまっていることが多いです。そうなると入力欄があることは分かっても、何を入力したらいいのかが分からないという状態になります。つまりこれはアクセシブルではありません。

以上の３つ以外にもまだあるかもしれませんが、とにかくこのような問題のために多くのソフトはアクセシブルではないのです。ですから目の不自由なかたとしては、まずアクセシブルであることをソフトに望む、ということになります。

では現状、ソフトウェアのアクセシビリティを達成するためには、MSVC++を使ってMFCのプログラムを作り、上記の②と③にも配慮するという方法しかないのか？ということですが、必ずしもそうではありません。いろいろな方法がありますが、大きく分けて２つのUIに関する流派が存在すると思われます。一つはWindows標準のGUI、もう一つは独自UIです。Windows標準UIの場合は、上記①②③の事情を考慮して、なおかつWindowsの標準的なスタイルであるUIの作法を守って作ります。そして読み上げに関しては多くの場合スクリーンリーダによる読み上げが利用できます。一方、独自UIの場合は何でもありです。Windowsが登場する前のDOSプログラムの世界では何でもありだったようにです。読み上げに関しては独自UIの自由度の高さを利用して、あえてスクリーンリーダに依存しないように作るケースも多いです。

そうすると、この２つの流派のどちらが正しいのか、ということになりますが、あまり今までそのような議論は、メーリングリストやウェブなど、公にはなされて来なかったようです。しかしユーザサイドでは、非常に強固に一方の流派を支持するケースも一部にはあるように感じています。Windows標準UIの支持層の意見としては、次のようなものがあるように思われます。「なぜWindows標準というある程度一貫性のあるUIがあるにもかかわらず、独自UIのソフトを作ったりするのか？独自UIのソフトがでてきたせいで、視覚障碍者のPC利用のための教育やサポートは混沌としてしまった。独自UIのソフトさえなければ、視覚障碍者のPC利用は今より進んでいたはずだ。第一、独自UIのソフトはユニバーサルと言えるのか？晴眼者が使うのと同じソフトを使えるようになって初めて、視覚障碍者は自立できたと言えるのではないか？」といったような主張です。一方、独自UIの支持層の意見はどうでしょうか。次のようなものがあるように思われます。「視覚障碍者向けPC環境は、DOS時代で既にある程度完成の域に達していた。操作性は非常に良かったし、視覚障碍者でも生産性の高い仕事ができた。しかしWindowsの時代になってからは生産性が落ちた。Windowsはそもそもマウス操作で生産性が上がるように考えられたOSだからだ。それにWindowsのGUIには、視覚障碍者への配慮に欠ける様々な新しい視覚的操作の概念が数多く組み込まれている。なぜハンデを背負った人間の側が、ハンデのない人間に適した環境に合わせるために、不都合な目にあわなければならないのか？」といったような主張です。

両者の言い分はどちらも正しいように思え、しかし両者の意見は全く相容れないもののようにも思えます。私としては、どちらの流派が正しいといった結論を出すのではなく、両方とも必要だと考えるようにしています。どちらの流派にもユーザのニーズがあるからです。（次号に続く）。

(4)UIにおけるニーズ(ユーザビリティについて)

前回はソフトのアクセシビリティが十分ではないということと、アクセシビリティの実現には２種類の方向性があることをお話しました。今回はさらに発展させてユーザビリティについてお話しようと思います。

障害者向けのユーザインターフェースに関するアクセシビリティについての話題としては、現在、ウェブサイトの構築方法などの分野で活発に議論がなされています。アクセシビリティというのは文字通り「アクセス可能かどうか」ということです。しかしアクセシビリティが保証されれば、障害者は満足して利用できるというわけではありません。極端な例を挙げると、アクセシビリティというのは、「丈夫な二本の足があれば誰でもエベレストの山頂にアクセス可能である」といっているようなものです。つまり可能性の有無には言及しますが、難易度については言及していないのです。しかし難易度というのは重要な問題ですよね。この問題を扱うには"ユーザビリティ"という指標が必要です。ユーザビリティというのは「使いやすさ」を意味します。如何に使いやすいかという指標ですから、その根底にはアクセシビリティが必須であるということは言うまでもないでしょう。つまり(障害者を考慮にいれた)ユーザビリティについての議論はアクセシビリティの議論の延長線上にあると考えられます。ただ現在はまだ多くの分野の多くの製品でアクセシビリティが達成されていませんから、まずアクセシビリティについての議論が重要になるということは確かです。しかし全ての製品のアクセシビリティが達成されるまでは、ユーザビリティについて議論してはならないという訳ではありません。アクセシビリティとユーザビリティの議論は、同時並行的になされるべきだと私は思います。アクセシビリティを実現するために選択される手段が、同時にユーザビリティを決定するからです。

そこで如何にユーザビリティを実現するかということになるのですが、このユーザビリティという指標は実に様々な意味合いを含んでいるのです。アクセシビリティを議論する時のようにシンプルにはいかないのです。前回お話した二通りのUIの方向性について、真っ向から対立する意見が出たりするのも、実はユーザビリティにおけるどの側面を重視するかという意見の違いなのです。万人にとって最適なユーザビリティの実現手段というのはまず存在しないので、個々のニーズに合わせた製品が求められる訳です。この辺の議論はユニバーサルデザインの考え方とはちょっと意見が食い違うところですね。一つの製品で万人のニーズを完全に満たすことが可能なら、これほど素晴らしいことはないのですが、そういう理念を述べることは簡単でも、現実に製品を作る立場としては、それは非常に非常に困難なことなのです。

では、ユーザビリティには具体的にどのような側面があるのでしょうか。そしてなぜ、それらの側面を同時に満足することが難しいのでしょうか。私は一介のプログラマであり、この分野の学者でも専門家でもありませんから、こういうことを体系的に考えたことはありません。ですから厳密な議論は専門家の先生方にお任せして、私は素人が思いつく範囲内で喋る程度にします。私が思いついたユーザビリティの側面は、以下の３つです。

①わかりやすさ。
製品を使用するために特定の知識や技術や能力を必要とせず、様々なレベルの人が使用できるように配慮されていること。また使い始めてから満足して使えるようになるまでに、多くの学習を必要としない、あるいは学習するにしても、自然、かつ楽に学習できる用に配慮されているということ。

②普遍性があること。
製品の使用方法に関して、製品毎や機能毎に個別のルールを定義するのではなく、できるだけ一貫性のある普遍的なルールに従っていること。普遍的なルールとは、人体の構造に由来するルールから、業界標準などのルールまで様々なレベルのルールがあると思います。※普遍的なルールに従えば従うほど、学習量が減るという意味では①の「わかりやすさ」に通じるものがあるかもしれません。

③少ない労力で確実に使えること。
製品の使用において、目的を達成するまでに要する労力がなるべく少なく、かつ失敗する可能性が低いこと。簡潔に言えば、「操作性が良い」ということです。労力が少ないとは、操作手順が少なくて効率的であるということと、身体的精神的な疲労や不快感が少ないということを意味します。

以上の３つが思い当たりましたが、まだ他にもあるかもしれません。次号ではこうしたユーザビリティの側面について、ソフトウェアのUIに話を戻して、より深く探っていこうと思います。また今回少しだけユニバーサルデザインについて触れましたが、ユニバーサルデザインについては私も共感できるところが多く、また別の機会に詳しくお話したいと思います。