UA Research

Ver1.2 2006年3月6日(最終更新日時: 2006年3月16日 15:13 )

日本の視覚障害者用ウェブ利用ソフトの機能調査

目次

この報告書について

この報告書の公開URL:
http://www.comm.twcu.ac.jp/~nabe/data/UAResearch2005/
問い合わせ先:
UAResearch @ comm .twcu .ac .jp

利用上の注意

この調査は、ユーザエージェント(ウェブブラウザやスクリーンリーダ)の性能を比較するのが目的ではない.また,特定のユーザエージェントがW3C/WAIのUAAG (User Agent Accessibility Guidelines) 1.0の要件を満たしていると断言するものではなく,ユーザエージェント開発者の同意を得ているわけではないので,この調査結果を,UAAG 1.0の要件を満たしているか否かの報告書として捉えないこと.また,この調査結果は完全なものではなく,調査に用いたテストファイルの内容やテスト結果の解釈によって変わる場合がある.特に,W3C/WAI UAAG 1.0 Test Suitesの曖昧さのため,テスターによって判断が分かれることがあることに注意されたい.

改訂履歴

2006年3月15日
プレスリリース配信.日本語テストファイルの注釈追加.
2006年3月6日
トップページを全面的に書き直してバージョン1.2として公開.各ユーザエージェントの調査結果も修正.
2006年2月6日
HPR3.04 SP3でテスト結果をupdate
2005年12月22日
調査結果を公開

調査担当者

はじめに

総務省の「平成16年度通信利用動向調査」によると,日本のインターネット利用人口は,2004年末で8千万人に達しており,日本の人口の62.3%がインターネットを利用していることになる.インプレス社の『インターネット白書2005』によれば,利用しているウェブ(World Wide Web)サイトの第一位が検索系サービス(39.0%)で,以下,オークションサービス(24.3%),ショッピングサービス(23.1%),ウェブメール系サービス(18.6%)と続く.同書によれば,全世界のウェブサーバの数は2005年5月時点で6,353万台にのぼり,さらに急速に増加中である.総務省自治行政局の「地方自治情報管理概要」(2004年4月1日現在)によれば,地方自治体の申請・届出システムのオンライン化も進んでおり,2005年度末の時点で,全都道府県の94%がオンライン汎用システムを導入予定である.このように,インターネットやウェブは幅広く利用され,人々の生活をより便利なものにしている.

ウェブを閲覧する方法や環境は様々であり,低速接続の人,テキストブラウザや様々な支援技術を用いてウェブを閲覧している人などがいる.たとえば,総務省の「平成16年度通信利用動向調査」によると,60歳以上のインターネット利用率は2004年度末で26%に達している.この数字は20歳代の利用率92%と比較すると小さいが,60歳以上の利用率が3年前と比較して2.43倍という急成長を見せていることを考えると,今後,幅広い年代に渡ってインターネットが利用されることが予想できる.また,電子メールによって調査が行われた国立特殊教育総合研究所の「視覚障害者のWindowsパソコン及びインターネット利用状況調査2002」(渡辺哲也)によると,回答者99人のうち95名がインターネット(ウェブ)で情報検索しており,約3分の1の回答者がネットショッピングを利用していることがわかる.

このようにインターネットが情報を得るための重要なツールとなった今日,障害者や高齢者を含むすべての人がウェブを利用できることが重要である.ウェブで利用されている技術の標準化をすすめている国際コンソーシアムW3C (World Wide Web Consortium)WAI (Web Accessibility Initiative)では,ウェブ・アクセシビリティ(身体的・年齢的制約に関わらず,ウェブで提供されている情報にアクセスし,利用できること)に関するガイドラインなどを作成している.特に,ウェブコンテンツに関するガイドラインであるWeb Content Accessibility Guidelines 1.0 (WCAG 1.0)は1999年にW3Cの勧告になり,世界中の国や組織などで広く利用されている.日本でも2004年6月に,日本版WCAGとでもいうべき,JIS X 8341-3:2004「高齢者・障害者等配慮設計指針 -情報通信における機器,ソフトウェア及びサービス- 第3部:ウェブコンテンツ」 が公示され,これを受けて,地方自治体をはじめとするウェブサイトのアクセシビリティ向上の取り組みが進んでいる.

残念ながら現実には,高齢者や障害者が利用できないウェブサイトがまだ多い.『日経パソコン』が2005年1月に発表した,主要17省庁のウェブサイトのアクセシビリティ調査によると,JIS X 8341-3を踏まえて『日経パソコン』が独自に作成した項目で100点満点で評価したところ,最低31点から最高78点となり,点が良かったサイトでもアクセシビリティに関する基本的な配慮がないなど,課題が多いことがわかった. 米国の"The State of Federal Websites: The Pursuit of Excellence"によると, (Bobbyでチェックした結果,)リハビリテーション508条があるにもかかわらず,連邦政府のウェブサイトのうち13.5%しか基準に準拠していない. 欧州では,英国内閣府が2005年11月に公開した"eAccessibility of public sector services in the European Union"によると,EU加盟25カ国の政府機関の計436ウェブサイトのうち,わずか3%しかWCAG 1.0のレベルAに適合していない.このように,公共機関のウェブサイトでも,WCAG 1.0やJIS X 8341-3や508条などのガイドラインに準拠したサイトが少ない.

