JP2007140642A - 履歴情報記録装置およびプログラム - Google Patents

Abstract

【課題】ＷＷＷ上にあるコンテンツのアクセシビリティをチェックする際に、従来、チェックする度に、確認要求をしている項目について、一度確認すれば、以降、確認要求をせず、効率的にチェックすることができる履歴情報記録装置およびプログラムを提供することを目的とするものである。
【解決手段】チェックツールを用いて、ウェブページのアクセシビリティをチェックする際に、ユーザが過去に確認したことを示す情報である履歴情報を蓄積し、次回、チェックツールを用いて、同ウェブページをチェックする際に、蓄積されているチェック履歴情報を参考にし、チェック結果を出すことによって、効率的に修正する履歴情報記録装置である。
【選択図】図１

Description

本発明は、チェックツールを用いて、ウェブページのアクセシビリティをチェックする履歴情報記録装置およびプログラムに関する。

情報通信機器の発達によって、近年、インターネットが広く普及されている。これに伴って、インターネットを用いた情報配信が、重要な社会的基幹技術になっている。このために、高齢者や視覚障害者等、様々な特徴を持ったユーザ（ウェブ閲覧者）も、ウェブページをアクセスできることが望まれている。

このような状況下において、ウェブのアクセシビリティが重要視されている。世界的に見れば、Ｗ３Ｃ（World Wide Web Consortium）が、ＷＣＡＧ１．０（Web Content Accessibility Guidelines 1.0）を制定し、国内でも、ＪＩＳ ＸＳ３３４１―３「高齢者・障害者等配慮設計指針―情報通信における機器、ソフトウェア、及びサービス」（以下、「ＪＩＳ」という）が制定された。ウェブページの制作者は、このようなガイドラインに則って、ウェブページを製作すれば、アクセシビリティを向上させることができる。

ウェブページ製作者や、ウェブページ閲覧者が、所定のウェブページのアクセシビリティをチェックする場合、そのページを構成するＨＴＭＬ（Hyper Text Markup Language）規格によって記述されたファイル（以下、「ＨＴＭＬファイル」という）、ＣＳＳと呼ばれるスタイルを記述したファイル（以下、「ＣＳＳファイル」という）等のファイルについて、上記ガイドライン項目を適用し、チェックすればよい。

しかし、一般的に、ＨＴＭＬファイルや、ＣＳＳファイルは、専門知識を必要とし、チェックしなければならないガイドライン項目が非常に多いので、ガイドライン項目を適用し、チェックすることは、容易ではない。そこで、総務省のウェブヘルパー（非特許文献１参照）等のウェブ・アクセシビリティ・チェックツール（以下、「チェックツール」という）と呼ばれるアプリケーションを利用する。

このチェックツールは、ガイドラインに則って、ＨＴＭＬファイルやＣＳＳファイル等をチェックするものである。このチェック結果に従って修正すると、ガイドラインに準拠したウェブページを制作することができる。
情報バリアフリーのための情報提供サイト「みんなのウェブ」（URL：http://www2.nict.go.jp/ts/barrierfree/accessibility/helper/what_webhelper.html)

上記ガイドライン項目の中には、文脈理解、画像理解を必要とする等、チェックツールでは自動的に判断することができない項目が少なくない。

このように、自動的に判断することができない項目について、該当する確認対象要素があれば、上記チェックツールが、その全ての確認対象要素を取り出し、ユーザに確認要求を求める。この場合、ユーザの労力を必要とするが、さらに、既存のチェックツールでは、以前チェックを行ったウェブページについて、毎回、新規にチェックを機械的に行う。したがって、ユーザは、同じ項目を、毎回、確認要求される。よって、同じ確認操作を繰り返す必要があるので、その労働力、コストが無駄であるという問題がある。

たとえば、ユーザに確認を要求する項目として、次のようなものがある。

ＪＩＳのガイドライン項目には、利用者が画像の内容を的確に理解できるように、画像に代替情報を提供しなければならないという項目があり、具体的な対応として、ａｌｔ属性値に、画像の説明を設定することを推奨している。つまり、画像が表示されない場合、その代替として、ａｌｔ属性値に指定されているテキスト情報が表示される。

また、音声ブラウザを用い、音声によって情報を得ている場合、画像を音声化できないので、画像を音声化する代わりに、ａｌｔ属性値に指定したテキスト情報を読み上げることによって、利用者は、その画像の内容を理解することができる。

