ウェブサイトが、ウェブアクセシビリティガイドラインで求められる達成基準を満たしているかを実際に試験（チェック）する作業においては、大きく下記の3つの手法が用いられます。
- プログラムによって機械的に行うチェック（AC: Automated Check）
- 機械的なチェックで発見可能なチェック項目を人間が目視で判断する方法（AF: Automated Find）
- 機械的なチェックでは発見不可能なチェック項目を人間が目視で判断する方法（HC: Human Check）
プログラムによって機械的に行うチェック（AC: Automated Check）のみでウェブアクセシビリティに関するすべての試験が問題なく完了するのであれば、それはもちろん理想的なのですが、残念ながらプログラムのみで完全なウェブアクセシビリティ試験を行うことはできません。
例えば、画像に求められる代替テキストが、「設定されているか」「設定されていないか」についてはプログラムのみでも判定可能ですが、「設定された代替テキストが、その画像に対して適切なものか」あるいは「代替テキストが空だが、それは画像の内容や文脈から考えて妥当なのか」といった部分までは、残念ながら現在の技術では正しく判断ができません。
そのため、ウェブアクセシビリティ試験を行うにあたっては、機械的なチェックのみではなく、それ以外の 2 つの方法、機械的なチェックで発見可能なチェック項目を人間が目視で判断する方法（AF: Automated Find）、および機械的なチェックでは発見不可能なチェック項目を人間が目視で判断する方法（HC: Human Check）という、人間が最終的に判断する方法を併用することが求められます。
機械的チェックで判断できる試験項目は全体のごく一部
実際に細かく統計をとったわけではないため、あくまで我々が過去に行ってきたウェブアクセシビリティ試験からの経験則ではありますが、機械的なチェック「のみ」で判断できる内容は、試験全体の10%～15%程度に限られるのではないでしょうか。
例えば、機械的なチェック（AC: Automated Check）のみで判断可能な（可能性がある）試験項目としては、下記のような項目が挙げられるでしょう。
- HTML に「文法的な」間違いがないかどうか（JIS X 8341:2016 における「4.1.1 構文解析の達成基準」）
- テキストと背景色のコントラスト比（JIS X 8341:2016 における「1.4.3 コントラスト（最低限レベル）の達成基準」および「1.4.6 コントラスト（高度レベル）の達成基準」）
- ブロックスキップ機構の有無（JIS X 8341:2016 における「2.4.1 ブロックスキップの達成基準」）
- その他、リンクの目的が明確かどうかの一部、つまりリンクテキストをもたない a 要素がないかなど（JIS X 8341:2016 における「2.4.4 リンクの目的（コンテキスト内）の達成基準」および「2.4.9 リンクの目的（リンクだけ）の達成基準」）
逆にいえば、ここで挙げた項目以外に関しては、人の目で確認しなければ最終的な判断ができないということです。
また、上に挙げたものでも、HTML に「文法的な」間違いがないかどうかは機械的に判断できたとしても、見出しや箇条書き部分など、使用されている HTML 要素の選択が妥当かどうかに関しては、文脈から判断しなければならないため、現在の技術において機械がそれを正しく判断することは困難ですし、コントラスト比も、背景色がグラデーションだったり、単色でない画像の場合は同様に機械だけで正しく判断することは難しいでしょう。
今後技術が進み、プログラムが文脈や画像の内容まで解析して人の目で確認するのと同程度の精度でアクセシビリティ試験を実施できるようになれば素晴らしいことだと思いますが、現実的にはまだしばらくの間、人の目で細かくチェックしながら試験結果をまとめる労力と、試験担当者の能力が、ウェブアクセシビリティ試験の現場においては必要になるでしょう。
試験の負荷を低減するためにも事前の環境整備を
余談になりますが、例えばウェブサイトに新たにページを追加する際、デザイナーが自由に色を選択して使って良い場合、コントラスト比に関連するウェブアクセシビリティガイドラインの達成基準を満たさない色の組み合わせが使用されるかもしれません。
あるいは HTML をはじめとしたコーディングガイドラインがなければ、実装者が独自の判断で実装を行い、結果として達成基準を満たさない UI コンポーネントやウェブページができあがる可能性もあります。
当然、デザイナーや実装担当者がウェブアクセシビリティガイドラインを正しく理解し、それに基づいてデザインや実装を行えばよい、ともいえますが、それでもガイドラインの解釈や実装方法の選択は人によってばらつきがありますし、日々の運用の中で、何か変更や追加がある都度、アクセシビリティ試験を実施するのも難しいでしょう。
そのため、事前にコントラスト比の試験をクリアした色の組み合わせによるカラースキーム、あるいはカラーパレットの作成や、デザインガイドラインの策定、コーディングガイドラインや UI コンポーネントライブラリの整備、それらを包含するデザインシステムの構築などが重要になります。
ウェブアクセシビリティに新たに取り組もうとなった場合、ウェブサイトの新規立ち上げやリニューアルプロジェクトなど、ウェブサイトを新たに制作する過程でそれが行われる場合が多く、ウェブサイトが公開された時点でのウェブアクセシビリティガイドラインへの適合・準拠ばかりに目が行きがちです。
しかし実際にはウェブサイトが公開され、運用されていく中でアクセシビリティを高く保ち、それを維持、改善していくのかが重要になります。そのためにもアクセシビリティを確保するための環境整備を怠ってはいけません。