ウェブのアクセシビリティを向上するためには,これらのガイドラインに基づいてウェブ作者が配慮することが大事である.しかし,そのウェブコンテンツを表示するユーザエージェントの機能が詳細にわからなければ,コンテンツの作者が配慮しようがない場合がある.たとえば,ウェブページの主要部分へのアクセスを容易にするためにアクセスキーを設定しても,ユーザエージェントがアクセスキーを活用する機能を持っていなければ,せっかくの指定が無駄になる.別例として画像要素の代替情報を考えてみると,画像には,alt属性(画像の代わりに表示されるテキスト),title属性(要素についての情報),longdesc属性(画像についての説明を記述したドキュメントのURL)の3通りの方法で画像以外の情報を提供できる.作者がこれらすべての属性に適切な代替情報を記述しても,ユーザエージェントがlongdesc属性をサポートしていなかったら,ユーザはこの情報を利用できない.あるいは,見出し要素を使ってコンテンツの構造をマークアップしても,ユーザエージェントが見出し要素を区別して表示できなかったら,ウェブの利用者はどれが見出しであるかがわからない.したがって,ウェブ・アクセシビリティ向上のためには,ユーザエージェントの機能を調べることも重要である.

日本人は日本語を利用するので,日本の障害者が利用するユーザエージェントは米国などで用いられるユーザエージェントと同じ物を利用できない.英語用のソフトを日本語化するか,あるいは独自に日本語用のソフトを開発することになる.いずれにしても日本の障害者数は英語を利用する障害者の数と比較してかなり少ないため,市場が狭い.そのため,英語圏のソフトと比較して改良が遅れたり,機能が劣ったりする場合が多い.したがって,日本におけるウェブ・アクセシビリティを向上させるためには,日本で使われているユーザエージェントの機能を網羅的に調べる必要がある.

目次に戻る

1. 調査の目的

「はじめに」で述べた問題を含めて,本調査は,以下の問題を解決する,あるいは問題解決のための基礎資料を得ることを目的としている.

  1. ウェブコンテンツを表示するユーザエージェントの機能が詳細にわからなければコンテンツの作者が配慮することが難しい場合がある.そこで,日本の視覚障害者が利用しているユーザエージェントの機能を総合的に調査する.
  2. WCAG 1.0のガイドラインの一部には,「ユーザエージェントでXXができるようになるまでは,(コンテンツ側でYYするように配慮する.)」という記述がある.このようなユーザエージェントの機能への依存性を除去するために,W3C/WAIのWCAGワーキンググループで開発中のWCAG 2.0 Working Draftには,baselineという概念が持ち込まれた.これによって,日本で利用できるユーザエージェントの機能を日本のbaselineとして定めて,そのbaselineに従って,ウェブコンテンツの作者にアクセシビリティへの配慮を求めることになる.つまり,もし,日本のユーザエージェントがJavaScriptに対応していなければ,日本のウェブ作者はJavaScriptの代替機能を用意しなければならないが,JavaScriptが日本のユーザエージェント(支援技術)で汎用に利用できる技術なら,日本のウェブ作者はアクセシブルなJavaScriptを用意するだけでよい.日本で何が利用できて何が利用できないかを明確に知ることで,日本のbaselineを定める基礎資料とする.
  3. W3C/WAIのUAAGワーキンググループでは,米国の検証結果に示すように,後述するUAAG 1.0用のテストスーツを使用して,アメリカで利用されている代表的なユーザエージェントを調査し,調査結果をウェブで公開している.日本ではこのようなテストはまだ行われていなかったので,同じテストスーツを用いて調査を行うことで,日米のユーザエージェントの機能差を客観的に比較することができる.
  4. 2004年に日本でJIS X 8341-3が策定されたが,JISは頻繁に改定されるべきではないという考えから,規定はできるだけ技術に依存しないように書かれている.また,JIS X 8341-3が発効された後,利用者からいくつかの質問や意見が寄せられた.これらの疑問に答えるため,また,JIS X 8341-3の理解を促進するため,日本規格協会情報技術標準化研究センター(INSTAC)に設置された「情報アクセシビリティの国際標準化委員会ウェブ・アクセシビリティ国際規格調査研究会(WG2)」は「JIS X 8341-3 技術解説ワーキングドラフト」を作成した.日本のユーザエージェントの事情にあわせた詳細な技術文書を提供するためには,日本のユーザエージェントの機能を詳細にする必要がある.
  5. W3C/WAIのUAAGワーキンググループが作成したUAAG 1.0とそのTest Suitesが,日本でも適用できるかを検証する.
  6. PDFやFlashが,現在の日本のユーザエージェントでどの程度読み上げ可能かを調べる.
  7. これまで曖昧だった日本の障害者用ユーザエージェントの機能を調査することによって,ウェブのアクセシビリティ確保におけるコンテンツ作者とユーザエージェント開発者の責任範囲を明確にし,アクセシビリティ向上を目指して今後進むべき方向への指針をたてる.

