視覚障碍者プログラマのためのツール

Autobiography of a Blind Programmer(視覚障碍者プログラマの自伝)』という記事を投稿した後、コンピュータをどのように使っているのか、どのようにコードを書いているのか、そしてどのように抽象的概念を理解しているのかよく聞かれました。

先週この記事を書き始めたのですが、話が脱線しがちになることに気が付きました。ツールに関係のない過去の話を持ち出してしまっていました。個人的な好みやなぜ好んでいるのかを長々と説明していました。なぜこのようなことを言っているのか。

それは、上のリンクの記事、『Autobiography of a Blind Programmer(視覚障碍者プログラマの自伝)』をぜひ読んでいただきたいのです。もし、その気になれない場合は、頭の片隅にでも置いておいてください。私の経歴に興味がわいた時にでも読んでください。

前置きはこのくらいにして、この記事の本題に入りましょう。

日常使うツール

スクリーンリーダ

視覚障碍を持つユーザはスクリーンリーダと呼ばれるものを使っています。そう、名前のとおりスクリーンに表示されるものを読み上げてくれるのです。とても強力な機能を持っています。例えば、マウスの制御が可能で、スクリーン上の要素を階層的に見ることができます(メニューバーを操作したり、ツールバー内で項目を移動させたりできます)。しかし、スクリーンリーダの持つさらにすごい機能はWebコンテンツの扱い方です。ごく基本的な機能としては、リストやヘッダー、ボタンやテキストのフィールドなどの異なる種類の要素から要素へと移動できることです。高度な機能としては、レベル1の(h1要素である)ヘッダーへジャンプできるような粒度です。そして、多くのWebページが使っているため、最近重要になりつつあるのがWAI-ARIAを処理する機能です(例えばGoogle DocsTwitterfacebookなど)。

他のプログラムと同じように、使っているスクリーンリーダによって異なる機能があります。例えば、私は、視覚障碍者によって書かれた質の高いフリーソフトであるNVDAを使っています。しかもこれを使えば海賊版を探す必要がありません。しかし、他にもスクリーンリーダはあります。Jaws(別名Job Access With Speech)は人気がありましたが、最近は利用者数が減っています。また、利用者が増えているWindow-Eyesがあります。最近の(ブラウザ、スクリーンリーダ、ブラウザとスクリーンリーダの組み合わせなどの)傾向を知りたい人は、WebAIMによって実施されたスクリーンリーダユーザ調査の第6の結果をご覧ください。少数派によって使われているものの統計的な傾向を知ることができます。

しかし、これらはWindows用になります。MacやiOSには、VoiceOverと呼ばれるスクリーンリーダが内臓されています。Linuxには、GnomeデスクトップについてくるOrcaと呼ばれるスクリーンリーダがあります。デスクトップ環境のないユーザには、Speakupプロジェクトがあります。AndroidユーザにはGoogleがGoogle Talkbackを提供しています。

完全に網羅するために、Chromeを使っている人には、通常ChromeVoxと呼ばれるものがスクリーンリーダの拡張機能として提供されています。これは、Chromeとスクリーンリーダから独立して相互作用するクロスプラットフォームとされ、さらにChrome OSのスクリーンリーダとされています。

私はWindowsとAndroidを使っているので、スクリーンリーダはNVDAとGoogle Talkbackを使っています。

プログラミング言語

プログラミング言語を学ぶのが大好きなため、全てを1言語ですることはありません。しかし、高い頻度で使っていたプログラミング言語は次のとおりです。

  • PHP (仕事で使用しています)
  • Go (これも仕事で使用していますが、PHPほどではありません)
  • Elixir (家でいじっています)
  • Scala (常々いじってみたいと思っている言語ですが、膨大な言語機能に圧倒され、いつもいじらず仕舞いです)

もちろん、他の言語もいじっていますが、上に挙げたものを主に使っています。

統合開発環境

まず、統合開発環境に期待するものを定義します。

