JP2005292901A

JP2005292901A - ウェブブラウザのアクセシビリティ検査プログラム

Info

Publication number: JP2005292901A
Application number: JP2004102833A
Authority: JP
Inventors: Masaya Ando; 昌也安藤
Original assignee: WEB STYLE KENKYUSHO KK
Current assignee: WEB STYLE KENKYUSHO KK
Priority date: 2004-03-31
Filing date: 2004-03-31
Publication date: 2005-10-20
Anticipated expiration: 2024-03-31
Also published as: JP4448724B2

Abstract

【課題】従来のアクセシビリティ検査プログラムでは、不完全であったり文法に誤りがあったりするHTMLソースプログラムを直接解析していたので、ウェブに対するアクセシビリティを必ずしも正しく検査できない。
【解決手段】HTMLソースプログラムをコンピュータに読み込むステップ、前記読み込んだHTMLソースプログラムを解釈するステップ、前記解釈に基づき当該解釈結果をコンピュータの出力装置に整合するDOMによる中間命令に変換するステップを有するウェブブラウザソフトウエアにおいて、前記DOMによる中間命令を対象としてアクセシビリティの検査を行う。これによりウェブ閲覧者が使用しているシステム構成に対応した情報出力状態に対して検査を行うことができ、したがって効率よくかつ的確にアクセシビリティを検査することができる。
【選択図】図２

Description

本発明は、高齢者や視覚障害者（以下「高齢者等」という。）がインターネットを通じて提供されるウェブコンテンツに容易にアクセスできるように、HTMLで記述されたウェブページ情報のアクセシビリティもしくは情報伝達度の適否を検査し、その結果を出力する機能を備えた検査プログラムに関する。

内閣設置の情報技術戦略会議（いわゆるIT戦略会議）において提示された「インターネットにおけるアクセシブルなウェブコンテンツの作成方法に関する指針」（平成12年11月）では、「ウェブのコンテンツ制作者（ページの作成者、ページデザイナー）及び作成ツールの開発者向けに、バリアフリーなウェブコンテンツを作成する方法を提示し、障害のある人がインターネットのウェブへ容易にアクセスできるようにすること」を目的として、ウェブ閲覧者の情報アクセシビリティを向上させるための14項にわたるガイドラインを提示している。

例えばその第1項には「音声や画像で表示されるコンテンツには代替手段を提供すること」が掲げられており、これをより具体的に実現する手法として、
・画像で提供されている情報には、alt属性で適切な代替テキストを用意すること。
・画像で提供されるリンクには、alt属性でリンク先が分かるような代替テキストを用意すること。
等々が挙げられている。これらは14項の全体では数十項目以上が具体的指針として示されている。

これに対して、非特許文献１に示したようなアクセシビリティ検査のためのソフトウエアが開発されている。これは、W3C(World Wide Web Consortium)が提唱するWCAG(the Web Contents Accessibility Guideline)に基づき、これを日本語（2バイト文字コード）を含むHTMLソースプログラムに最適化したうえで、前記のような指針の内容に準拠した記述となっているか否かを100項目以上にわたって検査しうるようにしたものである。
内田斉、外6名、"RESEARCH AND IMPROVING WEB ACCESSIBILITY IN JAPAN"、[online]、2002年1月21日、アライド・ブレインズ株式会社、[平成16年3月15日検索]、インターネット＜URL: http://www.a-brain.com/HP/rep/rep10/contents.html＞

従来のアクセシビリティ検査プログラムでは、HTMLで記述されたソースプログラムを直接解析している。このため不完全であったり文法に誤りがあったりするHTMLソースプログラムは必ずしも正しく検査できないという問題がある。すなわち、一般にHTMLソースプログラムは文法的な曖昧さや誤りを多く含んでおり、同じ表現をするにも複数の記述方法があることも多い。このため、HTMLソースプログラムを対象にアクセシビリティを検査しようとすると、しばしばこれらの曖昧さや文法的誤りが障害となり、正確な検査を行えないのである。

本発明は、HTMLソースプログラムを解釈しユーザが認識可能な形式に変換してコンピュータの出力装置に出力させるウェブブラウザソフトウエアの仕組みに着目して、高齢者等に対するアクセシビリティをより的確に検査できるようにした検査プログラムを提供することを目的としている。

本発明は、インターネット等を通じて提供されるHTMLソースプログラムをコンピュータに読み込むステップ、前記読み込んだHTMLソースプログラムを解釈するステップ、前記解釈に基づき当該解釈結果をコンピュータの出力装置に整合する中間命令に変換するステップを有するウェブブラウザソフトウエアを前提として、前記HTMLソースプログラムに基づき出力装置に表示される情報のアクセシビリティを検査するプログラムを構成する。特に本発明が特徴とする点は、HTMLソースプログラムそのものではなく、HTMLソースプログラムをコンピュータの出力装置に整合する中間命令、すなわち出力装置がモニタであれば文字・画像情報として、出力装置がスピーカであれば音声情報として、それぞれウェブブラウザが出力可能な命令形式に変換した結果に対してアクセシビリティを検査するステップを備えたことにある。