目次に戻る

2. 調査方法

本調査では,テスト結果の客観性(再現性)と調査する機能の網羅性を確保するためにテストファイルを用いる.すべてのテストは,調査時点で最新のWindows Updateを適用済みの,Windows XP SP2で行われた.以下,本調査で用いた3種類のテストファイル,(1) UAAG 1.0 Test Suite for HTML 4.01,(2) Flash及びPDFのテストファイル,(3) 日本語固有問題の調査用テストファイル,と各テストファイルでの調査方法について説明する.

2.1 UAAG 1.0 Test Suite

W3C WAIのUAAG (User Agent Accessibility Guidelines) Working Groupは,ユーザエージェントがUser Agent Accessibility Guidelines 1.0に適合しているのかどうかを客観的に調べられるよう,W3C WAI Test Suitesと名付けたテストファイル群を用意している.この中のUAAG 1.0 Test Suite for HTML 4.01は,UAAG 1.0のHTML 4.01に関した部分をテストするためのテストファイルで,全部で400種類ある.テストスーツにはチェックポイントごとにテストが用意されている(一部テストが用意されていないものもある).各テストページの構成は,「手順,テスト,ソースコード,結果」となっている.手順に従ってテストを実行し,その結果がテストスーツに書いてある結果と一致するかどうかを見て評価するわけである.テストスーツには、テストを行う際に参考になるよう,テストのソースコードも記載されている.

UAAG 1.0 Test Suite for HTML 4.01(以下,UAAG Test Suitesと略す)の中にテストファイルが正しく作成されておらず,テストが実行できないものがあった.そこで,修正できるものは修正し,その上でテストを実行した.また,用意されているテストファイルでは,本当にテストに合格しているかどうか曖昧なものもあったので,そうしたテストファイルも修正した.修正したテストファイルは,我々のサイトで公開した.

調査にあたっては,まず,テストファイルごとにテストを実施し,次に,そのテスト結果をUAAG 1.0のチェックポイントごとにまとめた.チェックポイントごとの結果は,チェックポイント内のテスト結果の分布に応じて評価した.テストファイルが用意されていないチェックポイントは,UAAG 1.0の文書をもとに判断した.評価結果のカテゴリーは,原則として,UAAG Test Suitesの評価カテゴリーを踏襲した.意図が曖昧なテストファイルは,調査メンバーで意見交換をして,できるだけ同じ判断となるようにした.

2.2 FlashとPDFの調査

今日では,Flashを使用して動的なウェブサイトを作成したり,PDFを使用して文書を提供したりするサイトが少なくない.そこで本調査では,Flash及びPDFも調査した.テストファイルとして,アクセシビリティに配慮して作成された富士通株式会社のFlashページと,Adobe Systems社がウェブで公開しているアクセシビリティに配慮して作成されたPDFテストファイルを用いた.

調査にあたっては,テストファイルで調査できる機能を表にし,その表の項目を満たしているかどうかを調べた.

2.3 日本語固有問題の調査

UAAG 1.0は日本語固有の問題を取り上げていないので,UAAG 1.0 Test Suiteでは,JIS X 8341-3が取り上げているような日本語固有の問題(縦書きやルビなど)にユーザエージェントがどう対応しているかをテストできない.そこで,JIS X 8341-3からユーザエージェント調査に必要と思われる問題を抽出し,日本語テストファイルを独自に作成した.

調査にあたっては,日本語固有の問題点ごとに,テストファイルを用いてテストファイルをどう読み上げるかを調査した.

日本語のテストファイルは,ユーザエージェントの機能をテストするというより,どう読むかを調べることを目的としている.(つまり,読めなくても構わない場合もある.)また,日本のユーザエージェントは,記号を読む読まないなど,多様な読み上げモードを持っているが,明記した以外は,デフォルトの読み上げモード(行読みモード)でテストした.

2.4 調査結果のまとめ

調査対象としたユーザエージェントごとに以上のテストを行い,その結果をまとめたのが,本報告書である.調査にあたっては,特に明示した場合以外は,ユーザエージェントのdefault設定で調査した.

目次に戻る

3. 調査対象

本調査では,日本の視覚障害者用ウェブ利用ソフトを総括してユーザエージェントと考える.アプリケーションの一つとしてウェブブラウザを利用できるスクリーンリーダも,音声化された独自のウェブブラウザも,視覚障害を持つ利用者から見るとウェブを利用できるソフトである.スクリーンリーダの場合は,スクリーンリーダとウェブブラウザを合わせた機能を対象とする.

本調査では,国立特殊教育総合研究所の「視覚障害者のWindowsパソコン及びインターネット利用状況調査2002」(表1)を参考にして,日本の視覚障害者の利用数が多いユーザエージェント3点と,もっとも高機能なユーザエージェントであるJAWSを調査対象とした.