一方、表示のための飾り画像等、意味を持たない画像や、近くに同等のテキスト情報がある画像等の場合には、ａｌｔ属性値を空白（ａｌｔ＝””）にする必要がある。しかし、既存のチェックツールでは、ａｌｔ属性値に、画像の説明を設定すべきかどうかを自動で判断することができないので、現状では、ａｌｔ属性値が空白であれば、画像の説明が必要であるか否かの判断を、毎回、ユーザに求めている。

上記以外にも、確認を要求する項目として、次のような項目もある。

たとえば、ＪＩＳのガイドライン項目には、ウェブコンテンツは、特定の単一のデバイスによる操作に依存せず、少なくともキーボードによって、全ての操作が可能でなければならないという項目がある。音声ブラウザを利用するユーザの多くは、キーボードのみで操作を行うので、これについての配慮が必要であることを、上記項目が意味する。

スクリプトやアップレット等のプログラムによる確認対象要素は、ボタン等、独自のインタフェースを持つことができるので、入カデバイスに依存することがある。しかし、既存のチェックツールでは、そのプログラムの動作を検証することができない。そこで、現状では、プログラムの確認対象要素であるＯＢＪＥＣＴ要素、ＡＰＰＬＥＴ要素、ＥＭＢＥＤ要素、ＳＣＲＩＰＴ要素等があれば、入カデバイスに依存しているかどうかの確認を、毎回、ユーザに要求する。

上記のように、従来例では、例外なく、毎回、ユーザに確認を要求する項目が少なくなく、ユーザの労力を必要以上に消費するという問題がある。

本発明は、ＷＷＷ上にあるコンテンツのアクセシビリティをチェックする際に、従来、チェックする度に、確認要求をしている項目について、一度確認すれば、以降、確認要求をせず、効率的にチェックすることができる履歴情報記録装置およびプログラムを提供することを目的とするものである。

本発明は、チェックツールを用いて、ウェブページのアクセシビリティ等をチェックする際に、ユーザが過去に確認したことを示す情報である履歴情報を蓄積し、次回、チェックツールを用いて、同ウェブページをチェックする際に、蓄積されているチェック履歴情報を参考にし、チェック結果を出すことによって、効率的に修正する履歴情報記録装置である。

本発明によれば、ＷＷＷ上にあるコンテンツのアクセシビリティをチェックする際に、従来、チェックする度に、確認要求をしている項目について、一度確認すれば、以降、確認要求をしないので、効率的にチェックすることができるという効果を奏する。

また、本発明によれば、効率的なチェックによって、同じ時間内に、従来よりも多くのページをチェックすることができるので、アクセシビリティに配慮されたウェブコンテンツが多くなることが期待され、したがって、視覚障害者等も、より多くのページにアクセスすることができるという効果を奏する。

発明を実施するための最良の形態は、以下の実施例である。

本発明の実施例１は、ＰＣの記憶装置内（以下、「ローカルフォルダ」という）に蓄積されているＨＴＭＬファイルについて、チェックツールを用いて、アクセシビリティのチェックを行う場合、ユーザの確認を必要とするガイドライン項目では、ＨＴＭＬファイル内に記録されている過去のユーザによる判断結果を含む履歴情報を利用し、チェック結果を表示する実施例である。

なお、上記「履歴情報」は、チェックツールを用いて、ウェブページのアクセシビリティ等をチェックする際に、ユーザが過去に確認したことを示す情報である。

すなわち、実施例１は、過去にユーザが確認済みの確認対象要素については、再び確認を求めないようにし、一方、ユーザの確認を新たに求める必要がある確認対象要素については、ユーザに確認内容を指示し、確認を行った場合、キーボードを使用してユーザが「済」を入力する。また、キーボードを使用してユーザが「済」を入力する代わりに、ディスプレイに「確認済」ボタンを表示し、この表示されている「確認済」のボタンを押すようにする。この確認結果を、対象のＨＴＭＬファイル内に履歴情報として追加記録する。なお、チェックした履歴情報を、上記確認対象要素のすぐ後ろに付与する。

実施例１によれば、次回以降のチェックの際に、同じ確認を要求しないので、アクセシビリティ・チェックを効率的に遂行することができ、したがって、ユーザの負担を軽減することができる。

図１は、本発明の実施例１である履歴情報記録装置１００を示すブロック図である。

