Network Accessibility Project (NAP)

NAP;音声・点字によるWeb アクセスに関する勉強会メモ

この記録は、出席者の渡辺さんがとられたものに、加筆・修正したものです。

1. 概要

• 日付；2002年9月7日(土) 13:00から16:30
• 場所；筑波大学附属盲学校
• 参加者； 22名
• 記録；渡辺

2. 最初に (中根)

今回はいろいろな人が参加している。 今後具体的なテーマで勉強できればいいなと思っている。 まずは最初にみんなの意識や知識を同じレベルに持っていきたい。

3. 高村；「視覚障害者のPC利用の説明」

皆さんと一緒に考えながら話を進めたい、いつでもinterrupt歓迎。

視覚が使えない場合、まず聴覚そして触覚で補おうとする。

• テキストの時代；画面出力を音で読み上げる。
  • 単に音声化しただけではだめ（音は消える、どこを読んでいるのかわからない）。
  • 音で画面をブラウズする工夫が始まった。
  • 点字ディスプレイも作られたが、高価、一度に表示可能な文字数 が少ない(40-80文字)し、一行のみしか表示できない。画面表示を文字に変換 して読む。AlVAの点字ディスプレイをお見せする。
  • スクリーンリーダ（SR）で音声や点字出力；音は聞いたところから消えていく、点字は今いる一行しか表示できない。
  • 最初のSRは画面全体を理解させようとしたので、頭の中で画面を再構成しなければならなかった。
  • 全体のレイアウトを知れば内容を掴み易い；音でも点字でもこれ は困難、そこで画面全体ではなくて行単位で考えるようにした、従って行単位 で読み上げさせる機能ができた、しかしどの行を読んでいるかわからなくなるので場所を確認する機能が必要。
  • 点字でもう少し効率上げよう、フル画面は無理、全体のレイアウトイメージを知るために点字を縦に並べて一行を4点で示し、文字の有無だけをスキャンできるようにする機能ができた。
• Windows登場、GUIになって行単位が意味を持たなくなった。
  • 画面レイアウトを知るために、画面を100分割して情報の有無を表示するSRができた。
  • アイコンは目で見れば絵の意味がすぐに分かるが、音で絵を表現 しても意味は伝わらない。効果音などで意味を伝える earconは実用化しなかった。
  • 目で見てすぐに分かることを別の形で音声表示する機能が必要；SRはWindowsの内部情報を取得して音声表示しようとすることが必要、情報を変換して音声や触覚に提示。
  • 画面にあるものを何でも読み上げさせると使えない！ ではどうすればよいかという研究は進んできている。
  • このような機能があれば理解できるか？ 訓練も必要、見るのと聞くのとの違いも明白になる。

目をつむって立方体を思い浮かべてください；晴眼者は斜めから見た図が思い浮かぶが、視覚障害者は手で持った形で思い浮かぶ、これが同じイメージは持てなくても同じobjectを理解できる例。

3.1 質疑応答

• 点字ディスプレイの値段は、 40桁表示のもので 50万程度、 80桁表示の ものでは 100万を越える。
• 点字を読める人は一割、中高生までに習わないと実用的なレベルで読める ようにならない可能性が高い。
• 「視覚障害者」といった場合、全盲だけでなく、弱視の人も含まれる。 ま た中途失明の人が多い。
• 拡大読書機の売り上げは年間3千台というデータがあるが、これから考え ると点字ディスプレイは100台くらい?
• 音声はアメリカで発達（英語だけに対応すればよい）、点字は欧州で発達 (異なる言語に対応する複数の音声合成装置の開発が困難だった) 、音声と点 字をうまく組み合わせる必要がある。
• 地図；絵を見てから文字説明を見ると良く分かる、マルチモーダルが有効。
• 受ける側もある程度のお膳立てをしてもらえれば理解できる。

4. 中根；「音声ブラウザの紹介」

視覚障害者が使う環境には、大きく二つある。

• SRとテキストブラウザの組み合わせ。
• ブラウザが解析した情報をユーザに分かりやすい形に加工して提示する形 式。

前者の例としては、 W3Mや Lynxが挙げられる。ユーザは、 SRを使って画 面に表示されているテキストやそのレイアウトを取得し、情報を理解する。

後者の例としては、 IBM Home Page Readerや VE2000が挙げられる。これらは IEが解析した情報をユーザが理解しやすい形で提示し、ユーザが使いやすいイ ンタフェースを提供している。

JAWS, PC-Talkerなどの最近の SRでは、 IEが出力した画面の状態を解析する のではなく、 IEが解析した情報を取得してユーザに提示している。特に JAWS の場合は、 HPRとほぼ同等の機能を持っているので、その実現方法などを考え ると、 SRに HPRが組み込まれているようなものである、という言い方もでき る。

テキストブラウザと SRの組み合わせに比べて、 IEなどの一般的なブラウザの 上にインタフェースを構築する HPRや最近の SRのような形式の方が、 Web技 術の変化に追随しやすいという利点があるのではないかと思う。

今日はHPRとWinAltair（VEGAのWindows移植版）をお見せする。Jaws + IE は多分できない。

4.1 質疑応答