表1.視覚障害者のインターネット音声化ソフト利用状況 (出典: 『視覚障害者のWindowsパソコン及びインターネット利用状況調査2002』)
音声化ソフトの種類 製品 利用者数
インターネット音声化ソフト HPR 55
VE2000 16
ボイスサーフィン 8
スクリーンリーダ PC-Talker 29
95 Reader 19
VDM100W-PC-Talker 15
JAWS 3
outSPOKEN 2

最新バージョンを調査するために,以下を対象とした.ホームページ・リーダーに関しては,調査期間中(2005年7月~2005年10月)に新しいバージョンが発売されたため,バージョン3.02と3.04の両方を調査した.

目次に戻る

4. ユーザエージェント毎の調査結果

ユーザエージェント毎の調査結果を,各テスターの調査報告を基に以下にまとめる.各テスターが調査した詳細な結果は資料(資料B,C,D,E)を参照されたい.また,UAAGワーキンググループの調査結果と比較するために,ユーザエージェント毎の調査結果の概要をUAAG WGと同じ書式で個々の資料にし,「本調査の調査結果概要」からリンクを張った.

4.1 HPR 3.02

4.1.1 UAAG 1.0 Test Suiteの調査結果

HPR 3.02では、UAAG 1.0で要求されているチェックポイントののうち下記に挙げた項目ができなかった。

各チェックポイントの詳細結果は、HPR 3.02のTest Suites調査結果概要に示す。(より詳細な結果は資料Bを参照)

4.1.2 PDFとFlashの調査結果

ホームページ・リーダー3.02では、Flash及びPDFを読み上げることはできない.

4.1.3 日本語固有問題の調査結果 

いくつかの記号や、一部が修飾された単語、lang属性で指定された箇所、abbr要素を正しく読み上げることができなかった。日時も斜線などの記号を用いて記述された場合は、日時として正しく読み上げることはできなかった。半角カナ、ひらがなとカタカナを区別して読み上げることもしなかった。

詳細結果については、HPR 3.02の日本語固有問題調査結果概要に示す。(より詳細な結果は資料Eを参照)

4.2 HPR 3.04 SP3

4.2.1 UAAG 1.0 Test Suiteの調査結果

HPR 3.02と比較すると、accesskeyの操作、イベントハンドラの操作、ツールバーのカスタマイズなどの点で大きな改善が見られ、UAAG 1.0を意識した開発が進められていることがわかる。尚、HPR 3.04でできなかった項目は下記に示す通り。

各チェックポイントの詳細結果は、HPR 3.04のTest Suites調査結果概要に示す。(より詳細な結果は資料Bを参照)

4.2.2 PDFとFlashの調査結果

HPR 3.04でPDF文書とFlashオブジェクトの読み上げが可能になったが、それぞれ基本的な機能として不十分な点が多かった。

詳細結果については、 資料C及び資料Dとして別ファイルにまとめてある。

4.2.3 日本語固有問題の調査結果

HPR 3.02と比較すると、(1)著作権や登録商標を表す記号の読み方、(2)ルビの読み上げ設定、(3)abbr要素を読み上げるという3点ができるようになった。

詳細結果については、HPR 3.04の日本語固有問題調査結果概要に示す。(より詳細な結果は資料Eを参照)

4.3 PC-Talker XP Version1.14

4.3.1 UAAG 1.0 Test Suiteの調査結果

PC-Talker XP で実装されていなかった主な項目は以下の通り。

各チェックポイントの詳細結果は、PC-TalkerのTest Suites調査結果概要に示す。(より詳細な結果は資料Bを参照)

4.3.2 PDFとFlashの調査結果

PDF

本文のテキストに関しては問題なく読み上げたが,画像の代替テキストを読み上げることができず,グラフも表題しか読み上げなかった.また,見出し要素がわかるように読み上げることもできず,タグ付けされている文書構造を用いたナビゲーション機能も実装されていなかった.

詳細結果については、資料Cとして別ファイルにまとめてある。

Flash

制作者がマクロメディアの技術文書(アクセシブルなFlashの制作方法)に従って制作したFlashムービーであれば、音声読み上げ、キーボードのみでの操作、ともに問題なく操作できた。

詳細結果については、資料Dとして別ファイルにまとめてある。

4.3.3 日本語固有問題の調査結果

「なめらか読みの設定」で、句点、括弧、記号をすべて読み上げるように設定すれば、記号文字も読み上げた。ただし、日付(例:「6/20」)や時刻(例:「10:00」)は、記号文字を用いると日付や時刻として読み上げることができなかった。また、曜日(例:「(金)」)もカッコ内の漢字を訓読みで読み上げてしまった。ただし、これらはスクリーンリーダではなく、マークアップ言語などが対処すべき問題である。

詳細結果については、PC-Talker XPの日本語固有問題調査結果概要に示す。(より詳細な結果は資料Eを参照)

4.4 95 Reader Version 6.0

4.4.1 UAAG 1.0 Test Suiteの調査結果

95 Reader 6.0で実装されていなかった主な機能は以下の通り.

各チェックポイントの詳細結果は、95 Reader 6.0のTest Suites調査結果概要に示す。(より詳細な結果は資料Bを参照)

4.4.2 PDFとFlashの調査結果

PDF

