HOME > 全文掲載 >

「アクセスビリティの今日的動向:バリアフリー社会の内実を考える」

石川 准 1997/11/28 於:筑波技短

last update: 20151221


アクセスビリティの今日的動向:バリアフリー社会の内実を考える

シンポジウムでの発表
石川准
19971128
於:筑波技短

はじめに
 以下では、北米(とくに米国)における視覚障害者のコンピュータ・アクセシビ
リティの今日的動向をまとめるとともに、バリアフリーをめざすうえで日本で今後
行わなければならないことを論じる。

1 視覚障害関連補助工学の分類
 視覚障害者のコンピュータ・アクセスを可能にするための技術=「補助工学」
(assistive technology)は、以下のような分野を含む。

1.1 ハードウェア(注1)
 ボイス・シンセサイザ、点字プリンタ、点字ディスプレイ、拡大ディスプレイ、
モバイル情報端末

1.2 ソフトウェア(注2)
1.2.1 専用ソフトウェアの開発
 音声ワード・プロセッサ、音声OCRシステム、音声ブラウザ、自動点訳ソフト、点
訳エディタ

1.2.2 OSや一般ソフトウェアをアクセシブルにする働きをするソフトウェアの開発
 スクリーン・リーダー

1.2.3 アクセシビリティ対応OSの設計、API等アプリケーション開発環境の提供

1.3 その他
1.3.1 ガイドライン
 Webガイドライン(ホームページ、オーサリング・ツール、ブラウザ)
ソフトウェアのユーザ・インターフェイス・ガイドライン
 マニュアルのガイドライン

1.3.2 マークアップ言語の規約改訂
 HTML CSS MML


2 クラシック・スクリーン・リーダーからモダン・スクリーン・リーダーへ
2-1 MSAA
 スクリーン・リーダー(screen reader)は視覚障害者のコンピュータ・アクセスを
可能にするための補助工学の中心的な存在である。スクリーン・リーダーは、一般
のプログラム(OS、アプリケーション)に介入しプログラムの動作に連動して、音声
・点字出力機能を提供する働きをする(注3)。
 たとえばDOSスクリーン・リーダーは、TSRまたはデバイス・ドライバとしてメモ
リ常駐し、DOSおよびBIOSが行なう入出力関連の割り込みをトラップするとともに、
ディスプレイ・バッファ(テキストVRAM)の状態変化(文字と属性)を監視し、操作
の流れ、データの流れを推定し、入出力された文字情報を必要に応じて音声あるいは
点字で表示する働きをする。一方、Windowsスクリーン・リーダーは、独立のアプリ
ケーションとして動作し、Windowsの標準APIやGDIなどを利用して情報を収集し、
off-screen-modelを構築し、キーボード・ショートカットなどに連動して必要な情
報を音声や点字で提供する働きをする。
 いずれにせよ従来のスクリーン・リーダーは、ハッキングにも似たトリッキーな
技巧を駆使する一種の「スパイソフト」である。その開発はたいへん困難であり、
多大な労力を必要とした。それでもMS-DOSのように10年以上もの間、基本的アーキ
テクチャは変更されずに広範に利用され続けたOSをターゲットとしたときには、こ
のアプローチは功を奏し大きな成果をあげた。しかし、今日のようにOSの変化が急
激な時代には、このアプローチは徒労に近いものになりつつある。
 今日、コンピュータの分野では、アクセシビリティという概念が定着しつつある。
とくに視覚障害者が直面する問題としてGUIとWebへのアクセスは大きな問題となっ
ている。
 その結果、OSメーカーのアクセシビリティへの積極的貢献が切実に望まれるよう
になり、欧米では「アクセシビリティの政治」が活性化した。その結果、今年にな
ってMicrosoft社も社会的要請に押されて、スクリーン・リーダー開発を支援する
MSAA(注4)というアクセシビリティAPIを開発し、Windows95と自社の主要アプリケ
ーション(Word97とIE4.0)に搭載した。また「ロゴ・プログラム」(Designed for
Windows Logo program)によってサードパーティにもMSAA対応を要求するというス
タンスをとりはじめた。
 従来のスクリーン・リーダーがトリッキーな技巧を駆使する「スパイソフト」で