良い統合開発環境にはオートコンプリート機能がなければなりません。関数やクラス、変数の宣言にジャンプできたり、機能のドキュメントを表示できたりしないといけません(DocBlockでもいいですし、ビルトイン機能のドキュメントでもいいです)。もちろん、ローカル変数の抽出や関数の移動、名前を付け直すようなリファクタリングは重要です。

個人的にはあまりこだわりませんが、あるといいと思うのが、コマンドラインから簡単に実行できるプロジェクトの依存性(composergo getnpmなどのパッケージマネージャ)を統合開発環境に持たせることです。統合開発環境から直接バイナリの構築を行うには便利になりえますが、私の場合はaltキーとtabキーを同時に押すだけでターミナルに移動できますし、矢印で最後のコマンドラインに移動することも、さらにenterキーを押すと再度実行することもできます。統合開発環境でこのような機能がなくても問題はありません。

多くの場合、EclipseやEclipseをベースにした統合開発環境を使っています。イランにいるため、海賊版を入手しています(例えばZend Studio)。しかし、他のコマンドライン式ではない統合開発環境提供のものよりもEclipseのアクセシビリティ機能の方が遥かに優れています(後でなぜ私がコマンドラインを使わないのか説明します)。

PHPのツールのアクセシビリティを深く掘り下げたThe State of Accessibility in PHP Toolsという記事をSitePointに投稿しています。要約すると以下のとおりです。

  • PHPStormは最悪でしたが、時と共に変化しています。IntelliJプラットフォームは最近まで非常にアクセシビリティが悪かったと言えます。もちろんAndroid Studioも変わってきており、Android Studio自体がEclipseをベースにした統合開発環境にもう少しで匹敵するまでになりました。PHPStormがスクリーンリーダとの互換性がないことを問題提起しています。そしてこれを多くの人が指示してくれたおかげで実現させることの中で優先順位を上げてくれ(IntelliJの開発者には感謝です)、着手し始めています。2016年に変化が来ることを願います。
  • SublimeTextは実に最悪です。アクセシビリティのリクエストに対して開発チームは無反応です。全く対象外のようです。
  • NetBeansはプログラミング言語Quorumの開発者によって作られました。最近は使っていませんが、Quorumの統合開発環境であるSodbeansから良くなったと聞いています。
  • Notepad++はただ動くというだけです。もちろんオートコンプリート機能などはスクリーンリーダとはうまく作動しませんが、Unixスタイルラインエンディングをサポートしているとても軽量なノートパッドなので急いで行う作業には便利だと思います。

OS

仕事でもプライベートでもWindowsを使っています。古いノートパソコンにLinuxをインストールしてEmacsやEmacspeakで遊びながら、無限にあるショートカットを使いこなせるか試しています。しかし、アクセシビリティという観点ではLinuxのブラウザはWindowsのブラウザほど良くないので、今の時点ではWindowsを使い続けようと考えています。

現在、視覚障碍者のコンピュータユーザが十分いるとは言えないため、多くのアプリケーションの中から視覚障碍者ユーザにとって使いやすいものを選び出すことができません。Linux OSを使用しているのが視覚障碍者の1パーセントだけと仮定します。もしスクリーンリーダが高度ではなく、デスクトップ(例えばKDEのような)環境が他の同様のOSにアクセシビリティが及ばず、更新が非常に遅かったらどうでしょう。もちろん使うことは可能です。ただUXの面でMac OS XやWindowsほど整っていません。

初めは視覚障碍者にとってWindowsよりもLinuxの方がアクセシビリティが高いと思うでしょう。根本的にその考えは正しいです。では、なぜLinuxの方がアクセシビリティが高いと思うのでしょうか。理由は、Linuxを思い浮かべる時にスクリーン上で急速にスクロールされる文字をイメージするからです。多くの人は「もしテキストのみならば、そのOSは視覚障碍者に適している」と思うはずです。そのとおりなのです。ある程度は。