履歴情報記録装置１００は、制御部１１と、情報入力部１２と、情報出力部１３と、情報取得部１４と、情報処理部１５と、情報蓄積部１６と、情報生成部１７と、情報更新部１８とを有する。

履歴情報記録装置１００を、パーソナルコンピュータ（ＰＣ）で実現する場合、制御部１１、情報取得部１４、情報処理部１５、情報蓄積部１６、情報生成部１７、情報更新部１８は、ＰＣ本体に対応し、情報入力部１２は、キーボード、マウス等の入力装置に対応し、情報出力部１３は、モニタ等に対応する。

情報取得部１４は、ネットワークＮＷを介してウェブサーバＷＳと通信し、ウェブページを取得し、または、ローカルディスクＬＤに蓄積されている内容から、ウェブページを取得する。なお、ローカルディスクＬＤは、ＰＣ内のハードディスクやＣＤ等の記録媒体である。

次に、履歴情報記録装置１００の動作について説明する。つまり、ユーザの確認を必要とするガイドライン項目について、ＨＴＭＬファイル内に記録されている履歴情報を利用し、ＨＴＭＬファイルのアクセシビリティ・チェックを実施し、このときのチェック履歴情報を、新たにＨＴＭＬファイルに付与する過程について説明する。

図２は、履歴情報記録装置１００の動作を示すフローチャートである。

まず、Ｓ１では、情報入力部１２を介して指定されたチェック対象のＨＴＭＬファイルを、ファイル情報取得部１４が取得する。

ここで、履歴情報を持ったＨＴＭＬファイルの例を以下に示す。

＜ｈｔｍｌ＞
＜ｈｅａｄ＞
＜ｔｉｔｌｅ＞テストページ＜／ｔｉｔｌｅ＞
＜／ｈｅａｄ＞
＜ｂｏｄｙ＞
テストページでは、様々なテストを紹介します。＜ｂｒ＞
＜ｉｍｇ ｓｒｃ＝”／ｉｍａｇｅ／ｌｏｇｏ．ｇｉｆ”，ａｌｔ＝”ロゴ”＞＜ｂｒ＞
＜ｉｍｇ ｓｒｃ＝”／ｉｍａｇｅ／ｓｐａｃｅｒ．ｇｉｆ”，ａｌｔ＝””＞＜！−−＃ＣＨＥＣＫ ＩＮＦＯＲＭＡＴＩＯＮ＃ ＯＫ−−＞＜ｂｒ＞
国語のテスト＜ｂｒ＞
＜ｉｍｇ ｓｒｃ＝“／ｉｍａｇｅ／ｄｏ＿ｒｅｄ．ｇｉｆ”，ａｌｔ＝””＞＜！−−＃ＣＨＥＣＫ ＩＮＦＯＲＭＡＴＩＯＮ＃ ＯＫ−−＞
小学校１年生レベル＜ｂｒ＞
１から１０までを漢字で書いてください。＜ｂｒ＞
＜ｓｃｒｉｐｔ＞
……
＜／ｓｃｒｉｐｔ＞
＜ｉｍｇ ｓｒｃ＝”／ｉｍａｇｅ／ｄｏ＿ｇｒｅｅｎ．ｇｉｆ，ａｌｔ＝””＞
小学校３年生レベル＜ｂｒ＞
「よこすか」「かまくら」を漢字で書いてください。＜ｂｒ＞
＜ｓｃｒｉｐｔ＞
……
＜／ｓｃｒｉｐｔ＞＜！−−＃ＣＨＥＣＫ ＩＮＦＯＲＭＡＴＩＯＮ＃ ＯＫ−−＞
＜ｉｍｇ ｓｒｃ＝”／ｉｍａｇｅ／ｄｏｔ＿ｂｌｕｅ．ｇｉｆ，ａｌｔ＝’”’＞
中学校１年生レベル＜ｂｒ＞
「かめ」と読む漢字を３つ書いてください。＜ｂｒ＞
＜ｓｃｒｉｐｔ＞
……
＜／ｓｃｒｉｐｔ＞＜！−−＃ＣＨＥＣＫ ＩＮＦＯＲＭＡＴＩＯＮ＃ ＯＫ−−＞
……
＜／ｂｏｄｙ＞
＜／ｈｔｍｌ＞
ＨＴＭＬファイルでは、＜ｈｔｍｌ＞と＜／ｈｔｍｌ＞とによって囲まれている部分が、表示される部分である。また、＜ｈｅａｄ＞と＜／ｈｅａｄ＞とによって囲まれている部分は、ページのタイトル等を定義する部分である。＜ｂｏｄｙ＞と＜／ｂｏｄｙ＞とによって囲まれている部分が、本文であり、この本文に記述されている内容に沿って、ブラウザ内で表示される。