表示行の途中に改行が入っていてもつなげて読むのでわかりやすかった.また,画像の代替テキストもグラフの数値も読み上げた.しかし,見出し要素がわかるように読み上げることもできず,タグ付けされている文書構造を用いたナビゲーション機能も実装されていなかった.

詳細結果については、資料Cとして別ファイルにまとめてある。

Flash

制作者がマクロメディアの技術文書(アクセシブルなFlashの制作方法)に従って制作したFlashムービーであれば、音声読み上げ、キーボードのみでの操作、ともに問題なく操作できた。

詳細結果については、資料Dとして別ファイルにまとめてある。

4.4.3 日本語固有問題の調査結果

記号読みをONにしても,句読点などの記号を読み上げなかった.単語内スペースの読み上げでは,CSSで指定した場合のみ正しく読み上げた.記号文字を用いると日付や時刻や金額として読み上げることができなかった。(ただし、これらはスクリーンリーダではなく、マークアップ言語などが対処すべき問題である。)abbr要素もacronym要素にも対応していなかった.ol要素のリスト番号を読み上げなかった.

詳細結果については、XP Reader6.0の日本語固有問題調査結果概要に示す。(より詳細な結果は資料Eを参照)

4.5 JAWS for Windows Professional Version 6.2

4.5.1 UAAG 1.0 Test Suiteの調査結果

JAWS 6.2 は、高度なカスタマイズ機能とJAWSスクリプトによる高い拡張性をもつスクリーンリーダである。したがって、評価するためにはJAWSをどのような設定状態で使用するかによって、結果が異なる。しかし、一般のユーザがJAWSスクリプトを記述して機能を強化することは難しく限界があると考えて、初期状態で目的を達成できるか、またはカスタマイズ機能で設定を変更することによって目的が達成できる場合を C (Complete) とした。 その上で、JAWS 6.2 が対応できなかったのは、以下の機能である。

各チェックポイントの詳細結果は、JAWS 6.2のTest Suites調査結果概要に示す。(より詳細な結果は資料Bを参照)

4.5.2 PDFとFlashの調査結果

PDFおよびFlashの読み上げには対応しているが,PDFで見出し情報などを用いたナビゲーション機能がなく,またFlashではリンクボタンが選択できないといった問題があった.PDFでは画像の代替情報を読み上げない場合があった.

詳細結果については、資料C(PDFの調査結果)と資料D(Flashの調査結果)として別ファイルにまとめてある。

4.5.3 日本語固有問題の調査結果

ほとんど日本語固有の読みの問題はなく、単語間スペース、タグづけなどがある場合でも正しく読み上げることができた。しかしlang属性による言語の切り替えには対応していなかった。JAWS日本語版では、音声読み上げで2ヶ国語の音声合成エンジンを持っているが、これらは手動で切り替える仕組みになっていた。

詳細結果については、JAWS 6.2の日本語固有問題調査結果概要に示す。(より詳細な結果は資料Eを参照)

目次に戻る

5. 調査結果のまとめ

以上の各ユーザエージェントの結果を整理するために,共通してできた機能,共通してできなかった機能,ユーザエージェント間で差があった機能の3種類に分けてまとめる.HPRはバージョン3.04のみを対象とする.

なお,本調査時点で,日本の視覚障害者用ユーザエージェントはInternet Explorerしか読み上げることができなかった.そこで,ユーザエージェントが実装すべき機能というより,Internet Explorer側に責任があると思われる機能は,注釈付きで下記リストに分類した.

5.1 ほとんどのユーザエージェントが共通してできた機能

5.1.1 UAAG 1.0 Test Suites

UAAG 1.0 Test Suitesの調査結果をまとめると,(条件付きながら)ほとんどすべてのユーザエージェントが共通してできた機能は以下の通りである.

5.1.2 PDFとFlash

PDFに関しては,すべてのユーザエージェントができた機能は以下の通りである.

Flashに関しては,すべてのユーザエージェントができた機能は以下の通りである.

HPR 3.04だけが,Flashの読み上げが不十分であった.HPR 3.04以外のユーザエージェントができた機能は以下の通り.

5.1.3 日本語固有問題

日本語固有問題のテストに関しては,特に明記すべき結果はなかった.

5.2 全ユーザエージェントが共通してできなかった機能

5.2.1 UAAG 1.0 Test Suites

UAAG 1.0 Test Suitesでできなかった機能は以下の通り.Test Suitesの不備や曖昧さのため,本当にできていないのかわからない物は除いた.

注1:JAWSは,コンフィグマネージャにページの再読込を停止する機能がある.

5.2.2 PDFとFlash

PDFの読み上げでは,全ユーザエージェントに共通して,以下の問題があった.

Flashの読み上げでは,今回テストした範囲内では,全ユーザエージェントに共通する問題はなかった.

5.2.3 日本語固有問題

日本語固有問題のテストに関しては,ユーザエージェントによらず,以下ができなかった.

5.3 ユーザエージェントによって差があった機能

5.3.1 UAAG 1.0 Test Suites

