Torisugariの日記： アクセシビリティとリテラシ 2

(APIについて)
俗にアクセシビリティAPIと呼ばれているものがあります。具体的に言うと、WindowsならMSAAで、GNOMEならAT-SPIなどのことです。プログラミングに興味がない人はあまり耳に馴染みの無い用語でしょうが、細かい固有名詞はともかく、そういった人にも決して無関係な話ではありません。

そもそも、アクセシビリティAPIとは、音声読み上げソフトや拡大鏡ソフトのために、プラットフォーム側が用意した規格に沿って、対応するアプリケーション側で実装されている機能のことです。誤解を恐れずに言えば、音声読み上げソフトや拡大鏡ソフトのためのバックドアです。ただし、これはプラットフォーム公認でアプリケーション側がわざと開けている広義のバックドアなので、セキュリティホールの類を心配する必要はありません。ただ、この事実をある程度正確に把握しておくべきだとは思います。

例えば、「現在ブラウザで閲覧中のウェブサイトのURLを知りたい」とします。この時、人間ならば、画面を見て、ブラウザのURLバーに表示されている文字を読めば、すぐ分かります。しかし、ソフトウェア的な解決はそう簡単ではありません。人間の手順に倣うなら、まずアプリケーションのスクリーンショットを取って、URLバーの位置を判断し、画像をOCRにかけて書かれている文字を文字列に変換する、という手順を踏むことになります。

無論、これは馬鹿げた方法です。なぜなら、ブラウザ自身はURLを文字列として保持しているはずなので、これをデータとして教えてもらえば済む話だからです。ここで、素直に考えると、ブラウザに寄生して、こちらの要求に応じてURLを漏らしてくれるようなソフトウェアがあればいいということになります。このようなソフトウェアはMozillaの用語では「拡張」といいます。そしてこれが正解です。適切な拡張を作ってインストールすれば、別にスクリーンショットを解析しなくても、ソフトウェア的な解決でURLを知ることができます。

もう勘のいい人は分かっていると思いますが、「現在ブラウザで閲覧中のウェブサイトのURLを知りたい」という技術的な要求には、実はスクリーンショットの解析も、拡張のインストールも必要ありません。近代的なブラウザにはウェブサイトのURLを漏らす機能が予め備わっています。それがアクセシビリティAPIです。実際のところ、Firefoxの場合は、前二者の方法に比べて遥かに簡潔にこのようなソフトを書き上げることができます。ここに設計上のブレイクスルーがあります。

もともと、「現在ブラウザで閲覧中のウェブサイトのURLを通知する」という機能は、介助ソフトに必要な機能として実装されているわけですが、この機能が介助ソフトにだけ有用な機能ではないことは自明でしょう。例えば、アクセスログを作成する時などにも使えます。従来、「URLを知りたい」というFAQに対しては「プロクシを設置しろ」とか「netstat系で確認しろ」と答えるのが一般的であり、ブラウザから直接答えを引き出すのはあまり筋が良い技術とは考えられていませんでした。

(続く)
(続き2011-03-11)

もともと、「現在ブラウザで閲覧中のウェブサイトのURLを通知する」という機能は、介助ソフトに必要な機能として実装されているわけですが、この機能が介助ソフトにだけ有用な機能ではないことは自明でしょう。例えば、ローカルのアクセスログを作成する時などにも使えます。従来、「URLを知りたい」というFAQに対しては「プロクシを設置しろ」とか「netstat系で確認しろ」と答えるのが一般的であり、ブラウザのように複雑なアプリケーションから直接答えを引き出すのはあまり筋が良い技術とは考えられていませんでした。しかし、アクセシビリティAPIを通じてURLを取得するのは、「プロクシでログを取る」に匹敵するくらいには十分合理的な方法であり、データの蓄積・評価方法によっては、より相応しい場合も多々あります。従業員のブラウザを監視するシステムの場合、「休み時間中にスラッシュドットにアクセスする」のと「就業時間中にそれを眺める」のは決定的に異なった評価をされるべき行動であるにもかかわらず、ネットワークのアクセスログやブラウザの履歴ではこの2者の区別がつきません。しかし、アクセシビリティAPIを使えば「ブラウザで閲覧中のURL」がわかるので、就業時間に閲覧中のURLをシステムが記録しておけます。少なくとも、この用途においてアクセシビリティAPIを使った方法は、プロクシその他の方法に比べて頭1つ飛びぬけています。

繰り返しますが、アクセシビリティAPIは、アクセス能力の弱者への救済を目的に作られた機能です。しかし、この機能をその目的からのみ理解しようとすると、前段の例のような、ある種の「実用性」を見逃してしまいます。目的を理解した上でさらに、「アクセシビリティAPIとは何なのか」という問いに対する理解が必要なのです。

URLバーのようなGUIは、「人間のユーザー」がブラウザを操作するための機能です。これに対して、「現在ブラウザで閲覧中のウェブサイトのURLを通知する」といったアクセシビリティAPIは、音声読み上げソフトなどがブラウザを操作するための機能です。つまり、「『ユーザーとしてのソフトウェア』のためのUI」がアクセシビリティAPIの本質です。アクセシビリティAPIが救済している弱者はソフトウェアだったのです。そのソフトウェアには音声読み上げソフトや拡大鏡ソフトも含まれますから、最終的には人間の弱者も救済されますが、一方で、そのソフトウェアにはブラウザ監視ソフトも含まれている、と、そういうわけです。ですから、アクセシビリティAPIという通称の「アクセシビリティ」の部分はやや誤解を招くので、十分広まってしまう前に何かもっと適当な名前を付けた方が良いのかもしれませんね。そこまで私はフォローしきれませんけれど。

とまれ、アクセシビリティAPIの用途は、「アクセシビリティの向上」という所期の目的より広大です。ソフトウェアが人間向けのアプリケーションを使いこなす時代に差し掛かってきた、と言えるのかもしれません。俄かには適当な使い道が思いつきませんけど、例えば、実際のブラウザを使ったクローラやボットを簡単に作ることができます。なにしろ、UAが本物なのですから、サーバー側からは全く見分けがつかないでしょう。また、ウェブアプリケーションの開発者にとってみれば、各種ブラウザを使いこなしてウェブサイトをテストしてくれるボットに何か感じるところがあるのではないでしょうか。さらに、「従業員の監視」は、「アクセシビリティの向上」よりも実用的であり、有体に言って金の匂いがする目的ですよね。ですから、技術者は福祉目的でないアクセシビリティAPIについて、もう少し検討してみることを薦めます。いや、福祉目的の方も検討してもらっていいんですけどね。

その半面、ここまで読んだブラウザの利用者には、アクセシビリティAPIの応用の結果、なにか窮屈な世界が展開されるような印象を与えてしまったかもしれません。まあ、実際のところ、ある種のスパイウェアが作りやすくなるのは事実ですから、副作用がゼロとは強弁できません。そこまで恐れるほどのものでもないのですが、そういった懸念を解決するには、アクセシビリティAPIに対する理解を深める以外にないわけで、究極的にはそれがリテラシなんだろうと思います。

当初の予定より随分長くなってしまったので、まとめておきます。

• アクセシビリティのガイドラインを引き合いに出す時は慎重に。
• アクセシビリティAPIはUIのようなもので、アクセシビリティの向上とは直接関係ない。