あるのに対して、新しいスクリーン・リーダーはMSAAを通してOSやアプリケーショ
ンとコミュニケートし、必要な情報を主体的かつ公然と取得できる(MSAAはOLEと
COMに依拠しており、スクリーン・リーダーは直接オブジェクトから、名前、種類、
画面上の位置などの情報を取得することができる)というのがMicrosoft社の主張
点である。
 欧米ではWindows用スクリーン・リーダーが市場に出るまでに、5年のタイムラグ
があった(ただし、Windows95では1年弱)。今後はこのギャップは縮小すると予想
できる。なお、MSAAは現状では日本語環境に対応していないが、WINDOWS98では対
応が予定されている。ロゴ・プログラムもWINDOWS98では適応対象となる。ただし
実際の作業はまだほとんど進んでいない。

2-2 ロゴ・プログラム
 ロゴ取得のためのアクセシビリティ要件
1)コントロール・パネルのサイズ、色、マウス、キーボード設定をサポートする
2)ハイコントラスト・モードをサポートする
3)すべての機能をキーボードでサポートし、それを明示する(Windows98での要件)
4)キーボード・フォーカスの位置を明示する(Windows98での要件)

将来要件となる性能
1) MSAAまたはスタンダード・コントロールを用いて、他のソフトウェアがすべて
  の画面要素を認識し操作できるようにする。
2)10ポイント以下のフォントを使わない。
3)それが適切でさえあれば、ユーザが任意のフォント・ネームとフォント・サイ
  ズを選択できるようにする。
4)スケーラブル・システム・フォントをサポートする。
5)適切であればシステム・カラーを用い、それ以外のフォントはユーザがカスタ
  マイズできるようにする。
6)ユーザ・インターフェイスのタイミングをユーザがカスタマイズできるように
  する。
7)マウスとキーボードを使ってユーザが探索(状態確認)できるようにする。
8)重要な情報を音だけで出すことをしない。

3 Webアクセシビリティ
 インターネットでも同様のことが起きている。ホームページが、単純なハイパー
テキスト(テキストと若干の画像データ)からなる場合には、視覚障害者のWebアク
セスには大きな障害はない。だが、HTMLの規約がより高度な視覚的表現を可能にす
る方向で拡張され(たとえばクリッカブル・マップ)、さらにフレーム表現、JAVA
アプレット、PDF、・・・と、各企業によって独自拡張された規約外のグラフィカ
ルな機能が次々登場、普及するようになって、視覚障害者のWebアクセスは急速に困
難になった。
 こうした状況を踏まえ、W3C(World Wide Web Consortium)はWAI(Web Accessibility
Initiative)(注5)というWebアクセシビリティに取り組む専門グループを立ちあげ
た。WAIは、アクセシビリティの観点からのHTML4.0、CSS2.0のスペック修正提案、
ホームページ、ブラウザ、オーサリング・ツールのガイドラインの策定作業を行っ
ている。
 またJAVAに関してはSUNが、PDFについてはADOBEがそれぞれアクセシビリティに取
り組む姿勢を見せている。
 なお日本では、新聞社等の商用サイト(とくに扉ページ)でJAVAアプレットやク
リッカブル・マップを用いているためにアクセシブルでないものがめだつ。


4 JAVAアクセシビリティ
 SUNは、アクセシビリティAPI、アクセシビリティ・ユーティリティ・クラスおよ
びアクセシビリティ・ブリッジにより、JAVAアクセシビリティを実現することを今
春発表した(注6)。IBMがこれに飯能市、SUNと提携し、JAVAスクリーン・リーダーの
プロトタイプを開発した(注7)。
 来春リリースされる予定のJDK1.1をサポートするJAVAバーチャルマシンは、JAVA
アクセシビリティAPIを標準搭載するとされている。
 JAVAのユーザ・インターフェイスの利点は、ユーザが好みのプレゼンテーション
を選択できる(pluggable look and feel)アーキテクチャを採用している点にある。
これによりスクリーン・リーダーは、画面プレゼンテーションを解釈して音声プレ
ゼンテーションに変換するという、はじめから限界のある作業から解放されプログ
ラムのふるまいの意味を理解した上で、必要な情報をユーザに伝えることができる。


5 「バリアフリー社会」に内実を与えるための指針
5-1 アクセシビリティ理念の制度化
 高度情報化社会においては、電子情報、電子メディア、コンピュータへのアクセ