実施例１で用いる履歴情報は、該当する確認対象要素のすぐ後に付与される。最初に「＜！−−」で始まり、最後は「−−＞」と記述され、「＜！−−」と「−−＞」とによって挟まれている部分がコメントであり、表示されない。

上記「履歴情報」は、チェックツールを用いて、ウェブページのアクセシビリティをユーザが過去にチェックする際に、ユーザによる過去の確認結果を示す情報である。

「＃ＣＨＥＣＫ＿ＩＮＦＯＲＭＡＴＩＯＮ＃」は、実施例１で用いる履歴情報と、普通のコメント文とを区別するための目印である。その後に続く「ＯＫ」は、ユーザが過去に確認済みであることを示す。

＜ｉｍｇ ｓｒｃ＝”／ｉｍａｇｅ／ｓｐａｃｅｒ．ｇｉｆ”，ａｌｔ＝””＞＜１−−＃ＣＨＥＣＫ ＩＮＦＯＲＭＡＴＩＯＮ＃ ＯＫ−−＞では、「＜ｉｍｇ ｓｒｃ＝”／ｉｍａｇｅ／ｓｐａｃｅｒ．ｇｉｆ”，ａｌｔ＝””＞」で示されているｉｍｇ確認対象要素のａｌｔ属性値は、空白であるが、これに続く「＜！−−＃ＣＨＥＣＫ ＩＮＦＯＲＭＡＴＩＯＮ＃ ＯＫ−−＞」は、ユーザに確認済みであることを示す。実施例１では、上記のような書式であるが、ブラウザ表示に影響せず、履歴情報を記録できる書式であれば、どのような書式でもよい。

Ｓ２では、情報処理部１５がチェックを実施する。

次に、実施例１において、情報処理部１５が行うチェック動作の詳細について説明する。

図３は、実施例１において、情報処理部１５のチェック動作の詳細を示すフローチャートである。

まず、Ｓ１１では、チェック対象のＨＴＭＬファイルから、１つ目の確認対象要素を取り出す。続いて、Ｓ１２では、取り出した確認対象要素について、アクセシビリティのチェックを実施する。このチェックの結果、ユーザによる確認が必要な確認対象要素であれば、Ｓ１４で、１つ目の確認対象要素について履歴情報があるかどうかを調べる。履歴情報がなければ、ユーザに確認する必要があるので、確認要求リストに追加する。

このときに、上記確認対象要素を特定するためのファイル内の位置情報として、文字番号と、チェック項目を特定するためのチェック項目番号とを一緒にして、図４に示すように、蓄積する。

図４は、実施例１おいて、チェック結果リストの例を示す図である。

上記Ｓ１２〜Ｓ１５の操作を、全ての確認対象要素について実行する。

次に、Ｓ３では、Ｓ２で得られた確認要求リストに基づいて、ユーザに確認を要求するリストを表示する。

図５は、実施例１において、ユーザ確認要求の表示例を示す図である。

図５における左の列から、順に説明する。まず、図５における「確認内容」は、ユーザに求める具体的な確認の方法である。図５における「対象確認要素」は、ユーザが確認すべき対象の要素である。図５における「文字番号」は、確認すべき確認対象要素の位置（つまり、何文字目かを示す位置）である。この文字番号の代わりに、行番号等、位置を示すものを使用するようにしてもよい。図５における「確認状況」は、ユーザがその確認対象要素を確認したかどうかを示すものであり、ユーザがその確認対象要素を確認した場合、ユーザがキーボードを使用して「済」を入力する。

図５示す表示例には、「済」が表示されているが、ユーザの意思を確認できる入力装置であれば、キーボード以外の入力装置を使用するようにしてもよい。

上記のように、ユーザは、確認内容に従って、確認し、訂正等が必要であれば、訂正した後に、「済」を入力する。

次に、Ｓ４では、Ｓ３で表示した確認要求に対するユーザの確認状況を取得する。Ｓ３で、ユーザが確認した場合、「済」ボタンを押すようにしているので、ここでは、その入力結果を取得すればよい。「済」と入力された確認対象要素のみを、新規履歴情報リストとして蓄積する。

