キーボードアクセシビリティを超えて

現在、マルチデバイス対応が盛んに叫ばれていますが、そもそも多様なデバイスに対応するということは何を意味しているのでしょうか？私は特定のデバイスに依存しない・依存度を下げるということだと考えています。

アクセシビリティでは、これまでも「特定の環境・特定のデバイスに依存しない」ということが一貫して主張されてきました。本稿では、ユーザーインターフェースが操作できるか、という点に注目して「特定の環境・特定のデバイスに依存しない」ということを考えたいと思います。

これまで、ユーザーインターフェースが特定のデバイスに依存しないという文脈では、「マウスと同様にキーボードで操作できること」が注目されてきました。しかし、キーボードのサポートはあくまでも最初の一歩であり、様々なデバイスからのアクセスが一般的になった現在では、より多くの入力デバイスに対応する、あるいは、そもそも特定の入力デバイスに依存しないことが重要です。

キーボードのみをサポートしていればアクセシブル？

アクセシビリティの国際的なガイドラインである、Web Content Accessibility Guidelines（WCAG）2.0には「Keyboard Accessible: Make all functionality available from a keyboard.（キーボード操作可能: すべての機能をキーボードから利用できるようにする。）」というガイドラインがあります。このガイドラインの背景には、PCでの利用を前提としたWebサイトにおいて、マウスで操作できてもキーボードでは操作できないユーザーインターフェースが作られてきた（作られている）という事実があります。

もちろん、キーボードをサポートすることは非常に重要です。身体的な障害などにより、マウスを利用できないユーザーはキーボードを使ってWebページを操作することが一般的です。また、障害の有無に関わらず、マウスが突然故障してしまった場合にもキーボードを使ってWebページを操作する必要がでてくるでしょう。私も、セミナーではマウスで細かい操作をすることが難しいため、キーボードを使ってデモページを操作しており、キーボードで操作できないユーザーインターフェースの扱いにはいつも苦慮しています。

このように、キーボードは非常に重要な入力デバイスなのですが、現在はスマートフォンをはじめとして、ハードウェアキーボードを持たないデバイスも普及しています。さらに音声認識のような入力デバイスも一般化しつつあります。このような状況ではキーボードのみをサポートしても「誰もがWebページを利用できる」とは言えなくなってくるでしょう。

本稿では、具体的な例を見ながら考えを深めていきたいと思います。

例1：プレゼンテーションのスライド

まずは、プレゼンテーションのスライドを考えます。スライドテンプレートとして、次のような仕様を考えてみましょう。

• 画面には1つのスライドのみを表示し、他のスライドは非表示
• 左右矢印キーを押すと前後のスライドに移動
• 前後のスライドに移動するボタンなどは画面に置かない

この架空のスライドテンプレートは、仕様通り実装されれば、キーボードのみで操作できます。しかし、スマートフォンやタブレットのようなハードウェアキーボードがないデバイスでは前後のスライドに移動できません。

スライドテンプレートの場合にはスワイプジェスチャーをサポートすることで、タッチスクリーンでも操作することができます。実際のスライドテンプレートを見ても、W3Cが公開しているSlidyは2011年にスワイプジェスチャーに対応しました（参考：HTML Slidy on smart phones and tablets）。

一方で、キーボードでもタッチスクリーンでもない入力デバイスは今後一切登場しない、と言い切れる人はいないでしょう。であるならば、デバイスに依存しない形でスライドを操作できるユーザーインターフェースを最初から提供した方がより望ましいと言えるでしょう。例えば、「前後のスライドに移動するボタンなどは画面に置かない」という仕様を見直して、画面上にスライドを移動するリンクやボタンを設置する/しないの選択肢を提供することで、デバイスへの依存度を下げることができます。

例2：絞り込み検索

もう1つ例として、ユーザーの入力に応じて候補を絞り込んで表示するユーザーインターフェースを考えます。

• ユーザーが入力欄にテキストを入力すると、入力に一致する候補を表示

この仕様に対して、次のように実装することにしました。

• 入力欄で発生するキーボード入力を監視
• キーボード入力が発生すると、入力欄のテキストを取得し、候補を絞り込んで表示

これも、仕様通り実装すれば、キーボード操作のみで候補を表示させることができます。しかし、入力欄のテキストはキーボードを使わなくても変化します。音声入力やマウスを使ってテキストを貼り付ける操作ではキーボードを使いません。

キーボード入力のみを監視している場合、このような入力を拾えず、候補を表示することができないことになります。

HTML5は、ユーザーが入力に使ったデバイス（キーボード、マウス、音声認識、など）によらず、ユーザーが入力を行ったことを表すイベントを新たに定義しています。この新しいイベント（inputイベント）はユーザーが入力に使ったデバイスに依存しないため、ユーザーがキーボードを使おうと、マウスや音声認識を使おうと、あるいは、全く新しい入力デバイスを使おうと、入力を拾うことができます。inputイベントはInternet Explorer 9をはじめとしてGoogle Chrome、Mozilla Firefox、Safariといった主要なブラウザーで既にサポートされています。Web技術そのものがデバイス非依存への流れを強めてきていると私は感じています。

多様なデバイスで使えることがアクセシビリティ

キーボードのサポートは重要ですし、今後もサポートし続ける必要があります。ですが、キーボードのみが入力デバイスというわけでもありません。今後はキーボードのサポートに加えて、それ以外の入力デバイスへの対応が必要となる場面が増えていくでしょう。

その際、個々の入力デバイスに都度対応していくとコストが増えるばかりです。それよりはユーザーが必要とする機能をよく吟味し、最初から特定のデバイスに依存しない形で機能を提供することの方が、より効率的かつ効果的にアクセシビリティを高められると私は考えています。

マルチデバイスへの対応が叫ばれる時代だからこそ、アクセシビリティをもう一度見つめなおしてみませんか。