Webアクセシビリティ・チェックツールとWebアクセシビリティに関するアレコレ
Webアクセシビリティの規格「JIS X 8341-3」やガイドライン「WCAG」のチェックツールについて、いくつか紹介します。
チェックツールを用いてチェックできるアクセシビリティ項目は限られており、最終的に多くの項目で目視チェックが必要になるのは前提ですが、いろいろなツールを用いて相補的にチェックすることで効率的に検証を行うことはできますね。
miChecker
総務省が配布している「miChecker」は、昔からあるアクセシビリティチェックツールですね。2023年3月にリリースされたVer.3で内部的に使われているブラウザがInternet ExplorerからMicrosoft Edgeに変更になっています。
ZIPファイルを解凍すると「2_手順書」フォルダがあり、その中にチェックリストとなる「ワークシート.xlsx」や、試験手順を記したPDFが入っています。
miCheckerの設定に関しては、A、AA、AAAといったチェックレベルもそうですが、現在の多くのWebサイトはどこかしらでJavaScriptを使っていると思われるので、下記のチェック対象とするソースを「ブラウザ内のDOM」に変更した方が良いですね。
ただ、チェック結果に行番号が表示されなくなり、どの箇所がエラーや要検証なのかが分かり辛くなるというデメリットもありますが…。
axe-core
アクセシビリティ・テストエンジンの「axe-core」は、Chromeの拡張機能「axe DevTools」やブラウザ自動操作ツールのpuppeteerやplaywrightと連携させたものがあり、これらを使ってWebページにチェックを掛けることができます。
axe DevToolsはChromeの開発者ツールパネル内でチェックとその結果を見ることができますが、@axe-core/puppeteer等はチェックを掛けるとチェック結果がJSONとして出力されるだけで、とても見辛いので下記のようなレポートツールを併用する必要があります。
axe-auto-reporter
axe-auto-reporterは、日本人の方が作成しており、下記のようにカラフルにエラー等を見ることができるのでとても便利です。ページの画面キャプチャが右上にあるのも良いですね。
axe-html-reporter
axe-html-reporterも下記のようにaxe-coreの出力結果をレポート形式に変換してくれます。
Pa11y
アクセシビリティ・チェックツールのPa11yは、テストランナーとして前述のaxe-coreとHTML_CodeSniffer（デフォルト設定）を切り替えてチェックを掛けることができます。
レポーターとしては、「Pa11y HTML Reporter」があります。
Chromeの拡張機能
ここからはChromeの拡張機能をいくつか紹介します。
WAVE Evaluation Tool
「WAVE Evaluation Tool」は、エラーやHTML構造の視覚化、カラーコントラストの自動チェック等を行うことができます。
具体的にどの場所なのかをアイコンで画面上に表示してくれるのは、分かり易くて良いですね。
ARC Toolkit
「ARC Toolkit」もエラーやアラートのチェック、カラーコントラストの自動チェック等を行うことができます。
WAVEのように画面全体にエラーやアラートのアイコンが表示されるのではなく、それぞれの項目をクリックすると該当箇所が表示されるので画面の見易さはあります。
taba11y
「taba11y」は、tabキーを押下した際のフォーカス移動の軌跡を下記のように1、2、3、4…と数字付きで自動表示してくれます。
わざわざ自分でtabキーを何度も押してフォーカスの順番検証をしなくても良いのは便利です。
Web Developer
「Web Developer」は、JavaScriptやCSSをOFFにしたり、画像のALT属性やaタグのtitle属性の表示をする等、いろいろな機能を備えた拡張機能です。Web Developerで確認する項目、自作のブックマークレットで確認する項目、といったように個人的には使い分けている感じですね。
Accessibility Insights for Web
「Accessibility Insights for Web」は、Microsoft社が開発しているアクセシビリティチェック用のブラウザ拡張機能です。Webではなく、Windowsのデスクトップアプリケーション用には「Accessibility Insights for Windows」が別途提供されています。
FAQに記載がありますが、Accessibility Insights for Webの自動チェックには前述のaxe-coreが内部的に使われているようです。ちなみにGoogle Chromeの開発者ツールにあるLighthouseも内部的にaxe-coreが使われています。
下記のように左側にチェック項目が並んでおり、上から順番にチェックをしていく形になりますが、項目によって手動チェックのものと自動チェックのものがあります。
各種ツールの雑感
ここまでアクセシビリティ・チェックツールやブラウザの拡張機能をいろいろ書いてきましたが、こうしてまとめるとたくさんありますね。テストエンジンとしては、axe-coreがいくつかのツールでも内部的に使われており、スタンダードな感じになってきています。
チェック方法としては、まずは紹介したようなチェックツールを用いて機械的に検出できるエラーを修正し、その後、目視チェックといったワークフローが効率的でしょうか。
HTMLやCSSのカラーコントラスト自動チェック機能は多くのツールの中に内包されてきていますが、バナー等の画像内テキストについてはColour Contrast Analyzerや画像をアップロードしてオンラインで計測することができるContrast Checker等を用いて個別に測る必要がありそうです。
アクセシビリティに関するアレコレ
最後にアクセシビリティに関するアレコレに触れて終わりにします。
日本国内のスクリーンリーダーのシェア
1月にウェブアクセシビリティ基盤委員会のFAQに追加されていましたが、日本視覚障害者ICTネットワークの第3回支援技術利用状況調査によると日本国内のスクリーンリーダーのシェアはPC-Talker、NVDA、Windows標準のナレーターといった順になっていますね。
文字サイズ変更、読み上げ機能は非推奨
デジタル庁の「ウェブアクセシビリティ導入ガイドブック」では、Webサイト側での下記のような機能の提供を非推奨としています。
- 文字サイズ変更機能
- 配色変更機能
- 読み上げ機能
ヘッダーに文字サイズ変更ボタンを配置しているサイトは、たまに見かけますね。miCheckerに付属している「ワークシート.xlsx」でもG178では「文字のサイズを徐々に大きくするメカニズムをウェブサイト上で提供」といった記載がありますが、2018年のWeb担の記事でも文字サイズ変更機能等は不要と結論づけられています。
同様のものに、本文へのスキップリンクというものがあります。
ボタンをクリックすると本文へアンカーリンクで飛ばすものですが、A11y.jpによればこれも不要と書かれています。
デジ庁のサイトを前述のtaba11yで調べると分かりますが、本文への隠しスキップリンクが<a class="u-visually-hidden" href="#mainContainer">本文へ移動</a>として記述されています。不要と言えば不要な機能ですが、隠しリンクでスクリーンリーダー利用者のみに本機能を提供するというのはアイデアとしては面白いですね。
また、デジ庁のガイドブックではその他のアクセシビリティ・オーバーレイ機能（ページ内の配色を変えたり、要素間のマージンを広げたりといったサイト側で後付けしたアクセシビリティ機能）も非推奨としているため、これらの機能も基本的には不要と言えるでしょうか。
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications)
WAI-ARIAはAやAAといったアクセシビリティ基準を達成するのに必須かと言えば、そうではないケースが多く、どちらかと言えば余裕がある時のプラスアルファの対応といった趣が強い印象です。
W3CのARIA Authoring Practices Guideの実装パターン集は参考になりますが（何も考えずに同じように実装すれば良いという訳ではないので注意。）、“No ARIA is better than Bad ARIA.”と書かれているように誤ったARIAを設定するぐらいならARIAなんて設定しない方が良いというのはその通りですね。スクリーンリーダーの利用者をミスリードするだけで、良いことは何もありませんので。