ウェブアクセシビリティ評価ツール

ウェブアクセシビリティをチェックする、いわゆる評価ツールについて紹介。関連して評価ツールを導入する時や使用時の注意点等。

HTMLファイル+cssファイルのウェブアクセシビリティ評価ツール

ウェブアクセシビリティを評価するツールは幾つかあるが、無料でHTMLファイル+cssファイルをチェックできる代表的なソフトウェアとして最初に挙げられるのは、総務省 miChecker(エムアイチェッカー)である。ローカル環境でも、Web上に既に公開されているHTMLファイルでもチェックが可能だ。

正式には、

みんなのアクセシビリティ評価ツール：miChecker (エムアイチェッカー)

という名称で、総務省のページから無料でダウンロードできる。

最初に提供されたバージョンはいくつか問題点があり、例えばUTF-8のBOM付きだとエラーが返されるということがあったが、現在提供中のVer.2ではそこは修正されているようだ。

なお、BOMとはbyte order mark（バイトオーダーマーク）の略で、その詳細な説明やUTF-8のBOM付き・BOM無しの確認方法といったことは、UX MILKさんに詳しい解説があるので、そちらをご覧いただきたい。

UTF-8のBOM付き・BOM無しの違いと確認方法 UX MILK

使用しているオーサリングツールによってはBOM付きなのかそうじゃないのか確認できない、或いはしづらいものもあり、旧バージョンのmiCheckerを使っていてエラーの原因が探し出せない場合は、このBOMの有無の可能性も無きにしも非ず。miCheckerのバージョンをあげ、また別のオーサリングツールで試してみることをお勧めする。
(古いバージョンをいつまでも使っているなんてあるのか?と思う方もおられるだろうが、組織全体の方針やセキュリティ、他のソフトウェアとの兼ね合いといった諸々の理由で、担当部署では容易にバージョンアップできなかったり新たなソフトを入れられなかったりという話は多い。これに限らず、ユーザーが常に最新の環境が整えられる状態ではない、ということは念頭に置くべきだ。)

Windowsのメモ帳でHTMLファイルは開かないこと

ついでと言っては何だが、HTMLファイルを確認修正する際の注意がある。
先に紹介したUX MILKさんの記事中にもある通り、Windowsに標準装備のメモ帳でHTMLファイルを開くと、もともとBOM無しであったファイルであってもBOM有りとして保存されてしまう。例えば無料のTeraPadやサクラエディタといったリッチテキストエディタであれば、BOM付き・BOM無しファイルに設定・保存可能である。
高価なオーサリングツールではなくとも対応可能なので、メモ帳でHTMLファイルを開くのはやめるべきだ。

特に最近は省力化やテンプレートの活用、また特にWebの知識がない担当者であっても更新作業ができるよう、CMSでWebサイトの運用をしていることが多い。職場の業務用のPC、官公庁や地方自治体であれば行政端末に、最低限のソフトウェアしか入っていないこともあるだろう。CMSを使っているとHTMLファイルを触る機会が少ないだけに、やらざるを得ない状態になると意識せずメモ帳で開きがちである。

ちなみにメモ帳でHTMLファイルを開いただけでBOM付きだったファイルがBOM付きになってしまう。やってしまった時はリッチテキストエディタでBOM無しに修正することが可能だ。またBOM付きが大量にありそうであれば、1つ1つ修正しなくてもWebサーバーの運営管理事業者が対応可能な場合もある。(そもそもの文字コード（符号化方式）がどのようになっているか仕様書等で確認のうえ、運営管理事業者に問い合わせてみてください。)

ウェブアクセシビリティ評価ツールの最低要求仕様

評価ツールについて話を戻す。

事業者によっては自社の評価ツールを勧めたり、或いはCMSにチェックツールが付属しています、といった説明がされることもあるだろう。

ウェブアクセシビリティ評価ツールの最低要求仕様があるということはご存じだろうか。ウェブアクセシビリティ基盤委員会のページ

ウェブアクセシビリティ評価ツールの最低要求仕様 2012年11月版

では、JIS X 8341-3:2010の達成基準に基づいたウェブアクセシビリティ評価のベースラインを揃えることを目的に、HTMLを解析し評価するツールの開発者に対して、実装すべき最低限の仕様を示している。対応していないチェックツールでいくらチェックしても意味をなさない。確認が必要だ。

株式会社インフォアクシア*1が運営している、「エー イレブン ワイ」*2では、各種チェックツールを紹介している。
HTMLファイル+cssファイルのためのウェブアクセシビリティ評価ツール以外にも、色のコントラストや色覚特性シミュレーション、ハイコントラスト表示、アクセシビリティAPIを紹介している。2018年4月20日時点で、PDFファイルのアクセシビリティチェックツールについて記載はないようなので(他のページにあったら見落としです、すいません)、以下記載する。

PDFファイルのアクセシビリティチェックツ—ル

PDFファイルについても、導入時には前述の最低要求仕様を満たしたチェックツールであることを前提とすべきだが、例えば以下のものがあげられる。

Adobe Acrobat DC Pro
完全チェックツールを使用すると、文書が PDF／UA や WCAG 2.0 などのアクセシビリティ規格に準拠しているかどうかを検証できる。
また日本語であること、ローカル環境でチェックできること、何といっても Adobe Systems 社によって開発された、電子文書のためのフォーマットがPDFであり、アクセシビリティについてかねてより取り組んでいてその蓄積されたノウハウがあり使いやすい。

Adobe Acrobatのアクセシビリティ機能については、以下ご参照。

アクセシビリティ機能はありますか （Acrobat DC）-Adobe Systems 社

ただし、miCheckerのように、どこの部分がJISのどこに抵触するかといった指摘はない。またmiCheckerを含めた全てのツールに共通して言えることだが、機械的にアクセシビリティチェックを全てし終えることはできない。必ず目視など手動によるチェックが必要である。
(なので、ついでに言っちゃうと機械的にチェックして評価できました!と事業者が言ったとしても、それは完全ではない可能性がある。というか、かなりの確率でできていないので、アクセシビリティチェックを外部業者に委託する場合は仕様書にしっかり盛り込むなど要注意)

上記以外では、英語であるが以下のようなツールもある。

Free PDF Accessibility Checker (PAC 3)

Commonlook™ PDF

なお、PDFファイルのアクセシビリティチェックツールについては、使用方法も含めて別に機を設けたい。

(了)

*1 株式会社インフォアクシアはウェブアクセシビリティ基盤委員会の現委員長である植木真氏が代表をつとめておられ、何といっても第一人者ですので、発信される情報は信頼のおけるものです。

*2 a11yとはアクセシビリティのスペル「accessibility」の略です。a で始まり y で終わる間に11文字あることからきているそうです。というわけで僭越ながら私もこのnoteでa11yとしている次第。

(ヘッダー写真 撮影地 ニュージーランド Tekapo©moya)