次に、Ｓ５では、Ｓ４で取得した新規履歴情報を、ＨＴＭＬファイル内に付加する。付加する位置は、Ｓ１で示した書式のように、該当する確認対象要素のすぐ後に付加する。同一の確認対象要素に、履歴情報が既に付与されている場合、新規履歴情報に更新することによって、常に最新の履歴情報を保持する。

実施例１によれば、ユーザが過去に行った確認内容を、履歴情報として蓄積するので、蓄積されている確認内容と同じ確認内容をユーザに確認要求する必要がない。したがって、従来、多くの労力を費やしていた確認作業を、実施例１では、効率的に遂行することができる。

本発明の実施例２は、ＰＣの記憶装置内に蓄積されているＨＴＭＬファイルについて、アクセシビリティのチェックを行うときに、実施例１と同様に、ＨＴＭＬファイル内に記録されているチェック履歴情報を利用し、また、これに加えて、チェック履歴情報を、ＨＴＭＬファイルの最後尾にまとめて記録する実施例である。

実施例２によって、ユーザに確認を求めた際におけるユーザの判断結果を、ＨＴＭＬファイルに付与するので、次回以降のチェックの際に、同じ確認を要求しないようにすることができ、効率的にアクセシビリティ・チェックを遂行することができる。

ユーザの確認を必要とするガイドライン項目について、ＨＴＭＬファイル内に記録されている履歴情報（ユーザが過去に判断した結果）を利用し、ＨＴＭＬファイルのアクセシビリティ・チェックを実施し、その時の履歴情報を、新たにＨＴＭＬファイルに付与する過程について説明する。

実施例２である履歴情報記録装置１００の構成は、実施例１における履歴情報記録装置１００の構成と同様である。

図６は、実施例２において、履歴情報記録装置１００の動作を示すフローチャートである。

まず、Ｓ２１では、情報入力部１２を介して指定されたチェック対象のＨＴＭＬファイルを、情報取得部１４が取得する。

次に、Ｓ２２では、取得したＨＴＭＬファイルから、履歴情報（ユーザが過去に判断した結果）を記述した部分を、情報処理部１５が取得する。ここで、ＨＴＭＬファイル内に記述されている履歴情報の例を以下に示す。

＜ｈｔｍｌ＞
＜ｈｅａｄ＞
＜ｔｉｔｌｅ＞テストページ＜／ｔｉｔｌｅ＞
＜／ｈｅａｄ＞
＜ｂｏｄｙ＞
テストページでは、様々なテストを紹介します。

……
＜／ｂｏｄｙ＞
＜／ｈｔｍｌ＞
＜！−−＃ＳＴＡＲＴ＿ＣＨＥＣＫ ＩＮＦＯＲＭＡＴＩＯＮ＃
ｌａｓｔ＿ｕｐｄａｔｅ＝２００５０９０１；
ｃｈｅｃｋ＿ｕｓｅｒ＿ｉｄ＝１６；
ｉｍｇ＆２１３＝ＯＫ；
ｉｍｇ＆２５７＝ＮＧ；
ｉｍｇ＆３７２ニＯＫ；
ｉｍｇ＆７９０＝ＯＫ；
……
ｓｃｒｉｐｔ＆１１３＝ＮＧ；
ｓｃｒｉｐｔ＆４１１＝ＯＫ；
ｓｃｒｉｐｔ＆１２０２＝ＯＫ；
……
ａｐｐｌｅｔ＆２８２＝ＯＫ；
ａｐｐｌｅｔ＆５１３＝ＯＫ；
……
＃ＥＮＤ＿ＣＨＥＣＫ ＩＮＦＯＲＭＡＴＩＯＮ−−＞
ＨＴＭＬファイルでは、＜ｈｔｍｌ＞と＜／ｈｔｍｌ＞とによって囲まれている部分が、表示される部分である。また、＜ｈｅａｄ＞と＜／ｈｅａｄ＞とによって囲まれている部分が、ページのタイトル等を定義する部分である。＜ｂｏｄｙ＞と＜／ｂｏｄｙ＞とによって囲まれている部分が、本文であり、この部分に記述されている内容に沿って、ブラウザ内で表示される。

実施例２で使用する履歴情報を、ＨＴＭＬ文書本体の後ろ（＜／ｈｔｍｌ＞の後ろ）に付与する。最初に「＜！−−」で始まり、最後は「−−＞」と記述しているが、この部分がコメントであり、ブラウザ等は、読み飛ばすので、表示されない。

