第1回A.A.O.セミナー　基調講演資料
アクセシビリティは高い技術と正しい思想により実現する

石川 准　先生　（静岡県立大学 国際関係学部　教授）

１　アクセシビリティの思想

• だれもが自由に情報を受発信できる電子情報共生社会→inclusive information societyをめざす。
• そのためには配慮の平等を。
• 配慮を必要としない人々と配慮を必要とする人々がいるのでなく、配慮されている人々と配慮されていない人々がいる。

ページの先頭へ

2　アクセシビリティはユニバーサルデザインと支援技術の共同作業である

2-1 ユニバーサルデザイン

• universal designあるいはdesign for allは建築分野から。その後、交通、情報分野へと拡大した。
• アメリカ障害者法とリハビリテーション法第５０８条に具現された。
• ICT企業がアクセシビリティに目を向けるようになる。たとえばMicrosoft社のMSAA。
• W3CもWAI（Web Accessibility Initiative）を組織し、ウェブアクセシビリティ・ガイドラインを策定。
• 日本も電子政府におけるバリア解消を掲げ、ISO/IECガイド71→セクターガイドライン→個別規格の策定作業。
• 携帯電話でも、高齢者や視覚障害者のアクセシビリティに配慮したユニバーサルデザインタイプのものが登場。
• 放送分野では、２００７年までにテレビ放送の字幕対応１００％達成という努力目標が総務省によって示されている。NHKは音声認識技術を用いた字幕放送の提供を始めている。
• 国連は２００３年１２月に第１回の世界情報社会サミットを開催。
• とはいえ、電子情報通信分野で真にユニバーサルデザインと呼べるものはまだほとんどない。後付けでアクセシビリティへの配慮を付加したもの（バリアフリーアプローチ）ばかり。限界がある。→支援技術への過度な負荷

2-2 支援技術

• 支援技術には、スクリーンリーダー、音声ブラウザ、画面拡大、オンスクリーンキーボード、自動点訳、視線入力、文字認識、音声認識、点字ディスプレイ、点字プリンタ、各種スイッチ等。
• 支援技術のマーケットは小さいため、開発費を十分には投入できない。→ ICTの進歩に支援技術がついていくのはたいへん。
• また対象とする電子情報通信機器のアクセシビリティへの配慮＝ユニバーサルデザインへの努力が不十分だと支援技術の負担が大きくなる。
• スクリーンリーダーによるGUI（Graphical User Interface）→AUI(Aural User Interface)変換には限界がある。

2-3 ウェブの場合

• ウェブアクセシビリティは、ウェブサイトと支援技術の共同作業。
• マークアップ言語のユニバーサルデザイン化、オーサリングツールのアクセシビリティ・ガイドライン準拠なども重要。

ページの先頭へ

３　GUIはdesign for allではない

• ユニバーサルデザインの考え方に立てば、人がユーザインタフェースに合わせるのでなく、ユーザインタフェースが人に合わせるべきだが現実はそうではない。
• GUIがユーザインタフェースの標準となっている。それをスクリーンリーダーでAUI(aural user interface)やBUI(Braille user interface)に変換して操作するのは至難の業。
• 目は情報を網膜全体で認識して面で処理できる、つまり一望できる。
• 耳は音波の到達した順にしか認識できない。１単語、１文ずつしか理解できない。
• 一度にすべてを見ることのできないユーザには、GUIはストレス。
• 支援技術ががんばっても、GUI-AUI変換, GUI-BUI変換では使いやすい道具にはならない。

ページの先頭へ

4　WWWの流れ

• 1989年、ティム・バーナーズ＝リーは、CERN（欧州合同原子核研究機構）内部の情報共有システムとして、ネットワークを使ったハイパーテキストシステムの導入を提案。環境に依存しない情報共有を実現するためのユニバーサルな約束→URI, http, htmlの３ルール
• １９９３年にはモザイク、１９９４年にはネットスケープが開発された。 1994年にWWWコンソーシアム（W3C）設立。企業や研究開発機関がメンバー。公的な標準化団体ではない。しかしWWWのデファクト標準化団体
• W3Cがアクセシビリティに力を入れるようになる。コンテンツ、ブラウザ、オーサリングツールのアクセシビリティガイドラインを策定。
• 情報処理、情報交換のコンピュータによる自動化のためにXMLが開発された。
• html→xhtml
• さらにセマンティックウェブへ

ページの先頭へ

5　音声ブラウザと音声ユーザ

5-1 音声ブラウザの種類

1. IEのコンポーネントを使った音声ブラウザ
2. IE＋スクリーンリーダー
3. 独立の音声ブラウザ

5-2　視覚ブラウザと音声ブラウザ

• 視覚ブラウザと音声ブラウザではまったくレンダリングが違う。
• 晴眼者は文字の大きさ、強調、色、配置などで総合的に検索できる。大部分のコンテンツは視覚的な表現だけを念頭に作られているので、音声ブラウザはユーザに十分な情報を提供できない。
• ウェブサイトは、視覚ブラウザによるレンダリングだけに気を配っている。音声ブラウザによるレンダリングは単純なものにしかなりえない。
• なぜなら音声ブラウザがレンダリングにおいて利用できる論理構造情報は正しく提供されないのが普通だから。

