私たちが普段コミュニケーションに使う知覚はいろいろありますが、コンタクトセンターの業務ではオペレータは基本的に聴覚だけで相手の発するメッセージを受け止めます。電話なのだから当たり前です。しかし、せっかく聴覚と声だけでコミュニケーションを生み出す機能があるのに、従来のコンタクトセンターではどうしても視覚に障害のある方が使いやすい製品がなかなか見当たらなかったのは大変残念なことです。これが昔ながらの電話機を使ったシステムならまだマシなのかもしれませんが、ソフトウェアを使った通話の場合はなおさら操作が難しくなってしまいます。

弊社では普段から多くのNPOの皆様にTwilioを利用したWebブラウザ上で動作するコンタクトセンターをご利用いただいているのですが、その中の一つエンパワメントかながわ様の運営されている「デートDV110番」では、従来のコンタクトセンターのオペレータ向け基本的な機能、受話、保留、転送、内線、スーパーバイザーとしての通話への参加、入出力デバイスの切り替えを当事者の方のご協力を得て視覚障害者でも使いやすい形で実装することができました。このような仕組みがもっと広まることで音声によるコミュニケーションの手段をさらに活用していただける機会が増えると喜ばしいので、いくつかその過程で知り得たことを共有したいと思います。

音声によるPCの操作アシスタント

視覚障害者の皆さんは当然ながらGUIによるPCの操作があまり得意ではありません。そこで活躍するのが音声によるアシスト機能です。といっても、アプリケーションの操作などOSの備える機能だけではどうしても対応するのが難しいケースがあるので、そのための専用のシステムを導入されているケースが大変多く見受けられます。代表的なのはスクリーンリーダと呼ばれる仕組みで、文字通り画面に表示された文字を読み上げたり、tabキーの操作で各エレメントを移動しながらその名称などを音声で読み上げることでクリックを可能にしたりする優れものです。その中でも得に国内で大きなシェアを得ているのが高知システム開発のPC-Talkerシリーズです。ありがたいことに開発者向けにカスタマイズされたバージョン（音声が出ない代わりに製品版で読み上げられる音声が画面に表示される）が無料で提供されています。ぜひご利用ください。

設計方針

スクリーンリーダーはtabキーによるエレメントの移動でアプリケーションを切り替えたりボタン操作を実施することができます。そのため、晴眼者にとっては使いやすいファンシーなGUIもともすれば煩雑な操作が必要な使いにくいものになってしまいます。そのため、まずは可能な限り画面をシンプルに、必要最低限なものしかない状態にすることが望ましいです。

それから、セキュリティの問題についても留意する必要があります。サーバ上に配置されブラウザで利用するSaaS型ソフトウェアである以上はどのような場所で利用されるのかを完全に限定するのは難しいため、利用ケースに応じたセキュリティを考える必要があります。特に視覚障害者向けのシステムでは音声はイヤフォンを利用していただくことである程度対策することはできるので、肩越しに画面を覗き見ることによる情報漏洩を防ぐことを考慮しました。画面に表示される文字は背景と同色にすることで人間の目に見えませんがスクリーンリーダーには見えるので通常の画面と同じく操作できるようにしました。

そうそう、ログインの方法も通常とは異なるものを用意しました。晴眼者の場合は同じシステムにログインするのにパスワードとreCAPTCHAを通過する必要がありますが、それとは別に、ユーザーごとに用意された特定のURLにアクセスするとそのユーザーの登録済みのメールアドレス宛にメールが送信され、そこの記載された時間限定のURLを利用するとログインできるという仕組みになっています。

最初の失敗

一番最初のバージョンはこんな機能を用意しました。

キーボードからのコマンド入力で操作できる

以下のような代表的な機能を実装してみました。

キーボードから「m」を入力するとメニューが読み上げられます
同じく「space」を押すと着信した通話に応答することができます
「d」で切断します
「l」を押すと現在通話中の一覧が読み上げられるのでスーパーバイザーとして参加できます
通話中に「h」を押すと保留します。「u」を押すとログイン中のユーザ（オペレータ）の一覧が読み上げられるので転送できます

良かった点

操作のたびにbeep音が鳴るようにしたのでフィードバックがわかりやすい
コマンド操作自体は楽で使いやすい

欠点

点字キーボードに対応できない
スクリーンリーダーのキー操作とぶつかってしまうことがある
ブラウザのwindow.onFocusイベントに依存するのでうっかりフォーカスが外れると動かないのが利用者にわかりにくい

結論：ボツ

筆者は正しい心を有する誰もがそうであるようにvi(m)の愛用者なので、コマンドによるモード切り替えやコマンドによる操作というインターフェースを思いつくのは簡単だったのですが、このスタイルの致命的なのはスクリーンリーダーの操作と競合してしまうことでした。思いついた当初は自分の才能が怖いと震えたものですが、すぐにそんなことはないと落ち着かなければいけなくなってしまいました。

改良版

次に、全ての操作インターフェースをボタンに変更しました。画面上にはボタンだけが並んでいます。スクリーンリーダーによる操作ではDOMエレメント間の移動を素早く実現することが可能だったので、tabで上から下に移動してまた元に戻るという循環する移動を念頭に優先順位の高いものからまとめてボタンを並べた方が操作しやすいことが利用者のテストで判明しました。これなら普段ブラウザを使う操作と比較しても違和感なく使えそうです。

良かった点

慣れた操作で簡単に扱うことができる
スクリーンリーダーがボタンのラベルを読み上げるので誤操作がない

悪かった点

機能が増えるとボタンが増えるので煩雑にはなってしまう
これだからvi(m)信者は、などと悪口が聞こえる

結論：一旦リリース

見落としがちなのは、ブラウザの設定の操作が視覚障害者には大変使いにくいことでした。例えばマイクやスピーカーを別のデバイスに切り替えるような操作は大変難しくなってしまいます。そこで、画面に設定ボタンを用意して、そこをクリックした時だけデバイスの一覧がボタンとして表示され、それをクリックすることで切り替わる機能を追加してみました。最もデバイス名がいつもわかりやすいものとしてブラウザ側から見えるとは限らないので、完璧ではないのですが、そこは試して慣れてもらうしかないようでした。

こんな風に試行錯誤しながら出来上がったのがこの画面です。

見えるかな？

CSSはこんな感じですね。

button {
    color: #fff;
    background-color: #fff;
    border-color: #fff;
    border-style: none;
}

これで視覚障害者の皆さんにも安心してコンタクトセンターが利用できるようになったわけですから、個人的にとても誇らしい仕事でした。何度もビデオ通話で協力していただいた皆さんには感謝することばかりです。この場を借りて改めて御礼申し上げます。ありがとうございました。お手本がない仕組みをあれこれ考えて作るというのはとても楽しい作業でした。でも、きっともっといい仕組みを考案されている方も世の中にはいらっしゃるかもしれないので、もしこれがその方々に届けば、おいおいこうすればいいんだよとお知恵を拝借できる機会になるかもしれないので、そんなことを期待しつつ、この文章も一旦リリースしたいと思います。