• HPRのようなIEの音声化だとmediaがscreenになるので、 Aural Cascading Style Sheet (ACSS)に対応できない。
• Webブラウザの音声利用の問題は、問題のレイヤーの切り分けが必要。ペー ジのデザインの問題、ブラウザの問題、ユーザの知識不足の問題。
• 日本語の音声合成は機能が低いのでACSSに対応しきれない問題もある。
• Operaは軽いし、W3Cの標準に対応しようとしているしキー操作で使える。 しかしSRとの連携が今の段階ではうまく行っていないようである。ALT属性の内 用が tooltip として表示できない。 (しかしこれが HTMLの仕様であり、　ＩＥの実装が誤り。) CSSの使い分けはできる。 表示の制御が容易。弱視の人は使いやすいはず。

5. 中根、内田；「各種WebブラウザによるWWW表示のデモ」

5.1 筑波大学附属盲学校のWebサイト (テキスト版)

5.1.1 Home Page Reader 3.01

リンクは女性の声。訪れたリンクはちょっと棒読み。header要素は音で合 図して声も少し遅くなる。カーソルの左右キーでナビゲーション。Tabでリンクジャ ンプ。スペースキーで連続読み上げ。耳で聞いたときに情報の階層構造がわかるか?

質疑応答

• リンクを女性で読むのはわずらわしくないか? ；個人の慣れの問題か。
• (項目が列挙されている目次部分に関して) 最初に32項目あるとわかっていればたくさんリンクがあっても我慢できるが、そうでないとストレス
• 項目が多いとき、階層を深くするとどこにいるか分からなくなる。しかし一階層に数が多いと覚えきれない。
• ユーザ側が機能を知らないと使いやすくならない。
• リンクのリストはよく使うが、リンク名に意味がないと「ここへ」ではどこにリンクしているのか分からない。
• ページ間の移動で、どの階層にいるかを分かるようにするためにも、何 が書いてあるのかで分かるように適切なtitle要素を書くべき。
• 何度も見て慣れているページだとリンクの数が多くても問題ない。初めて使うページとよく使うページでは違う。最初にリンクの数を教えるようにするのは最初に見る人にはよいが、いつも数を教えてくれると今度はわずらわしくなる。
• ユーザテストをしないとわからない。
• 音声合成の読み上げ間違い「方（ほう）へ」を「かたへ」と読む。どう対処するか?

5.1.2 WinAltair (VEGA)

Windowsでも使えるようになったテキストブラウザ。Altairはエディタ。リンクには強制的に番号がついて、必ず行頭に置かれる。今回はProTalkerで読ませる。かなり特有なブラウザ。ブラウザだけではなく、辞書検索などを含んで統合的に使える総合環境。

リンク単位でジャンプ可能。エディタの機能で情報検索や加工ができる。論理行で表示。声の使い分けはできない。

5.2 www.asahi.com

まずは画面を見ずに聞いてみてください。画面上部のトップバーや画面左のバーの読み上げが終わらないと本文にたどりつかない。

5.2.1 HPR

質疑応答

• テーブルナビゲーションモードを活用すれば本物のテーブルを理解しや すい。 asahi.com にあるようなレイアウトのために table要素が用いられて いる場合はあまり意味がないが、場合によっては理解の助けになる。
• HPRでasahi.comのような構成のページを読むときは、ページの先頭から ページダウンキーを何回押すと望みの記事にたどり着くかを学習する。あるい は早送り（パラグラフの先頭だけ速度を落とすことができる）を使うなどの工 夫をする。

5.2.2 WinAltair (VEGA)

デモは省略。

5.3 www.yodobashi.com

スクリプトなどで生成されたコンテンツなのか、 alt属性のついていない 画像リンクが多い。また、リンク先のファイル名からその意味を推測できない ような機械的な名前付けがされている。

サイト内の検索機能を使うと使いやすい。

6. Closing

• 公共サイトはアクセシビリティを考えて作るべき。
• あちこちのWebを使うので、初めてのページを見る数が多くなり、ストレスがたまる。
• 視覚障害者に使いにくいページは一般の人にも使いにくい。ユーザビリティの一部としてのアクセシビリティを提起すべき。
• e-CommerceのサイトでWeb自体はよくないが使ってみるとよい企業は結構ある。
• お客様の満足度を計るのは、発注したお客様のみ。発注しなかったお客さまの意見は逃してしまう。
• ヨドバシカメラなどは、こちらから提起してあげれば取り入れてもらえるのではないか。
• オンラインショッピング；声でも案内する機能は有用か?
• Flashで声を使って案内するサイト。次に行くボタンにフォーカスをあてられないから使えない。
• Flashが普及してきている。
• 一度作ってしまったものを後から改善するのは難しい。デザイナなどの コンテンツ製作者への教育が大事。またアクセシビリティを改善しても見た目が変わらないから予算がつかない。
• 日本語だと対象のアイテムの頭文字を入力してジャンプすることができ ないので、 Windows上でたくさん候補があるプルダウンメニューやリストボックスは使いにくい。
• プルダウン以外の方法で情報を入力できることが必要。この方が早い場合がある。
• ブラウザのページ内文字列検索の機能は有用。

7. 今後の予定

NAPの今後の活動をどうするか。アイデアを出して欲しい。今のアイデアは (1)サイトの評価、(2)特定の技術的話題に絞ってサイトを見たりデザインのア イデアを出す（ALTのつけ方など）、(3)特定の音声・点字ブラウズ環境につい て徹底的に掘り下げての勉強。2ヶ月に一回できるか？

• NAPとしてやるのならサイト評価をして提言をしていくのがよいのでは。