「ｌａｓｔ＿ｕｐｄａｔｅ＝２００５０９０１」は、最終更新日である。「ｃｈｅｃｋ＿ｕｓｅｒ＿ｉｄ＝１６」は、チェックしたユーザを識別する。これによって、自分以外の履歴情報を、適用しないようにすることができ、また、ある特定のユーザの履歴情報のみを適用することができる。次行以降が、各確認対象要素に対する履歴情報である。

次に、「ｉｍｇ＆２１３＝ＯＫ」を例にして、書式について説明する。

「＝」の左側（例では、「ｉｍｇ＆２１３」）が、対象であり、右側（例では、「ＯＫ」））が、その値（以下、「ユーザ判断値」と呼ぶ）を示す。

さらに、対象確認要素において、「＆」の左側（例では、「ｉｍｇ」）は、ＨＴＭＬ規格の確認対象要素名であり、右側（例では、「２１３」）は、ファイル内でその確認対象要素が現れる文字番号である。つまり、「ｉｍｇ＆２１３」は、「２１３文字目に記述しているｉｍｇ確認対象要素」である。

ユーザ判断値は、ユーザに確認を要求した際の回答結果を示すものであり、「ＯＫ」は、ユーザが正しいと判断した結果を示す。

以上をまとめると、「ｉｍｇ＆２１３＝ＯＫ」は、「２１３文字目に記述しているｉｍｇ確認対象要素について、ユーザは可であると判断したこと」を示す。また、「ｓｃｒｉｐｔ＆１３３＝ＮＧ」は、「１１３文字目に記述しているｓｃｒｉｐｔ確認対象要素について、ユーザは不可であると判断したこと」を示す。これらと同様に、他の確認対象要素についても、列挙して記述されている。

次に、Ｓ２３では、情報処理部１５が、対象のＨＴＭＬファイルについて、アクセシビリティをチェックする。基本的に、アクセシビリティ・ガイドラインの各項目は、各確認対象要素別に書かれていることが多く、チェックツールでは、ガイドラインで指定されたチェック対象（確認対象）である確認対象要素について、チェックする。このときに、チェックツールでは、自動的に判定できないので、ユーザに確認する必要がある確認対象要素について、チェック結果として得る。

図７は、実施例２において、チェック結果リストの例を示す図である。

チェック項目番号、対象確認要素、文字番号を、図７に示すように、まとめて、チェック結果リストとして蓄積する。

次に、Ｓ２４では、履歴情報をリスト化した履歴情報リストに基づいて、出力用チェック結果情報を生成する。

次に、実施例２において、出力用チェック結果情報を生成する詳細な処理について説明する。

実施例３２である履歴情報記録装置１００の構成は、実施例１における履歴情報記録装置１００の構成と同様である。

図８は、実施例２において、情報処理部１５が、出力用チェック結果情報を生成する詳細な処理を示すフローチャートである。

Ｓ３１では、チェック結果リストの１つ目の確認対象要素を読み出す。Ｓ３２では、読み出した確認対象要素と同じ確認対象要素が、履歴情報リストにあるかどうかを調べる。読み出した確認対象要素と同じ確認対象要素が、履歴情報リストになければ、履歴情報リストにない確認対象要素を、出力用結果情報リストに追加する。この操作を、チェック結果リストの確認対象要素の全てについて実行する。これによって、履歴情報リストにないチェック結果のみが、出力用結果情報リストに含まれる。

次に、Ｓ２５では、Ｓ２４で得た出力用結果情報リストに基づいて、ユーザヘ表示する。

図９は、実施例２において、ユーザに行う確認要求であるユーザ確認要求の表示例を示す図である。

図９における左の列から順に説明する。「確認内容」は、ユーザに求める具体的な確認の内容である。「対象確認要素」は、ユーザが確認すべき対象の要素である。「文字番号」は、対象確認要素の位置（対象確認要素が何文字目に存在しているかを示す位置）である。上記文字番号の代わりに、行番号等、対象確認要素が存在している位置を示す他のものを使用するようにしてもよい。

図９に示す「確認結果」は、ユーザがその確認対象要素を確認した結果を示すものである。つまり、確認内容に適合していれば、「可」を、ユーザがキーボードで入力し、確認内容に適合していなければ、「不可」を、ユーザがキーボード入力する。この場合、キーボードの代わりに、ユーザの意思を取得できる入力手段であれば、キーボード以外の手段を使用するようにしてもよい。