UAAG 1.0 Test Suitesの調査結果を比較すると,JAWS 6.2及びHPR 3.04は,PC-Talker及び95Readerが対応していない以下の機能を持っていた.

上記以外でも,個々のユーザエージェントによって差がある機能があった.

5.3.2 PDFとFlash

PDFに関しては,

Flashに関しては,HPR 3.04だけが読み上げ能力が劣っていた.

5.3.3 日本語固有問題

日本語固有問題のテストに関しては,以下の通り.

目次に戻る

6. 考察

本調査によって,日本で利用されている代表的な視覚障害者用ユーザエージェントの機能が詳細に調べられ,以下のことがわかった.

6.1 ユーザエージェントの機能差

「5.3.1 UAAG 1.0 Test Suites」で示したように,JAWS 6.2及びHPR 3.04とPC-Talker及び95Readerの間に明確な機能差がある.前者2つ(JAWS 6.2及びHPR 3.04)だけが対応していた機能を再録する:

JIS X 8341-3は, 5.2 a) ウェブコンテンツは,見出し,段落,リストなどの要素を用いて文書の構造を規定しなければならない。5. 2c) 表は,分かりやすい表題を明示し,できる限り単純な構造にして,適切なマーク付けによってその構造を明示しなければならない。 などの項目で,文書の構造を適切にマークアップすることを求めている.しかし,見出し要素やテーブルの構造を示す要素を用いてウェブコンテンツをマークアップしても,ユーザエージェントがそれに対応した機能を提供しなければ,利用者はページの構造を利用できない.この点で,後者に属するユーザエージェントが上記1)や2)の機能を持たないことは,大きな欠点といえる.

また,WCAG 2.0ワーキングドラフトは, Guideline 2.4 Provide mechanisms to help users find content, orient themselves within it, and navigate through it. のように,ナビゲーションを容易にする機能をウェブコンテンツに求めている.しかし,後者に属するユーザエージェントが上記3)と4)の機能を持たないことは,ページ内リンクを使ってナビゲーションスキップや目次を用意しても,利用者は利用できないことを意味する.後者のユーザエージェントでは,望む情報をページ内検索で見つけることもできない.

上記リストの5)以下の機能も,利用者の利便性を向上させる機能であり,後2者のユーザエージェントは,ウェブ・アクセシビリティ向上に不可欠な機能を欠いている.

6.2 機能差の原因

「6.1 ユーザエージェントの機能差」が生じた原因を調べた結果,機能が豊富な後者のユーザエージェントは,Windows OSが提供するMSAA (Microsoft Active Accessibility)以外に,DOM (Document Object Model)を利用してウェブページにインターラクションしていることがわかった.支援技術がWindowsアプリケーションを音声表示する場合,MicrosoftのMSAAを利用してアプリケーションから情報を取得するのがOSとして標準的な方法であるが,ウェブの場合は,DOMを利用することもできる.実際,現在は米国で開発されているHome Page Reader,米国でメジャーなスクリーンリーダであるJAWSやWindow-Eyesは,ウェブの読み上げにDOMを併用している.これに対し,国内で開発され,日本でメジャーなスクリーンリーダであるPC-Talkerや95Readerは,DOMを積極的に使用していないと思われる.

ウェブコンテンツを表現するために使われる(X)HTMLやCSS2は,明確な構造を持っている.DOMを使えば,(X)HTMLデータやスタイルシートの内容を構造化されたまま取得したり,逆にプログラムから(X)HTMLデータやスタイルを操作したりすることもできる.DOMを併用すれば,見出し要素などのデータ構造を利用したナビゲーションや,ページ内リンクやページ内検索にも対応できる. 一方,MSAAは,ウェブページのツリー構造を操作するための特別な機能を持っていないし,ウェブの全構造の情報を取得することも難しい.MSAAだけでは,longdesc属性などを知ることもできない.DOMを併用するよりMSAAだけを利用する方がプログラミングが簡易になるしパフォーマンスも良いので,市場が小さい日本で製品を開発しなければならないメーカがMSAAだけに頼ってプログラミングする事情は理解できなくもない.しかし,(X)HTMLで文書の構造をマークアップし,CSSでプレゼンテーションスタイルを指定するのが現在のウェブ標準であり,前節でも述べたように,ウェブのアクセシビリティにおいても,文書構造を適切にマークアップすることを求めている.したがって,このようなデータ構造を活用することがユーザエージェントに必要である.

日本ではPC-Talkerや95Readerの利用者が多く,この二つと比較して高機能で高価なJAWSの利用者は少ない.PC-Talkerや95Readerの利用者でもウェブ利用時はHPRを併用できるが,国産スクリーンリーダもDOMを活用してウェブページの情報や構造を利用していくことが,日本のウェブ・アクセシビリティ向上には必要である.

6.3 日本のbaseline

「6.1 ユーザエージェントの機能差」から,調査目的 2)で述べた日本のbaselineをどこに定めればよいかがわかる.十分な機能を持たない後者のユーザエージェントを基準にbaselineを考えると,アクセシビリティに配慮して作成されたウェブコンテンツを活用することができない.したがって,日本のbaselineは,前者(JAWS 6.2及びHPR 3.04)のユーザエージェントが共通して持つ機能をベースにして定めるべきである.

