「この機能のアクセシビリティどうしよう」と思ったら

こんにちは、この記事は Webアクセシビリティ Advent Calendar 2020 の6日目です。

すこし前に、同僚のエンジニアに「Webアプリケーションにドラッグ＆ドロップを使う機能を作ろうとしているんだけど、アクセシビリティは何をすればいいのかわからない」という相談をされる機会がありました。そのときの回答が、実はアクセシビリティを考える上ですごく大事なことだなと思ったので、ちょっと文章化してみることにしました。

相談されたのは「新しい機能で直感的な操作を実現するためにドラッグ＆ドロップを使いたいが、アクセシビリティチェックをパスできない気がする」というような内容でした。たしかに私の会社で運用しているチェックでは、キーボードやスクリーンリーダーによる動作チェックを行っているので、それらではドラッグ＆ドロップの操作ができそうには思えません。

彼のこの相談内容からは「良いものを作ろう」という強い意思が感じられました。しかし、チェックの内容からは「ドラッグ＆ドロップはダメそう」ということが読みとれ、これが「ドラッグ＆ドロップによって直感的な操作が実現したい」という意思とコンフリクトして、2種類の「良いもの」をどうすればいいのか混乱してしまったようです。

その場では ドラッグ＆ドロップ以外のキーボードで操作できる方法で、ドラッグ＆ドロップしたのと同じ結果が得られれば十分ですよ という話をました。そこの結論に至るまでの説明をするのはアクセシビリティを考える上でけっこう大事な考え方な気がしていて、それをいま書ければと思っています。

この記事は長いです。時間がない人や読むのが面倒な人は、最後の「結果のアクセシビリティで考える」から読んでください。

誰が困りそうなのかを考えてみる

チェックリストやガイドラインは、現実世界で起こり得るさまざまな問題をもとに整理してまとめたものです。さまざまな視点を反映したものを小さなドキュメントにすることで、「最小限これに従えばいい」という形にはなっているわけですが、そのぶん「何故そうするのか」の情報は少なく、理解が難しくなってしまう側面がありそうです。

現実に起きてしまいそうな問題を想像する上で、個人的にオススメなのはイギリスの内務省が作成したアクセシビリティ啓蒙ポスター (do-donts)です。これは、「自閉症スペクトラム」「スクリーンリーダー利用者」「ロービジョン」「ディスレクシア」「身体障害・運動障害」「聴覚障害・難聴」「不安状態」のユーザーのために、「すること」「しないこと」を列挙しています。そして日本語にも翻訳されています。
なお、ポスターの内容をテキストにしたファイルも用意されています。

さて、「スクリーンリーダー利用者」と「身体障害・運動障害」のポスターにはそれぞれ、「しないこと」として「マウスや画面の使用を強制する」「マウスをたくさん動かす必要がある」があります。そしてそれに対応する「すること」として「キーボードだけで使えるように構築する」「キーボードや音声だけで使えるように設計する」が挙げられています。

スクリーンリーダーの利用者はほとんどが視覚障害者です。画面を視覚的に捉えずに使用しているのでマウスポインタがいまどこに表示されているのか、マウスポインタの位置に何が表示されているのかを知ることができません。

身体障害・運動障害にはいろいろな種類があります。マウスは平面に置かれた物を正確に動かすことが求められ、これができなかったり、苦手な場合にはキーボードのほうが扱いやすいという場合も多いようです。あるいはふつうのキーボードの形状ですら扱うのが難しい障害をもつ人には、PCの操作を補助する専用の道具を使っている場合もあります（たとえば、口に咥えた棒を使ったり、視線入力をしたりする）。文字入力はできないと困るわけで、こういった道具はキーボード用のことが多いはずです。

視覚障害の当事者以外の人にとって、スクリーンリーダーを使ってWebを操作する姿はなかなか想像しづらいですが、マウス操作がしづらい・できない状態というのは比較的簡単に想像できるんじゃないかと思います。たとえば酷い転倒をして両手首あたりを骨折してしまったら、マウス操作はかなりしんどくなりそうです。

たしかに、これらの人たちにとっては、ドラッグ＆ドロップでの作業を行うのは難しそうです。そして、代替策として、キーボードで操作できるようにしろと書かれています。

ガイドラインを読んでみる

Webアクセシビリティの標準規格である WCAG (Web Content Accessibility Guidelines) 2.1 では、すべての機能がキーボードで操作可能であることを求めています。ここでは日本語版での文面を引用します。

達成基準 2.1.1 キーボード
(レベル A)

コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボードインタフェースを通じて操作可能である。ただし、その根本的な機能が利用者の動作による始点から終点まで続く一連の軌跡に依存して実現されている場合は除く。

注記
上記の例外は、根本的な機能に関するものであり、入力手法に関するものではない。例えば、テキスト入力に手書き入力を用いるのであれば、その入力手法 (手書き) は利用者の動作による軌跡に依存した入力を必要とするが、その根本的な機能 (テキスト入力) は利用者の動作による軌跡に依存した入力を必要とするものではない。

注記
これは、キーボード操作に加えて、マウス入力、又はその他の入力手段を提供することを禁ずるものでも妨げるものでもない。
https://waic.jp/docs/WCAG21/#keyboard