Ｓ２６では、Ｓ２５で表示した確認要求に対するユーザの確認結果を取得する。Ｓ２５では、確認結果は、「可」、「不可」のいずれかを入力するので、この入力結果を取得すればよい。その後に、この取得した入力結果を、新規履歴情報リストに蓄積する。

Ｓ２７では、Ｓ２２で得た履歴情報リストのデータと、Ｓ２６で得られた新規履歴情報リストとを合わせて、記録用履歴情報リストを生成する。この場合、同一確認対象要素が、上記履歴情報リストと上記新規履歴情報リストとの両者に存在していれば、新規履歴情報リストに含まれている確認対象要素の情報のみを用いて、上記記録用履歴情報リストを生成する。これによって、上記記録用履歴情報リストに記録されている履歴は、最も直近の情報である。

Ｓ２８では、Ｓ２７で得た記録用履歴情報リストに基づいて、Ｓ２２で説明した書式を生成し、ＨＴＭＬファイルに付加する。これによって、次回、このＨＴＭＬファイルをチェックする場合、今回新たに追加した履歴情報も反映され、チェックが行われる。

実施例２によれば、ユーザが過去に行った確認内容を、チェック履歴として蓄積するので、ユーザには、同じ確認内容を要求することがない。これによって、従来、多くの労力を費やしていた確認作業を、実施例２では、効率的に遂行することができる。

本発明の実施例３は、インターネットのウェブサーバＷＳ上にあるウェブページについて、実施例１と同様にアクセシビリティ・チェックを実施する実施例である。

実施例３は、ウェブサーバＷＳ上にあるウェブページでは、そのページの製作者や管理者等に許可なく、そのページを構成するファイル内に、履歴情報を記録することが不可能であるので、自ＰＣ内に、自由に書き換え可能なファイル等を別に用意し、この別に用意されたファイルに、履歴情報を蓄積する実施例である。なお、自由に読み書きが可能な記録形態であれば、ファイル以外の記録形態を、ファイルの代わりに使用するようにしてもよい。

実施例３によれば、ウェブ上に公開されているウェブページについても、効率的にチェックすることができる。

次に、インターネット上のウェブページについて、自ＰＣ内に記録したチェック履歴情報を利用して、アクセシビリティをチェックする動作について説明する。

実施例３である履歴情報記録装置１００の構成は、実施例１における履歴情報記録装置１００の構成と同様である。

図１０は、実施例３において、履歴情報記録装置の動作を示すフローチャートである。

Ｓ４１では、情報入力部１２を介して指定されたアドレスに基づいて、チェック対象であるＨＴＭＬファイルを取得する。

Ｓ４２では、自ＰＣ内に蓄積した履歴情報群から、Ｓ４１で指定されたＨＴＭＬファイルを、情報処理部１５が取得し、履歴情報リストとして、記憶装置に蓄積する。

次に、Ｓ４３〜Ｓ４７では、実施例２と同様に、チェック対象であるＨＴＭＬファイルのアクセシビリティをチェックし、このアクセスビリティをチェックした結果のリストであるチェック結果リスト、上記履歴情報リストに基づいて、出力用チェック結果情報を生成し、記憶装置に記憶し、ユーザヘの確認要求リストを表示する。これに対するユーザの確認結果を加えて、記録用履歴情報リストを取得する。

最後に、Ｓ４８では、Ｓ４７で得た記録用履歴情報リストに、それぞれチェックしたページのアドレスを付加し、自ＰＣ内の履歴情報郡に追加記録する。これによって、次回、このＨＴＭＬファイルをチェックする場合、今回新たに追加した履歴情報を反映して、チェックされる。

実施例３によれば、過去にユーザが行った確認内容を、チェック履歴として蓄積しているので、同じ確認内容をユーザに要求しない。これによって、従来、多くの労力を費やしていた確認作業を、実施例３では効率的に遂行することができる。

すなわち、ＨＴＭＬがガイドラインに沿っているかどうかを検査する従来のソフトウェアを使用しても、どうしても人間が介在（判断）せざるを得ない判定箇所があり、上記実施例では、このような判定箇所について、過去に人間が判定した結果を記憶し、以降は、その判定結果を活用するので、毎回人間が検査することを省略することができる。