インターネットのことになると問題が浮上してきます。最近ではネットサーフィンするにはJavaScriptを実行できるブラウザが必要になるため、コマンドラインが使用できないことになります。すると、ブラウザやブラウザでのアクセスについて考える必要があり、Adobe Flash PlayerなどはLinuxでは提供されていませんし、代替のプラットフォームも存在しません。PHP関連の記事、PHP: a fractal of bad design(PHP: 悪いデザインのフラクタル)で書かれているように、多くの小さな問題が存在します。全てがなんとなく動くけれど、異なるソリューションとしてはしっくりこないのです。

注:PHPをやり玉に挙げているわけではありません。ただ多くの開発者が知るツールボックスについての有名な例なのでこの記事を引用している次第です。

Web開発においてLinuxが必須部分であることは多くの人が知るところだと思っています。私はこの問題を解決するためにVagrantを使って開発環境を作成しました。Vagrantの利点はWindowsでコードを書くことができ、Linuxでコマンドラインを書いて実際にアプリケーションの構築と実行をすることができる点です。イランでイメージのダウンロードが許可されていないため、Dockerは使っていません。

ここまで読んで、なぜMacを使わないのかと思っていることでしょう。なぜなら、Macは使い勝手のいいGUIを提供し、ターミナルを指先で操作できるようにデザインされているからです。確かにそうなのです。VoiceOverは使い勝手のいいスクリーンリーダですが、私の直面したMac OS Xの問題はもっと単純なことなのです。問題はMac OS Xが閉鎖的であることです。LinuxやWindowsではどのスクリーンリーダをどの音声合成器との組み合わせでもインストールすることが可能です。しかしながら、Mac OS Xで使えるのはOS X対応のスクリーンリーダや音声合成器のみなのです。そのため、イラン語のサポートを追加するために、私と友人2名が貢献しているオープンソースのテキスト読み上げソフト、eSpeakを使うことができません。このプラットフォームではこのテキスト読み上げソフトがサポートされていないので、母国語でコミュニケーションを取ることができません。

開発支援ツール

人によってものを視覚化するために用いるアプリケーションは様々です。看板やマインドマップソフト、財政管理ソフトなどたくさんあります。プログラミングにおいては、たくさんの図表やグラフ、いろいろなタイプのイラストがあります。これらをどうしているのか。大体使っているのか。

多くの場合、使っていません。

大学在学中、教授がUML図を使ってデータベースの概念について話していました。線型代数学など、データの表現や計算を図にしていました。こんな時私は一生懸命にこの講義で話された概念を理解するしかありませんでした。常にこのようなプレッシャーに加え、仕事を終わらせて帰宅することしか頭にない教授のせいもあり、この教育システムで逆境に立ち向かってまで勉強する価値がないことに気が付きました。その時退学したのです。

このような問題は大学の講義に限定されません。Machine Learning Foundations: A Case Study Approach(機械学習の基礎:ケーススタディでのアプローチ)というコースを受けました。このコースでも一部同じような手法、例えば線形回帰のようなものが使われました。概念を理解できないため、よく聞かれる「単純な線形回帰は、プロットや線形代数を使用せずに行うことができるのか」という質問にたどり着いてしまいました。物に触れないと視覚化ができないわけではありません。ただ、そもそも線やプロットに関係のない概念がそれらを介して説明されるのか理解できませんでした。データを視覚化することでどのようにデータポイントが散在しているのか確認するのは理解できますが、統計的問題の解決策として傾き切片型を使用するのは、うーん、理解できません。

実を言うと、私はプロットを使わずに線形回帰の概念を説明する記事に取り組んでいるところです。この準備が整うまでは、実際に私の真意を説明することはできません。とはいえ、必要以上に複雑な方法で行われているように見えるこうした多くの概念には、いつも混乱させられます。私にとって線分やグラフといったものは直感的に分かるものではないということもあり、その言わんとするところはお分かりいただけるかと思います。