なお本明細書において用語「HTML」は、データ処理について拡張されたXMLやウェブページ上でのインタラクティブな表現を可能にするためのDynamic HTMLなど、ウェブブラウザが取り扱うことが可能なタグ命令を主体としたウェブページ出力のためのプログラム言語一般を包含する概念として使用している。また、本明細書で使用する用語であってW3Cが定義する語意または用法が該当するものは、特に断りがない限り当該定義に準拠するものとする。

本発明によれば、モニタやスピーカなどコンピュータに接続された出力装置に実際に出力される内容に相当する命令に対してアクセシビリティの検査を適用し、すなわちHTMLソースプログラムにおける曖昧さや誤りを排除して、ウェブ閲覧者が使用しているシステム構成に対応した情報出力状態に対して検査を行うことができ、したがって効率よくかつ的確にアクセシビリティを検査することができる。

また、従来はコンピュータに読み込んだHTMLソースプログラムに対して検査を実施するようにしていたため、JSP(Java Server Pages)(Javaは登録商標である。）によりHTMLを自動生成するようなウェブページについては検査を行うことができなかった。これに対して本発明によれば前述の通り解釈結果から生成した出力命令に対して検査を行うことになるので、自動生成されたHTMLに対しても検査が可能である。

以下、本発明の実施形態を図面に基づいて説明する。図１は一般的なウェブブラウザソフトウエア（以下「ブラウザ」という。）がHTMLソースプログラムに基づいてコンピュータの出力装置へウェブページの内容を出力する手順の概略を、図2は前記出力処理の過程で検査を行う手順の概略をそれぞれ表した流れ図である。この実施形態では前期検査を一般にブラウザが装備しているDOM(Document Object Model)の機能を利用して実行する例を示している。

図1において、ブラウザはまずHTMLソースプログラムの読み込みを行う(STEP 11)。HTMLソースプログラムは多くの場合はインターネットまたはイントラネット上のサーバから読み込まれるが、ウェブ閲覧者自身のコンピュータ内の記憶装置から読み込まれる場合もある。HTMLソースプログラムにはタグと呼ばれる命令群が記述されており、一般に文字（テキスト情報）についてはHTMLソースプログラム内に記述され、画像や音声の情報についてはその情報が格納されたネットワーク上のアドレスが記述されている。

ブラウザは、次にこれらのタグ命令群を解釈し、ウェブ閲覧者のコンピュータシステム（OSおよびハードウエア）によって出力可能な中間命令群をDOMによって生成する(STEP 12)。

次に、前記DOMによる中間命令に従ってモニタ画面（ブラウザウインドウ）に画像や文字などのウェブコンテンツを表示する(STEP 13)。コンテンツが音声情報である場合はコンピュータに接続された音声出力装置を介して音声を出力させる。

以上がブラウザの動作の概略であるが、次に前記のDOMについて説明する。W3Cの定義によると、DOMとはHTML文書のためのアプリケーション・プログラム・インターフェイス(API)である。DOMは、HTML文書の論理的構造や、これら文書へのアクセスや操作の方法を定義している。すなわち、DOMとはHTMLソースプログラムに記述されている内容を、実際にコンピュータのモニタ画面に表示する「ページ」の部品(＝オブジェクト)に相当する中間命令に翻訳したものと言える。DOMの仕様はW3Cにより標準として提示されているため、Microsoft社のInternet Explorer(以下「MSIE」という。)をはじめとする多くのブラウザに装備されている。ブラウザは、HTMLソースプログラムから直接ページを表示しているのではなく、HTMLソースプログラムをいったんDOMによる前記の中間命令に翻訳してから、DOMを参照してページ表示等の出力を実行している。

この実施形態では前記DOMの機能を利用して、図2に示したような手順で検査を行っている。まず前記DOM（中間命令）を読み込み、次いでDOMの内容に対して予め設定された検査項目の有無を文字列検索等の手法により検索する(STEP 21-STEP 22)。

検査項目が有った場合には、次いで予め用意された検査ルーチンによりアクセシビリティに関する検査基準との整合性を検査し、その結果を出力する(STEP 23-STEP24)。この検査処理を必要な限度で繰り返し実行することでウェブページないしコンテンツに対するアクセシビリティの検査は完了する。検査結果の出力は、例えばテキスト形式などの文書ファイルとして記憶装置に出力するようにしてもよいが、より好ましくは検査結果をHTML化しブラウザを介して新規ウインドウまたはフレーム内に表示させるようにする。これにより、アクセシビリティ検査の対象となるHTML文書を表示させながら、検査結果を容易に検証したり修正したりすることが可能になる。

アクセシビリティの検査項目は既述したように多岐にわたるが、ここでDOMを利用した検査が可能な項目についていくつかを例示すると次の通りである。
文書構造の適切さ
…文書のタイトル、見出し属性
リンク文書の適切さ
…リンク文書（画像、イメージマップの代替テキストを含む）
テーブル構造
…SUMMARY属性、CAPTION属性、TH要素の有無
画像の代替テキスト
…画像とALT属性（代替テキスト）の対応、イメージマップとALT属性の対応
リンクテキスト内の空白
…リンクの文字列の間に空欄（スペース）の有無
フォームのラベル指定
…label要素でフォーム部品とラベルが関連付けられているか
オブジェクトの使用の有無
…動画などのオブジェクトファイルの使用の有無および代替テキストの提供の有無
文書内の強制改行の有無
…文書内で強制改行<BR>要素が試用されているかの有無
ただし、これら検査のためのアルゴリズムそのものは周知であるので詳しい説明は省略する。本発明の要点は該検査処理をDOM等による中間命令に対して適用するようにした点にある。すなわち、前述したようにHTMLソースプログラムは一般に文法的な曖昧さや誤りを多く含んでいて情報伝達度を検査するうえでの障害が多いのに対して、ウェブページの設計図に当たるDOMはオブジェクト構造すなわちページ部品の構成や内容、組み合わせ方等を記述する必要があるため、HTMLソースをDOMに翻訳する手順の中で、必然的にHTMLソースの文法的曖昧さや記述方法の違いを取り除く手順を実行する構成になっている。したがって、DOMを対象としてアクセシビリティの検査を行うと、HTMLソースで問題となる「曖昧さ」や「記述の違い」「小さな文法的誤り」に影響されることなく、ウェブデザイナ等のユーザがコンピュータのモニタ画面で実際に目にするコンテンツの作りに沿った検査を行うことができるのである。

なお、W3Cで定義されているDOMは基本的な思想と構造に関する定義のみであり、実際には各種のブラウザが独自に拡張して実装している。汎用的なアクセシビリティ検査としてはW3Cの定義によるDOM構造のみを対象とし、各種ウェブブラウザソフトウエアが独自拡張している仕様には対応しないのが本来である。しかしながら実際には独自拡張仕様部分まで対応した検査を実施することが簡易な操作でのアクセシビリティの検査や動的なページでの情報伝達度の検査を実現するうえでは望ましい。このため、DOMを対象にアクセシビリティの検査を行う場合、厳密にはブラウザ別に異なる手順・プログラムが必要になる。具体例を挙げると、前記MSIEでは、コンテキストメニューおよびその呼び出し元ウィンドウオブジェクトであるexternal.menuArgumentsオブジェクトはMSIE独自拡張のオブジェクトであるので、それに応じた検査処理を実行することになる。ただし、この場合でもMSIEに限らず、すでに表示されたウィンドウオブジェクトを取得することが可能なオブジェクト持つブラウザであれば、同一論理構造のまま検査処理の移植が可能である。また、処理は多少複雑になるが、独自拡張のオブジェクトをDOM標準のAPIによって代替することも可能である。したがって、DOMを対象としてアクセシビリティの検査を実施することの利点は、ブラウザの種類に関わりなく共通している。

本発明は前記実施形態に限定されるものではなく、発明の要旨を変更しない範囲内で各種の変形例を構成可能であることは言うまでもない。

一般的なウェブブラウザソフトウエアの動作内容の概略を示した流れ図。本発明の一実施形態の動作内容を示した流れ図。

符号の説明

STEP 21 本発明の実施形態によるアクセシビリティ検査処理の第１のステップ
STEP 22 本発明の実施形態によるアクセシビリティ検査処理の第２のステップ
STEP 23 本発明の実施形態によるアクセシビリティ検査処理の第３のステップ
STEP 24 本発明の実施形態によるアクセシビリティ検査処理の第４のステップ

Claims

インターネット等を通じて提供されるHTMLソースプログラムをコンピュータに読み込むステップ、
前記読み込んだHTMLソースプログラムを解釈するステップ、
前記解釈に基づき当該解釈の結果をコンピュータの出力装置に整合する中間命令に変換するステップ、
を有するウェブブラウザソフトウエアを前提として、
前記HTMLソースプログラムに基づき出力装置に表示される情報へのアクセシビリティを検査するプログラムであって、前記中間命令に対して前記アクセシビリティを検査するステップを有することを特徴とするウェブブラウザのアクセシビリティ検査プログラム。
前記アクセシビリティを検査するステップは、前記中間命令をコンピュータの記憶領域に読み込むステップと、この読み込んだ中間命令に対して検査処理を実行するステップとを有している請求項１に記載のウェブブラウザのアクセシビリティ検査プログラム。
前記検査の結果を前記ウェブブラウザソフトウエアを介して出力する請求項１に記載のウェブブラウザのアクセシビリティ検査プログラム。
前記中間命令としてウェブブラウザソフトウエアのDOMによる記述を参照する請求項１に記載のウェブブラウザのアクセシビリティ検査プログラム。