スは、所得、障害、居住場所にかかわらず等しく保証されなければならないという
理念を成熟させ制度化する必要がある。米国ではRehabilitation Act 504, 508,
Americans with Disabilities Act, Telecommunications Actなどの法律を整備し
たことでアクセシビリティは確実に進展した。NII(National Information Infra
structure)政策でもアクセシビリティが強調された。
 日本では通産省の「情報処理機器アクセシビリティ指針」(1990年)というガイド
ラインがある。これ自体は拘束力のないガイドラインにすぎないが、障害者雇用促
進法とのセットで一定の機能を果たしている。(障害者を雇用する企業は補助工学
に期待するという意味で)

5-2 適応追随型からユニバーサル・デザイン型の補助工学へ
 道具を使うには、道具に付けられたインターフェイスに従って道具と適切に相互
作用しなければならない。では、道具が要求するとおりにふるまえない人々はどの
ようにするのか。人は目的を実現するための便法として、何かを流用して別の何か
の代用とする、という方法を工夫する。これを、ここでは「間に合わせ技術」と呼
ぶ。ある程度の不整合なら、人は生活のなかで間に合わせ技術を工夫することで、
どうにか道具との相互作用をこなしてきた。だが、道具は多機能性と高機能性を増
すに連れ、ますますあらかじめ決められた操作手順に従って使わなければ機能しな
くなり、間に合わせや融通を認めなくなるという意味において、「純化」され「合
理化」されていく。間に合わせ技術の限界は、道具を設計した側が想定していない
利用の仕方をしているということ、様々な情報の断片を捕まえ、それを流用してア
クセスしているということである。したがって、そういった流用や代用、間に合わ
せや融通は、簡単に無視されてしまう。というより、最初から知られていない。そ
のため、間に合わせ技術が利用しているような管理されていない情報は、しばしば
本来の目的にとって不用で無意味な剰余cjして消去されていく。間に合わせ技術が
通用しなくなった時点で、人と道具との不整合はようやく社会問題として浮上する。
 アクセスを保証するための技術は補助工学と呼ばれている。だが、従来の補助工
学は大半が追随的な間に合わせ技術である。コンピュータのアーキテクチャやOSが
変更されると、補助工学は置き去りにされる。補助工学の開発はつねに後手に回り、
タイムラグが生じる。補助工学は、コンピュータやそのインターフェイスと利用者
の間の齟齬を完全には埋められない。マーケットの規模が小さいため、ベンダーは
重い開発コスト負担には耐えられない。などがそれである。
 こうした追随型の補助工学に代わって、近年重視されるようになったのがユニバ
ーサル・デザインである。基本設計にアクセシビリティを包含することで全体とし
ての社会的費用を軽減しつつ、より十全かつ速やかにアクセシビリティを実現する
ものとして期待されるようになった。

5-3 多様なインターフェイスを提供する
 MSAAはユニバーサル・デザインへ向かう第一歩として評価できるものの、GUIへの
アクセシビリティという考え方は原理的には依然として追随的である。GUIそのもの
を脱構築するアプローチが要請される。この意味ではJAVAアクセシビリティはさら
に先進的である。表示形式がpluggableな分、JAVAスクリーン・リーダーは視覚障害
者ユーザとのマッチングがよいはずだからである。視覚障害者が望むインターフェ
イスはCUI+マルチタスク(UNIX環境におけるshell+screenなどはその典型)である。
 視覚障害者は画面を見ることができない。それは大きなハンディキャップである。
だからこそ従来の発想は、いかにすれば視覚障害者は障害を克服して画面検索を行
なえるようになるのか、というものであった。しかし、クライアント領域でこそ画
面のレイアウトは意味を持つが、ウインドウ・アプリケーション操作領域では、ウ
インドウの大きさ、画面上の位置、他のウインドウとの重なりなどの情報は、画面
というハードウェアの制約とのかかわりでのみ意味を持つものであって、けっして
本質的なものではない。
 一般に、視覚障害者は障害の特性との関係で、論理的操作、言語的操作を得手と