これをWebアプリケーションの世界に拡張してみると、多くの似たような機能でも、その意味が失われます。例えば、私はGoogle Analyticsが効果的に使えません。マウスをホバーする以外に、インタフェースにおける生データを簡易的に閲覧する手段がないからです。そのため、Google Analyticsからデータを取り込んで簡単な表に起こすためのJavaScriptアプリケーションに取り掛かることにしたのです。これにより、私はデータを比較することができ、必要に応じてミックスしたりマッチさせたりすることができるのです。

反対意見もおありでしょうが、ここではさておき、私にとって役立っているものを紹介しましょう。

私が自分のやることリストをまとめるために使っているのはTrelloです。標準のWAI-ARIAの仕様になっていないため、Trelloを使うためのインタフェースは簡単ではありません。キーボードで使うことができるのに、多くのことを知らせてくれないのです。例えば、jkを使ってリストのカードをナビゲートすると、きちんとナビゲートはされますが、スクリーンリーダに今どのカードがフォーカスされているのかということを知らせてはくれません。つまり、私はキーボードを使って別のカードに誘導できると言いつつ、実際のところはできないのです。なぜなら、今どのタスクにフォーカスされているか私には分からないからです。Google Mailはこれをより良く実装しており、jkは別のeメールにあなたを誘導するよう機能し、さらに新たに選択するものにフォーカスするようにも誘導します。つまり、これはスクリーンリーダが新たにフォーカスしたものを教えてくれるということであり、実質的には、私は自分が必要とする特定のeメールを選択中だということが分かるということになるのです。

ソーシャルネットワークにおいて、私はTwitterやFacebookのWebサイトを使うためにTWBlueを使用しています。質問に回答するためにはQuoraを頼っていますが、それは私の日課の1つというわけではありません。

私のクリエイティブな作業のプロセスはかなり異質なものです。あいにく、これを自分自身でひも解くために、神経言語プログラミングといった分野に明るい人に相談できるわけではありません。問題は、mind mapは見る者に刺激を与えますが、私がただ何かを書き溜めていても同じような刺激は与えられないということです。

私が選んだ開発支援ツールでできることがプログラミングツールでできること以上とは思っていません。自分にとってもっと最適なソリューションを見つけるため、あるいは試して創り出すため、いろいろと遊んでみなければいけないと思っています。

まとめ

視覚障碍者であるということについて、私が気に入っている点がいくつかあります。そのうちの1つは、多くの時間を費やして自身の道を切り開く必要性があることです。自分以外のみんながやっている方法をただ同じように行っても意味がありません。それではうまくいかないのですから。超基本的なレベルから内容を理解する必要があり、あるいは最適なやり方を見つけ出すために試行錯誤を繰り返す必要があります。例えば、誰かが「フリーランサーになるべき10の理由」を教えてくれたとします。多くの人がそのリストをただ眺めては、自分の夢や、こうなっていたいと想像する将来のビジョンと比較して、最終的に自分はフリーランスになるべきかどうかを決定できます。しかし私は、その道を選んだ場合、視覚障碍者であるということが強みになろうと弱みになろうと、常に考えなければなりません。これまでどおりに継続していくために10の理由のリストを見て思うのは、「私は自分でユーザインタフェースを作り出す必要があるか?」という質問です。現時点では、はっきりと「イエス」と答えます。それが、私がフリーランスにはならない理由です。

しかし、これは最も初期のレベルです。成功者たちはそうした状況に直面すると、そうした状況を楽しむようになり、何かを形にし、それを満足いくまで手直ししていきます。それは、プログラマが常に思い描いていたとおりの形になるまで、書いたコードのリファクタリングを行うようなものです。石工が大理石の作品を少しずつ削りながら、彼らの思いが現実の形となるまで細かな作業を積み重ねていくことにも似ています。

私がなりたいのはそういう人です。それが私の願うやり方なのです。

追伸:WordPressでサイトを構築したいので、サイト移動を助けてくれる方を探しています。もしテーマ開発者で、私の新しいテーマをデザインしたいという方がいましたら、本サイトのヘッダーおよびフッターに記載されているソーシャルメディアのリンク、あるいはお問い合わせフォームから、私までご連絡をいただけたらと思います。