5-3　視覚障害者が期待するサイト構造

• リンクは選択リストにつけられており、内容はもっとも深い階層に置かれていると暗に想定。
• メインメニューのページ→サブメニューのページ→本文ページ

5-4　検索方法の違い

• 晴眼者は文字の大きさ、強調、色、配置などで総合的に検索。
• 視覚障害者はA要素の内容だけを聞いて判断することが多い。先頭からすべて聞くのは効率が悪いため。
• したがって、ページ内リンクがないと、いま開いているページの本文は見落とされる危険がある。

5-5　ナビゲーションスキップ

• ページ先頭にナビゲーションスキップを用意する。飛び先に｢ここから本文｣を入れる。ただし、本文の先頭に必ずH要素があれば、ナビゲーションスキップはなくてもよいかもしれない。（ブラウザ側で対応できるから）
• なおXHTML2.0ではNLという要素が追加される予定。

5-6　論理構造の重要性

• アクセシブルなページは、論理構造がきちんとしているページ。つまり、大見出し、小見出し、本文、という構造がきちんとしていれば、音声ブラウザは、必要な情報にすばやくたどりつけるようにユーザをアシストできる。
• H要素、P要素、UL, OL, DL, Tableなどのブロックレベル要素を正しく使う。これらは視覚的レンダリングのために誤用されている。

ページの先頭へ

6　フォームのアクセシビリティ

6-1 Labelがないといけない場合

フォームのコントロール(input, select, textarea)にはラベルを貼るのが望ましい。

例
1室　　おとな<input type=”text” name=”txt_pers1″ size=”3″ value=”” maxlength=”2″>名さまこども<input type=”text” name=”txt_chld1″ size=”3″ value=”” maxlength=”2″>名さま

でなく

<label> 1室　　おとな<input type=”text” name=”txt_pers1″ size=”3″ value=”” maxlength=”2″>名さま</label><label>こども<input type=”text” name=”txt_chld1″ size=”3″ value=”” maxlength=”2″>名さま</label>

6-2 Java ScriptでonChangeにすると

• コンボボックスで下カーソルを押すとJava Scriptがキックされてしまう。
• ブラウザによって、特別な機能ショートカットが用意されている場合もあるが、一般にはほとんど知られていない。
• Windows IE6.0、OPERA 7.1では、Alt+下カーソル、NN7.1では、下カーソル

例
<SELECT onchange=”openFAQ(this.options[this.selectedIndex].value)”>
<OPTION>お選び下さい　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
<OPTION VALUE=”/cgi-bin/faq/faq.cgi?target=20010402150243&d=1&c=1″>ドメインとは？
<OPTION VALUE=”/cgi-bin/faq/faq.cgi?target=20010403001835&d=1&c=1″>DNSとは？
<OPTION VALUE=”/cgi-bin/faq/faq.cgi?target=20010403001915&d=1&c=1″>ドメインを取得するとどんなメリットがあるの？
<OPTION VALUE=”/cgi-bin/faq/faq.cgi?target=20010403002040&d=1&c=1″>gTLDやccTLDとは？
</SELECT>

ページの先頭へ

7 音声ブラウザのJava Script対応には限界がある

現状ほとんどの音声ブラウザ、スクリーンリーダーはonMouseOverに対応できていない。onClickも同様。

onMouseOverに対処するには

1. onMouseOverが設定されている要素をユーザに明示しなければならない。
2. キーボードでマウスポインタを動かすモードを用意しなければならない。
3. onMouseOverで新しく表示された情報、変更された情報をユーザが読めるようにしなければならない。

上記機能の実現は容易ではない。

ページの先頭へ

8　最悪のFlashオンリーページ

• Flashだけのページはどうにもならない。
• Flashは音声ブラウザによるFlash以外の部分の読み上げを阻害することもある。
• 短いメッセージならアクセシブルなFlash＋代替テキスト。
• 大規模なコンテンツならHTML版も提供すべき。

ページの先頭へ

9 PDF

• PDFで電子文書を提供したいなら、少なくともPDFメーカーでタグ付きPDFを作るべき。
• だが、PDFアクセシビリティは不完全。
• 現状ではHTML版も公開するのが適切。
• XMLへのシフトに期待。

ページの先頭へ

10　Webアクセシビリティの基本原則

1. 規格と仕様に準拠する
2. 構造と表示スタイルを分離する
3. 操作と入力をインタフェース依存にしない
4. 非テキスト情報には代替テキストを提供する
5. 色や形に依存しないで情報を提示する
6. 文字サイズを固定しない
7. 音声出力はユーザの意向を尊重する
8. 動画等の表示速度に配慮する
9. 言語を明示する

ページの先頭へ

11 結論

アクセシビリティは高い技術と正しい思想により実現する。

以上

2004年1月13日　第1回A.A.O.セミナー基調講演配布資料より

• 第1回A.A.O.セミナー開催報告へ