6.4 Internet ExplorerとWindows OSが提供すべき機能

「5.2 全ユーザエージェントが共通してできない機能」のうち,ユーザエージェントが対応すべきなのか,Internet ExplorerかWindows OSが対応すべきなのか迷った機能を下記に再録する:

OSやInternet Explorerに欠けている機能の実装をユーザエージェントごとに求めていると,それに対応できないユーザエージェントが生じるので,ウェブのアクセシビリティの向上が遅れてしまう.利用者の特性にかかわらず利便性を向上させると思われるこれらの機能は,OSやInternet Explorerレベルで提供することが必要であると思われる.

6.5 ユーザエージェントに欠けている重要な機能

UAAG 1.0には,チェックポイントごとに優先度が設けられている.

本調査の結果,優先度1のチェックポイント全てを満たすユーザエージェントはないことがわかった.全ユーザエージェントが対応していなかった(評価結果がNI,又はNAかNRのうち重要な物)優先度1のチェックポイントは,以下の通りである.

上記リストを見ると,時間変化やマルチメディアコンテンツの制御に関するチェックポイントが多いことがわかる.つまり,今のユーザエージェント(やInternet Explorer又はOS)には,こうした機能が大きく欠けている.

6.6 UAAG 1.0 Test SuitesとUAAG 1.0の問題

Test Suitesを用いて調査を行った結果,UAAG 1.0 Test Suitesには以下のような問題があることがわかったので,テストファイルの修正点など,これらの問題点をUAAG Working Groupに指摘した.

6.7 ユーザエージェントのUAAGへの適合とUAAGの改善

Catherine K. Lawsが"Presentation-based Web Accessibility Evaluation System: Design and Implementation Challenges and Trade-offs"(Proceedings of HCI International, 2005)で述べているように,IBMはHPRをUAAG 1.0に適合させる努力をしている.しかし前節で述べたように,UAAG 1.0にはわかりにくい記述が多く,テストファイルも不完全である.ウェブアクセシビリティ向上には,すべてのユーザエージェントが一つの標準に準拠することが重要であるので,UAAG自体の改善と,他のユーザエージェントのUAAGへの対応が望まれる.

6.8 日米のユーザエージェントの比較

調査目的 3)で,同じUAAG 1.0 Test Suitesを用いて調査することにより,日米のユーザエージェントの機能を客観的に比較できると述べた.しかし,米国版のHPR 3.04は自動言語検出ができるのに対し日本版ではその機能がないなど,同じHPR 3.04であっても日米で実装に違いがあること,また,UAAGワーキンググループが用意したテスト結果の評価基準が曖昧なため,日米の評価基準が同じであるとは言えず,テスト結果を比較できなかった.

6.9 PDFはどの程度利用できるか

調査の結果,PDFの利用にはかなりの制約があることがわかった.全ユーザエージェントが共通してできたのは,本文と表を上から順に読み上げることだけである.最も結果が良かったJAWSを使っても,見出し要素の区別が付かないし,見出し要素を用いたナビゲーションもできない.PC-Talkerはグラフや画像の代替情報を読み上げることができず,HPR 3.04は見出しを読み上げない.つまり現状では,PDFは(X)HTMLと比較してアクセシビリティが劣っていることがわかる.この事実から,(X)HTMLで提示できる情報は,PDFではなく(X)HTMLで提示すべきであると言える.

6.10 Flashはどの程度利用できるか

調査の結果,HPR 3.04以外のユーザエージェントは,テストした範囲内では,アクセシビリティに配慮して作成されたFlashをよく読むことがわかった.

Flashの機能は膨大であり,今回テストした範囲でFlashが利用できても,Flash自体を100%利用できることは意味しない.また,アクセシビリティに配慮して作成しなければ,Flashを利用することは全くできなくなる.ウェブにインターラクティブ性をもたらすFlashの利用には,こうしたことに注意を払う必要がある.

6.11 コンテンツとユーザエージェントの責任範囲

調査目的 5)で述べた,コンテンツとユーザエージェントの責任範囲の分担も,本調査の結果から定めることができる.UAAG 1.0が要求する機能のうち重要な物を満たすユーザエージェントが日本にも存在することがわかったので,コンテンツ作者はWCAG 2.0及びJIS X 8341-3を考慮してウェブページを作成し,UAAG 1.0準拠を考慮して開発されたユーザエージェントでそのコンテンツを利用することが可能である.コンテンツとユーザエージェントの両方がW3C/WAIが定める標準に準拠することで,ウェブのアクセシビリティが前進する.

目次に戻る

7. まとめ

