様々なユーザーの入力手段の特徴とそのサポート

Webサイトのアクセスに際して、多くのユーザーはキーボードとマウス、またはタッチUIを利用しています。しかし、必ずしもすべてのユーザーが同じ環境を使っているわけではありませんから、特定の入力手段を前提とした実装をするべきではありません。

多様な入力手段

以下、様々な入力手段のうちいくつかを記します。

マウスを使用せずキーボードのみを使用する場合

以下のようなユーザーは、マウスなどのポインティング・ディバイスを使うことが困難、もしくは不可能で、キーボードのみを使用している可能性があります。

スクリーン・リーダーを利用している視覚障害者
上肢が不自由で細かい動きが苦手なユーザー

タッチUIを使用せずキーボードを使用する場合

iOSやAndroidの端末において、タッチUIをほとんど使用せず、キーボードを接続してこれを主に使用するユーザーがいます。上肢が不自由でタッチUIの細かい操作が困難な場合がまず考えられますが、障害の種別、障害の有無に関係なく、タッチUIの操作が苦手なユーザーがこういった使い方をしている可能性は充分に考えられます。

音声入力を使用する場合

上肢が不自由な人の中には、音声入力を使用しているユーザーもいます。もちろん今や障害の有無に関係なく、音声入力を使用する人は増えていますが、健常者が音声入力を使用するのは文字入力をするときが主であるのに対して、上肢が不自由なユーザーの場合は、メニューの操作などGUIの操作も音声入力で行います。

オンスクリーン・キーボード+スイッチ・インターフェース

肢体不自由のユーザーでキーボードやタッチUIを使うことが難しい場合、オンスクリーン・キーボードとスイッチ・インターフェースを組み合わせて端末機器を操作する場合があります。

「スイッチ」というと、オンとオフを切り替えるハードウェアを想像する人が多いと思いますが、ここでいうスイッチは「押しボタン」に近いイメージのものです。形状やスイッチの数は、ユーザーの身体能力に合わせて異なります。複数の指を動かすことができるユーザーの場合は、その指の本数分の小さめの押しボタンかもしれませんし、細かい指の動きができず肘から先を動かせるユーザーの場合は、大きめの押しボタン一つかもしれません。

体をほとんど動かすことができないユーザーの場合は、呼気スイッチと呼ばれるものを使うかもしれません。呼気スイッチは、ストロー状の形状のスイッチで、行きを吹き込むことでボタンを押したのと同じ信号を発するようになっています。

これらのスイッチをPCやスマートフォン、タブレットに接続して操作する仕組みが、スイッチ・インターフェースです。

詳細な挙動は環境や設定によって異なりますが、スイッチ・インターフェースを使用する場合は、だいたい以下のように端末を操作します。

1度スイッチを押すと、画面上にあるポインターが移動を開始する。
クリックしたい場所にポインターが到達した時に、再度スイッチを押す。

文字入力に当たっては、スクリーン上にキーボードを表示して（オンスクリーン・キーボード）上記の操作をします。

スイッチを複数使用できる場合は、ポインターの移動する方向を変えるなどの指示を出すこともできるようになっているようです。

多様な入力手段をサポートするための基本的な考え方

前述のように、入力手段には様々な方式がありますが、これらをなるべく広くサポートするためには、以下の点に注意する必要があります。

一般的なキーボードでの操作を保証する

多くの入力のための仕組みは、一般的なキーボードと同じ信号を発するようになっています。したがって、一般的なキーボードですべての機能の操作をできるようになっていれば、多くの入力手段に対応できる可能性が高いと考えられます。

また、当然のことですが、こうすることでキーボードのみを使用する場合にも確実に対応することができます。

マウスの誤操作を減らす

マウスを使用している場合に、誤った場所をクリックしたときに操作を取り消すことができるように、ガイドラインではトリガーにはダウン・イベントではなくアップ・イベントを使うことを求めています。

このガイドラインに従うことで、マウスによる誤操作の抑制に加えて、タッチUIや視線追跡ディバイスなど、他のポインティング・ディバイスの使用も容易にできることが考えられます。

なお、クリック・イベントは、同じコンポーネント上でのダウン・イベントとアップ・イベントの組み合わせによって発生しますので、クリック・イベントをトリガーとして用いれば、このガイドラインを満たすことになります。

テキスト情報の提供

音声入力でGUIを操作する場合、クリック（アクティベート）したい項目（メニューやアイコンなど）を言葉で指示する必要があります。あるアイコンをクリックしたい場合、そのアイコンに付いている名前が分かる、もしくは推測できなければ、音声入力でこのアイコンをクリックすることはできません。そしてもちろん、そのアイコンにそもそも言葉で表現できるような名前が付いていなければ、簡単にクリックすることはできません。

この問題を回避するためには、操作対象になるものにはAccessibleNameを付与するということが必要です。また、もしそのAccessibleNameが推測しにくいものであれば、なるべく画面上に表示されているテキストを用いると良いでしょう。AccessibleNameについては、UIコンポーネントのアクセシビリティーを参照してください。

ただ、音声入力のサポート以外の目的でも適切なAccessibleNameの付与は必要なことですから、他のガイドラインを満たしていれば、この点について取り立てて意識する必要はあまりないでしょう。

音声入力で誤ってショートカットキーが発呼しないようにする

システムによっては、音声入力でショートカットキーを押したのと同じ操作ができるようです。このようなシステムで誤ってショートカットキーが押されることがないようにするために、ショートカット・キーを提供する場合が定められています。

特定の入力手段を前提としない

前述した「一般的なキーボードでの操作を保証する」こどう徹底すれば、この点について意識する必要はないはずですが、ガイドラインでは特に以下のような場合について、注意することを求めています。

OSがサポートする入力手段の使用を阻害しない:

状況に応じて、複数の入力手段を併用する必要があるユーザーがいます。このようなユーザーの利用を阻害しないために、たとえば、タッチUIを前提としている環境で何らかの入力を求める場面において、接続されたキーボードからの入力を受け付けず、画面上に表示されたボタンを使うことを強制するといったことは回避すべきです。
加速度センサー、モーション・センサーの入力だけをトリガーにする機能を作らない:

肢体不自由のユーザーの利用を阻害しないために、たとえば端末を振るなど、ユーザーの動きだけをトリガーとするような機能は作るべきではありません。ユーザーの動きに加えて、別の手段でその機能を利用できれば問題ありません。