し、非論理的操作、非言語的操作を不得手とする。また、記憶負担より検索負担が
重荷となる人々である。GUIが想定するユーザの特性とは、まったく対照的だといえ
るだろう。したがって、視覚障害者に空間や平面上での検索を要求するインターフ
ェイスは不適当である。
 もちろん、GUIでなければできないこと、たとえばWYSIWYG方式のデスクトップ・
パブリッシングなどを、視覚障害者が独力で行なえるようにするための努力に価値
がないわけではない。だがそれ以前に、従来達成されていた水準の操作性、機能性
をWindows環境で実現することが、まずめざされなければならない。

5-4 電子データの蓄積と公開
 米国の「NIIへのユニバーサル・アクセス」でも強調されていることだが、電子
情報は、極力デバイス非依存的な形態で蓄積されなければならない。すなわちデバ
イス非依存とは、出力メディア非依存、出力環境非依存、蓄積装置非依存をいう。
また、画像や音声のように本質的にデバイス依存的なデータについては、マルティ
プル・フォーマットでの蓄積が必要となる。なお、マルティプル・フォーマットと
は画像や音声にキャプションを付加したり、文章形式の代替データを用意するとい
うことを指す。


6 おわりに
 以上、本報告が扱った視覚障害者のコンピュータ・アクセスというテーマは、あ
るいは特殊だったかもしれない。だが、これは人と人、人と社会、人と道具を接合
するインターフェイスのあり方に関する基本原則=哲学の問題であることを強調し
たい。人間の特性を一元的に想定してユーザ・インターフェイスを一方向に純化し
ていくやり方は、インターフェイスと不整合を起こすユーザのアクセスを排除する
のみならず、便法による適応をも拒絶する。それは、人権という倫理的視点からし
ても、ユーザの多様化という時代状況における資本制の論理からしても、すみやか
に解決されるべき事態であると報告者は考える。
 障害者に使いやすい道具は高齢者にも使いやすく、ひいては健常者にも使いやす
いはずだ、という常套句がある。しかしそれはつねに正しいとはいえない。多様性
は調和的であるとは限らない。ある特性を持った人には使いやすい物が、別の特性
を持った人には使いにくいというのがむしろ普通である。そのことを踏まえつつ、
インターフェイスは設計されなければならない。パーソナル・コンピュータのよう
にユーザの多様性を、マルチモダリティによって解決できる場合はむしろ例外的で
ある(なぜなら一台の「パーソナル」コンピュータを複数のユーザが同時に使うこ
とは考えなくてもよいから)。ところが道路や建物となると、多様な特性を持つ人
びとが異なる特性のインターフェイスを要求しつつ、同時に利用しようとする。こ
の場合のインターフェイス(マルチユーザ・マルチモーダル・インターフェイス)
設計は困難を極める。同じ障害者でも、視覚障害者は歩道の段差を維持するように
求め、車椅子の障害者は段差を削ることを求める、といった具合である。どのよう
なブレイクスルーが可能かを徹底的に考え、妥協や譲歩の可能性をぎりぎりまで考
慮することしかさしあたり方法はない。


1)海外のハードウェア・ベンダーのほぼ網羅的なリストについては
http://www.u-shizuoka-ken.ac.jp/~ishikawa/access.htm
2)これらのソフトウェアの機能を詳しく知るには、報告者が開発した視覚障害者
用ソフトウェア(スクリーンリーダー、自動点訳ソフトウェア、音声点字エディタ)
の各マニュアルを参照されたい。
http://www.u-shizuoka-ken.ac.jp/~ishikawa/devpgm.htm
3)石川 准「GUI用スクリーン・リーダーの現状と課題:北米と欧州の取り組みを
中心に」,『情報処理』,12,1995
石川 准「共生のインターフェイス:電能福祉論によせて」,『社会臨床雑誌』,3,
1996
4)MSAA(Microsoft Active Accessibility)については
http://www.microsoft.com/enable/dev/msaa.htm参照。
5)WAIの活動については
http://www.w3.org/WAI/
WEBのガイドラインについてはTrace R & D Center's Unified Web Site
Accessibility Guidelines
http://www.trace.wisc.edu/text/guidelns/htmlgide/htmlgide.htm
6)JAVAアクセシビリティについては
http://www.sun.com/access/
7)IBMのJAVAスクリーンリーダー関連情報は
http://www.austin.ibm.com/sns/



石川准  ◇ARCHIVES
TOP HOME (http://www.arsvi.com)