ウェブ・アクセシビリティ支援ツールに思うこと
こんにちは、みんなのハッピーを目指してお仕事しているHitoyamです。
正直に言うと、みんなのハッピーと同じくらい、生活費が重要です！ 給料バンザイ！
さて、突然ですが、ウェブ・アクセシビリティを担保するための支援ツールというものがありますよね。そういったツールについて常日頃から思っていることがありまして、書いてみようかと。
支援ツールは有料・無料含めてたくさんあるのですが、今回は官公庁や自治体などでの導入実績が多い「ZoomSight」と「WebUD」の2つを例に挙げたいと思います。
アクセシビリティ・サポーター「ZoomSight」
「みんなにやさしい」をコンセプトに第一回キッズデザイン賞も受賞している、日立公共システムエンジニアリング株式会社のツールです。
ZoomSightが利用できる環境
※基本、WWWサーバに導入することが前提のツールですが、ここではクライアント環境のみを考えます。
導入サイトである西東京市を実例として『ZoomSightをご利用ください』のページを見てみると
このツールは、Windows 2000 SP4、Windows XP SP2、Windows XP SP3、Windows Vista、Windows Vista SP1、Internet Explorer 5.5 SP2からInternet Explorer 7 までのパソコンをお使いの方のみご利用いただけます。
とあります。むむむ、と。できるだけ多くの方にホームページを快適に閲覧いただくために用意されたツールであるにも関わらず、IEでしか使えないことになっています。
ちなみに西東京市の同ページには「ZoomSightをご利用になれない方」というリンクがあり、WindowsとMac、IEとNetscapeでのフォントサイズ設定の仕方が説明されていたりします。
ZoomSightの利用方法
新規に利用を開始するには、Administrator権限でインストールを行う必要があります。場合によってはブラウザの再起動が必要です。パソコンの操作に慣れていない人が自力でインストールをするには、手順が少し難しい気もします。支援ツールを導入する支援をしてくれる人がいれば問題はないのでしょうが。
ウェブ・アクセシビリティ支援ツール「WebUD」（富士通株式会社）
「ITのユニバーサルデザイン」推進を掲げる富士通が手がけるツールです。
WebUDが利用できる環境
※基本、WWWサーバに導入することが前提のツールですが、ここではクライアント環境のみを考えます。
導入サイトである草加市を実例として『WebUDの動作環境』を見てみると
Windows(R) 98 SecondEdition/Me/2000Professional/XP 日本語版 Internet Explorer 5.5 SP2/6.0必須
とあります。やはりWindowsのIEしか動作しないようですし、IE7以降の動作は保証されていないことが分かります。ただし、バージョンの新しいWebUDはIE7にも対応しているようです。
WebUDの利用方法
新規に利用を開始するには、こちらもAdministrator権限でのインストールが必要です。
WebUDそのものが独立したブラウザなので、WebUDを立ち上げて操作を開始します。
独立したブラウザではありますが、支援機能を使うにはWebUDがあらかじめサーバ側に導入されているサイトでなければなりません。また、各サイトごとにWebUDを使用するための手順を踏まなければならず、それを忘れると導入されたサイトでも支援機能を使うことはできないままです。
構築する側が注意すべきこと
上記に代表されるような支援ツール使用を前提としたサイトを構築する際には、いくつか気を付けなければならないことがあったりします。
「互換モード」推奨
特に気を付けるべき点は、DOCTYPE宣言の際の「標準モード」と「互換モード」についてです。先に挙げた2つのツールの場合、実はどちらも「互換モード」推奨なのです。
導入実績を見ると、CSSでレイアウトを実現しているサイトのほとんどは互換モードで書かれています。標準モード宣言もたくさん見られますが、ひとつひとつを確認していくと、そういったサイトはそもそもCSSレイアウトではなく、テーブルレイアウトを使用していることが分かります。
見た目の表示に関わる部分だけならまだよいのですが（いやよくないけど）、文字を小さく／大きくボタンが使えなくなるケースもあるようです。
色変更機能
色変更機能を実装しているツールの場合、背景色や文字色のコントロールで思いもよらない動作をすることがあります。他ボックスのmarginと干渉しあって意図しない部分が塗りつぶされたり、floatやpositionの使用で印刷表示がされなくなったり...。
すべての条件で表示テストをする必要がありますが、色変更＋印刷を利用する場合は実際に印刷をしてみないと結果が分からないので、何十枚も印刷しなければなりません。
JavaScriptの制限
たとえばIE6で横幅を制御するようなスクリプトはよく使用されるものだと思いますが、ツールとの相性はよくないようで、エラーが出る場合が多いです。その場合はエラーを出すスクリプトを外さなければなりません。
何が言いたいのかと言うと...
個人的な感想でしかないのですが、「できるだけ多くの人に使ってもらいたいから」という理由で導入しているツールが、逆に利用者の幅を狭めているように思えて仕方ありません。
「そんなツール自分は使わないので構わない」と言うのは簡単なのですが、そういったツールに合わせるために仕様を落としていかなければならない（という言い方が適切なのかどうかは分かりませんが）というのは、大変にデメリットが大きいことだと思うのです。
実際はこうした支援ツールに触れる機会は少ないのだと思います、使う側も作る側も。けれど官公庁や自治体などでの導入は多いんですよね。しかもそれが「良いこと」だとされている現実があります。
もちろん優れた点もあるし、使い慣れて馴染んでいる方もいると思うので、それは良いことだと思います。例に挙げたツールも含めて、支援ツールを全否定する意味のエントリではないのですよ。誤解させてたらごめんなさい。
ただ、「ツールを導入する＝アクセシビリティの担保」という思考停止状態はいかがなものかと感じる場面が多いことは否めません。本当にそれでいいのか、提供する側としてもっともっと考えようよ。って、個人の小さな声ではありますが、言いたかったんです。
特別な支援ツールがなくても同等の仕組みが実現できるブラウザやアドオン、それに素直に読んでもらえるHTMLソースがあれば、みんながハッピーなのに！
ブラウザベンダーさんにはもちろん頑張っていただきたいですが、サイト設計者さんは的確な設計を！ デザイナーさんは美しくかつ視認性の高いデザインを！ コーダーさんは整然としたHTML＆CSSを！ プログラマーさんは抜群のプログラムを！
そんなふうに当たり前の仕事を当たり前にできたらいいのになぁ。
- 2009年11月10日 00:10
- トラックバック(0)
トラックバック(0)
トラックバックURL: http://www.hitoyam.com/mt5/mt-tb.cgi/487