つまり、上記実施例は、チェックツールを用いて、ウェブページのアクセシビリティをチェックする際に、ユーザが過去に確認したことを示す情報である履歴情報を蓄積する履歴情報蓄積手段と、上記チェックツールを用いて、上記ウェブページをチェックする際に、上記蓄積されているチェック履歴情報を参考にし、チェック結果を生成するチェック結果生成手段と、上記生成されたチェック結果を出力するチェック結果出力手段とを有する履歴情報記録装置の例である。

この場合、上記履歴情報取得手段は、所定のコンテンツから、上記履歴情報を取得する手段である。また、上記履歴情報取得手段は、コンテンツとは別に記録された履歴情報群から、コンテンツに一致する履歴情報のみを取得する手段である。

さらに、上記結果生成手段は、上記評価情報の中で、上記履歴情報にはない要素を含む結果情報を生成する手段である。そして、上記判断情報取得手段は、上記結果情報に対する使用者の判断を取得する手段である。

なお、上記実施例をプログラムの発明として把握することができる。つまり、上記実施例は、チェックツールを用いて、ウェブページのアクセシビリティをチェックする際に、ユーザが過去に確認したことを示す情報である履歴情報を蓄積し、記憶装置に記憶する履歴情報蓄積手順と、上記チェックツールを用いて、上記ウェブページをチェックする際に、上記蓄積されているチェック履歴情報を参考にし、チェック結果を生成し、記憶装置に記憶するチェック結果生成手順と、上記生成されたチェック結果を出力し、記憶装置に記憶するチェック結果出力手順とをコンピュータに実行させるプログラムの例である。

本発明の実施例１である履歴情報記録装置１００を示すブロック図である。 履歴情報記録装置１００の動作を示すフローチャートである。 実施例１において、情報処理部１５のチェック動作の詳細を示すフローチャートである。 実施例１おいて、チェック結果リストの例を示す図である。 実施例１において、ユーザ確認要求の表示例を示す図である。 実施例２において、履歴情報記録装置１００の動作を示すフローチャートである。 実施例２において、チェック結果リストの例を示す図である。 実施例２において、情報処理部１５が、出力用チェック結果情報を生成する詳細な処理を示すフローチャートである。 実施例２において、ユーザに行う確認要求であるユーザ確認要求の表示例を示す図である。 実施例３において、履歴情報記録装置の動作を示すフローチャートである。

符号の説明

１００…履歴情報記録装置、
１１…制御部、
１２…情報入力部、
１３…情報出力部、
１４…情報取得部、
１５…情報勝利部、
１６…情報蓄積部、
１７…情報生成部、
１８…情報更新部。

Claims (6)

1. チェックツールを用いて、ウェブページのアクセシビリティをチェックする際に、ユーザが過去に確認したことを示す情報である履歴情報を蓄積する履歴情報蓄積手段と；
   上記チェックツールを用いて、上記ウェブページをチェックする際に、上記蓄積されているチェック履歴情報を参考にし、チェック結果を生成するチェック結果生成手段と；
   上記生成されたチェック結果を出力するチェック結果出力手段と；
   を有することを特徴とする履歴情報記録装置。
2. 請求項１において、
   上記履歴情報取得手段は、所定のコンテンツから、上記履歴情報を取得する手段であることを特徴とする履歴情報記録装置。
3. 請求項１において、
   上記履歴情報取得手段は、コンテンツとは別に記録された履歴情報群から、コンテンツに一致する履歴情報のみを取得する手段であることを特徴とする履歴情報記録装置。
4. 請求項１において、
   上記結果生成手段は、上記評価情報の中で、上記履歴情報にはない要素を含む結果情報を生成する手段であることを特徴とする履歴情報記録装置。
5. 請求項１において、
   上記判断情報取得手段は、上記結果情報に対する使用者の判断を取得する手段であることを特徴とする履歴情報記録装置。
6. チェックツールを用いて、ウェブページのアクセシビリティをチェックする際に、ユーザが過去に確認したことを示す情報である履歴情報を蓄積し、記憶装置に記憶する履歴情報蓄積手順と；
   上記チェックツールを用いて、上記ウェブページをチェックする際に、上記蓄積されているチェック履歴情報を参考にし、チェック結果を生成し、記憶装置に記憶するチェック結果生成手順と；
   上記生成されたチェック結果を出力し、記憶装置に記憶するチェック結果出力手順と；
   をコンピュータに実行させるプログラム。

Images