W3CのUAAGワーキンググループが作成したUAAG 1.0用のテストスーツ,独自に作成した日本語固有問題調査用テストファイル,アクセシビリティに配慮して作成された既存のPDFファイルとFlashファイルを用いて,日本で利用者の多いスクリーンリーダ2種とウェブ音声化ソフト1種,高機能なスクリーンリーダ1種の機能を詳細に調査した.その結果,全体としてみると,UAAG 1.0の優先度1のチェックポイントのうち,マルチメディアの制御に関する機能が足りないことがわかった.個々に見ると,日本の視覚障害者用ユーザエージェントには,MSAAだけを利用してウェブを読み上げるものと,DOMも利用するものの2種類があり,DOMを併用しているスクリーンリーダだけが,ウェブの利用に適した機能を備えていることがわかった.また,スクリーンリーダや音声化ブラウザが備えるべきと言うより,その基となっているInternet ExplorerやWindows OSが標準として備えるべき機能が少なからずあることもわかった.PDFも音声利用できるが,(X)HTMLと比較するとアクセシビリティが劣ることがわかった.アクセシビリティに配慮して作成されたFlashならば,ほとんどのユーザエージェントは,アクセシブルになっている範囲において利用できることもわかった.

W3C/WAIのUAAGワーキンググループが作成したUAAG 1.0 Test Suitesには誤りや曖昧なところが多く,UAAG 1.0自体の曖昧さとともに,テストファイルによる適合性調査が難しい物があった.今後,UAAG 1.0自体の改良とともに,テストファイルの改善も望まれる.

今後のウェブのアクセシビリティ向上を考えると,コンテンツのアクセシビリティの向上と共に,アクセシビリティに配慮して作成されたコンテンツを上手に利用できるユーザエージェントも重要である.W3Cにおいて両者の標準化が行われているので,コンテンツがWCAG 2.0やJIS X 8341-3に準拠して作成され,UAAG 1.0に準拠したユーザエージェントでそのコンテンツが表示される方向に世の中が進んでいく必要がある.そうでないと,良いコンテンツを作っても上手に利用できるユーザエージェントがないとか,良いユーザエージェントがあってもコンテンツにアクセシビリティへの配慮が欠けているのでアクセスできないなど,お互いに足を引っ張り合う状態に陥ってしまう.(たとえば,見出し要素を利用したナビゲーションは視覚障害者だけでなく晴眼者にも便利な機能であるはずだが,見出し要素でナビゲーションできるユーザエージェントが少ないためにその便利さが理解されず,コンテンツも見出し要素でマークアップされない物が多い.Internet Explorerなどのウェブブラウザで見出し要素によるナビゲーションが簡易に行えるようになれば,見出し要素で文書の構造をきちんとマークアップしているコンテンツの利用しやすさが明白になり,見出し要素をきちんとつかったページが増えることが期待できる.)

ウェブの構造を利用できる機能を持ったユーザエージェントを利用していない視覚障害者が日本には少なからずいる.こうした利用者がなぜ高機能なスクリーンリーダを用いないのか,視覚障害者への支援技術の教育がどのように行われているのか,などの調査も,高機能なユーザエージェントの普及に必要である.

今回の調査では,Java (Java applicationとJava applet)やJavaScriptを使ったコンテンツなどは調査しなかった.しかし,Javaは公共サービスにおける電子認証をはじめ今後いろいろなところで利用されていくであろうし,JavaScriptは,静的なウェブページの表示からインターラクティブなアプリケーションインターフェースと変化しつつある次世代Web(Web 2.0)で多用されるので,こうした技術の調査も必要である.

Mozilla Firefox 1.5はDOM利用を含むアクセシビリティ機能を備えており,それに対応したプログラムを書けば,WindowsでもLinuxでもFirefoxを音声利用できる(詳細は「Mozillaアクセシビリティプロジェクト」参照.).現在日本にあるユーザエージェントはInternet Explorerしか読み上げることができないが,JAWS 7.0やWindow-Eyes 5.5などの米国でメジャーなスクリーンリーダの最新バージョンはFirefoxにも対応している.日本でもFirefoxを音声利用できるようになれば,両ブラウザの競争あるいはオープンソース開発の効率性により,より利便性が高いウェブの音声利用が可能になるかも知れない.

目次に戻る

資料

資料A: User Agent Accessibility Guidelines 1.0(英語)

W3C WAI Technical Activityの一グループである User Agent Accessibility Guidelines Working Groupでは、ユーザエージェントの開発者向けにアクセシビリティに配慮するようUAAG1.0を策定しており、2002年12月にW3Cの正式勧告を受けた。UAAG 1.0は、ユーザエージェントの開発者向けに様々な障害を持つ人々にとってアクセス可能なウェブブラウザやメディアプレーヤーなどのソフトウェアの設計方法を説明している。内容は、キーボードのみで操作できることや、読み上げソフトへの対応など多岐にわたる。

User Agent Accessibility Guidelines 1.0のチェックポイントレベルの和訳

資料B: UAAG 1.0 Test Suitesによる調査結果(PDF)

資料C: PDFの調査結果(PDF)

資料D: Flashの調査結果(PDF)

資料E: 日本語固有問題の調査結果(PDF)

目次に戻る

本ページからリンクを張っている重要なページのリスト:

W3C/WAIの関連ガイドライン

本調査で用いたテストファイル


Valid XHTML 1.0 Strict Valid CSS!

Copyright(c) 2005,2006 UA調査プロジェクト

目次に戻る