アクセシビリティはボランティアじゃないっ!
公開日 : 2007-07-21 16:24:09
スクリーンリーダー利用者とのやりとりから理解できること
「ウェブコンテンツ・テキストバージョン・ジェネレーター(Naked Beta)」なるものを作っているのだが、先日某SNSの「視覚障害者のパソコンサポート」コミュニティにて「PDFの扱い方」スレが立っていたので初めて書き込ませていただいた(Naked(Beta)ではPDFをテキスト化することができる)。
その後メンバーの方が参加しているメーリングリストで紹介いただいた関係で何通かメールをもらった (感想や要望など)。早速いくつかは反映させていただいたが、そのメールでのやりとりから改めて「音声ブラウザやスクリーンリーダーといってもその使い方は様々」ということを実感したので、ちょっと紹介させていただこうと思う(これまでにお会いして話を聞いた他の方の例もあわせて紹介したい)。
以下、利用環境の一例。
ウェブの利用の方法の一つとして、この方の場合はウェブページやPDFをクリップ・ボード経由でエディタに貼り付けることが多いとのこと。
ポイントは、PDFへ移動しようとする際にOrbitが起動してしまうこと(単に拡張子の問題だろうな)。Naked経由でPDFを読み上げる場合はOrbitのダイアログで「キャンセル」を選ぶ必要があるらしい。
エディタに貼付けるとかエクセルに(テーブルを)貼付けるってのは他の方にも聞いた事があって、スクリーンリーダー＋エクセルだと「矢印キー」でセルの移動ができるから表を読み上げるのには便利だよ、というお話をしておられた(この方には少々驚かされた。エクセルもそうだが、ページ内で欲しい情報はエディタに貼付けてエディタの検索機能を使うから、ほら、こうやって...速いだろ? って...*)。
* もちろんこの方はかなりの上級者だからこうできるのであって、一般のユーザーだとこうはいくまい。
また、他の方の場合 (弱視の方) ルーペを使えば見えるけれども (つまりソフトウェア的に拡大ではなくて、実物のルーペを使ってディスプレイに顔をくっつけて情報を見る)、音声ブラウザは楽だから読み上げソフトはよく使うよ、と言っておられた。
これは完全に余談だが「目の見える人は不便やのう(笑)。わしら重たいモニターとかいらんもん。」ってな冗談で僕らを笑わせてくれたおっちゃんもいた。
携帯ブラウザでPCサイトを閲覧する
私事で恐縮だが、Naked(Beta)を最も活用しているのは誰あろう自分自身である。用途は携帯からのPC用サイト閲覧。
スポーツのリアルタイム中継とかでPC向け無料、携帯向け有料ってサービスが結構あるので(セコいな! 俺)、Naked(Beta)の「携帯」モードのURLをブックマークに登録しておいて外出中はそこからウェブサイトを見ていることが多い。
僕の携帯には一応フルブラウザが入っているのだが、僕にとっては使いやすいものではないし、何より画像込みの重たいページをダウンロードするには電波状況がかなり良くないと途中で切れてしまうことが多い (回線速度も決して速くない)。またあの小さなディスプレイの上ではやはり携帯向けのページの方が使いやすい。
Googleのモバイルゲートウェイやライブドアの「モバウザー」とか同じようにPC用のサイトを携帯用に変換するサービスは存在するが、これらのゲートウェイで変換して「読みやすい」サイトと「読みにくい」サイトがある。これらのゲートウェイで変換して読みやすいページは、音声読み上げでも理解しやすいと考えてほぼ間違いないだろう。装飾が排除されシンプルに構造化されたテキスト情報こそが携帯ブラウザで読みやすいページであるからである。
ウェブサイトやソフトウェアは意外な使い方をされている
覚えておきたいのは、それがソフトウェアであってもウェブサイトであっても、どんな利用のされ方をされているかは全く分からないということだ。
VDMW300のほうはともかく、Orbitの開発者たちは視覚障碍者がこんな使い方をしているなんておそらく想像もしていないだろう。
サイトの中での「文字の画像化」がエディタを使ってページ内検索をする人にとってはマイナス要因になっているということも普段僕たちはあまり気にしない。
PCでの閲覧を前提にサイトを作成していて「携帯版は想定外」な場合でも、ゲートウェイを使って携帯で閲覧しているユーザーがいるかもしれない。
「サイトのターゲットはこうだから...」という考え方をするのは構わないが、そのサイトやサービスをどう使うかはユーザー次第であり、全然自分たちの想像から離れたところで有益なものとして使われているかもしれないのだ。
「色んな使い方ができる」のが「Web標準」
で、まぁ何と言うかここからが答えになるわけだが、「そんなに色んなブラウザやユーザーをターゲットにして制作する側の負担ばかり増える...」という思考の対極にあるのが「Web標準」なんだな。
表現は視覚だけじゃなく音声だけでもない。また音声にしたって使い方は一通りじゃない (だからこそIAとかペルソナ/シナリオ法とか...それはそれで大切であるが「想定外」の使い方にも耐えられるつくりにしないといけない、それがアクセシビリティ)。
どんな使い方をしてもらってもいいよ。色んな使い方ができるよ、ってのが「Web標準」の本質なのだ。
- 文書構造がもたらす利点 ～環境に依存しないコンテンツ～中村 精親/辻 勝利 株式会社ミツエーリンクス (スライド)
- Web標準の日々レポート 「文書構造がもたらす利点 ～環境に依存しないコンテンツ～」 中村精親さん 辻勝利さん | Blog hamashun.com
制作者とクライアントにメリットはあるか
これはもう滅茶苦茶あるね (日本語滅茶苦茶...)。まずユーザーにメリットがあること＝制作者の幸せでありクライアントへのメリットじゃないか。
まぁ、ありきたりのことを書いてもつまらんだろうから少し目線を変えてウェブプログラマ向けに書いてみようか。
思いつくままに羅列すると、工数短縮・コードの短縮、分業化、メンテナンス性の向上、出力されるHTMLの減量→トラフィックの節約、等々。
これらの殆どは制作者のメリットでもあるが例えば受託の開発であればクライアントのメリットに直結する。工期とコストの縮減、メンテや改良コストの縮減、さらにウェブサイトやウェブサービス利用者へのメリットがあるとなれば、もう「やらない理由が無い」ではないか。
と、まぁこのあたりで息切れして来た。「早い段階での分業化が可能」「テンプレートを半分に減らす」あたりを続いて書こうかと思っていたが、続きはいずれ書く予定。
あ、そうそう具体例を一つだけ。
SNS構築案件の時に「OpenPNE」を試してみたことがあるのだが、テンプレート数の多さとテーブルレイアウトのコードのあたりで嫌になってしまい結局採用を見送った (今のバージョンは良くなっているのかもしれないが)。何もそこまでmixi真似することもなかろうに。
これ「Web標準」ベースだったらテンプレート数とコード量おそらく半分近くになるだろう (これ本当)。テンプレート数が減ったらカスタマイズ工数も大幅減ですよ。
と、ここまで書いたところでこんなエントリー見つけてしまった...
アクセシビリティはボランティアじゃないっ!
ということでタイトル改題。まだこんなこと言ってるのか...何年前の議論だろうか。
ここまでお読みいただいた方は既にお分かりだろうが「アクセシビリティ」は何も障碍者のためだけのものではない。特にページを処理するプログラムを書く人間に対するアクセシビリティが高ければ高いほど様々なメリットが享受できるようになる。
確かに冒頭のNaked(Beta)の話はボランティアというか、実際にパソコンサポートという形でボランティアされている方とのやりとりがきっかけで...という話なのだが、何も僕自身はNaked(Beta)をボランティアで作っているわけでも趣味でつくっているわけでもない。
このプログラムの本質はHTMLの構造を保ったままてきるだけシンプルなテキストバージョンのHTMLに変換する「アクセシビリティ・テキスト変換エンジン」なのだ。で、この変換エンジンはサイト制作現場というきわめて「ビジネス」的な世界で様々な活用が可能である*。
もちろんこのプログラム自体への引き合い(製品やサイトへの組み込み)も頂いているが、変換エンジンの部分はもっと多様な利用方法を想定して作成している。
いくつか例をあげよう。
サイトリニューアル時の既存ページの変換・再利用
サイトを新しいデザインに変更するだけなのに、既存のページをいちいちコーダーがひぃひぃ言いながら流し込み直し、マークアップし直しとかするの? 何か無駄じゃない? 旧ページを機械処理でCMSにインポートして、新しいデザインテンプレートを適用して出力(某方面では「再構築」と呼ぶアレ)し直したらリニューアル終了! ってな形で活用している。
もちろん、ページの構造がきれいであればあるほど変換は容易である。
どっか(どこ?)の制作会社に騙されて(!) 「Web標準」で作ってみたけどリニューアル見積もりとったら全然安くないじゃん! というクライアントの皆さんはどうぞウチの会社にご連絡を。きっとびっくりするようなワークフローと見積もりの提案が可能かと*。
* もちろん、ウチ的にちゃんとそれで利益があがるわけです。スタッフも「ひぃひぃ」言わないし。
サイト運用におけるアクセシビリティの継続確保
せっかくCMS入れたのに覚える事沢山すぎる...あんたらフォームの全半角揃えとかはサーバー側で行うべきとか言うくせに、CMSへのテキスト入力の際は私らが気をつけないといかんのか? というクライアントの皆さんはどうぞウチの会社にご連絡を。ガイドラインに違反した入力は可能な限り機械的に修正・出力するという考え方でCMS構築します。
何か単なる宣伝になってきたな...まぁ、工数短縮・コード縮減のあたりでも書いたが、「Web標準」ベースだとサイト全体にわたる修正とかも楽だから、「えー!! ここまできて全ページにかかる修正ですか!? 勘弁してください」とか言われなくて済むようになるし。
とか...本当に息切れしてきたので続きはまた今度書く...かもしれない。