WCAGの文面はちょっと独特のクセがあるというか、なかなか読むのにカロリーが必要な感じがします。将来的にWebの仕組みやあり方が変化していっても通用するように抽象的な書き方になっているせいらしいです。読みやすいように整理するとこんな感じになるでしょうか

• コンテンツのすべての機能はキーボードで操作できる
• キーボード操作のキーストロークに特定のタイミングを必要としてはいけない
• 利用者の動作による始点から終点まで続く一連の軌跡に依存して実現されている場合は仕方ない
• マウス操作は禁止というわけではない（やっていい）

「特定のタイミング」とか「始点から終点まで続く一連の軌跡」とかよくわからないものが出てきましたが、とりあえずキーボード操作ができる必要があることは読み取れます。WCAGの原文には、文中で使われる用語の定義について文中にリンクが張られていますが、これらについてはリンクも張られていません。

そういうとき、次に読むべきはUnderstanding WCAG 2.1（WCAG 2.1 解説書）というやつです。WCAGの原文ページには、それぞれの項目に「Understanding Keyboard」みたいなかたちでリンクされています。

たとえば、先ほどの「達成基準2.1.1 キーボード」からは「達成基準 2.1.1: キーボードを理解する」というページにリンクされています。これまた結構な長文なのですが、先ほど説明した「誰にとって必要なのか」や、よくわからなかった「特定のタイミング」の説明なども載っています（これは引用していくと長いので、気になる人は元の文を見てください）。

「一連の軌跡」の部分は、ドラッグ＆ドロップに関係しそうなことが書かれています。

「ただし、その根本的な機能が利用者の動作による始点から終点まで続く一連の軌跡に依存して実現されている場合は除く。」というフレーズは、キーボードから合理的に操作できないものを区別するために含まれている。

（中略）

自由な手描き、水彩画、及び障害物コースを通るヘリコプターの飛行は、いずれも軌跡に依存した入力を要する機能の事例である。直線や規則的な幾何学的図形を描く、ウィンドウのサイズを変更する及びある位置へオブジェクトをドラッグすること (その位置への軌跡に関係がない場合) は、軌跡に依存した入力を必要としない。
https://waic.jp/docs/WCAG21/Understanding/keyboard.html

ドラッグ＆ドロップは、ある地点でマウスボタンを押したまま、別の地点まで移動してから離す操作です。これは「始点から終点まで続く一連の軌跡」と言えそうです。しかし、順番の入れ替えやサイズの変更であれば、始点から終点までどういう経路を移動しようが関係がありません。つまり、「一連の軌跡に依存する」とは言えず、キーボードでの代替操作を提供する必要があります。

というわけで、やはりキーボードによる操作は必要そう、ということになります。そしてもう一つ大事なのは、ガイドライン本文にあった「これは、キーボード操作に加えて、マウス入力、又はその他の入力手段を提供することを禁ずるものでも妨げるものでもない。 」という部分です。

結果のアクセシビリティで考える

ここまで、ドラッグ＆ドロップをできない・しづらい人が存在しそうなこと、アクセシビリティの標準ガイドラインにもそう書かれていて、キーボード操作の実装が求められていることを説明しました。

しかし、ここまで長く説明したことより先に考えるべき、もっと重要なことがあります。「この機能にドラッグ＆ドロップが絶対に必要なんだろうか」ということです。

たとえば、Googleカレンダーでドラッグ＆ドロップを用いているのは、予定の日時の変更です。ユーザーにとってのゴールは「ドラッグ＆ドロップできること」ではなくて「予定の日時を変更できること」のはずです。ドラッグ＆ドロップはその手段でしかないのです。Googleカレンダーでは予定をクリックして編集画面を開くと（これはTabキーで予定にフォーカスしてEnterキーを押せば、キーボードだけでできます）、ドラッグ＆ドロップでできていたのと同じように開始時間や終了時間を設定できます。それどころかドラッグ＆ドロップより細かい時間に設定することすらできます。

Webではないですが、Windowsのエクスプローラーでファイルを別のフォルダに移動するときも、ドラッグ＆ドロップで移動させられます。しかし元のフォルダを開いて目的のファイルをコピーして、移動先のフォルダに貼りつけるやり方もできます。複数のファイルを一気に移動させるのも、マウスをドラッグして選択しても、Shiftキーを押しながら左右キーで選択してもいいのです。あるいはコマンドラインで操作するかもしれません。

冒頭で説明した事例では、「ドラッグ＆ドロップ」という特徴のイメージに引っ張られてしまっているように感じられます。たしかにドラッグ＆ドロップはモノを直接動かしているように感じられ、それに比べるとキーボードでの操作はひと手間増えているように見えます。しかし上にあげたような事例では、ドラッグ＆ドロップができる場面でも、別のやり方でやりたくなる場合はしばしばあるのではと思います。

「ドラッグ＆ドロップでやるかどうか」は「手段のアクセシビリティ」であり、「実際に移動させたりできること」は「結果のアクセシビリティ」と言えるんじゃないかと思います。同じ手段が誰でも使えれば良いですが、それよりも同じ目的を誰でも達成できることのほうがはるかに重要なはずです。ひとつの目的を果たすための手段が複数提供されていれば、利用者は最適な手段を選んで使うことができるのです。そしてこれはさきほどの例で触れたGoogleカレンダーやWindowsのエクスプローラーの例のように、障害の有無などに関係なく、すべての人にとって嬉しいことのはずなのです。