持続的なウェブアクセシビリティ検証の運用 (自動テストと手動テストのバランスの取りかた)

ウェブアクセシビリティの検証には、自動テスト (註1) と、人間による手動テスト (註2) の、ふたつの手法があります。

註1 : ここで言う自動テストとは、専用のツール (Deque Systems の axe、WebAIM の WAVE、TPGi の ARC Toolkit など) を用いて、ウェブページ全体に潜むアクセシビリティの問題を自動的に検出することを言います。 註2 : ここで言う手動テストとは、人間がテスト実施者となり、WCAG (Web Content Accessibility Guidelines) に基づいてヒューリスティック評価を行なったり、スクリーンリーダーなどの支援技術を用いてウォークスルー評価を行なったりすることを言います。

自動テストの利点は、特定のチェック項目 (画像に代替テキストがあるか、アクセシビリティの観点で不適切な HTML 構造がないか、背景色と前景色のコントラスト比に不足がないか、など) について、ウェブページ全体をくまなくスキャンして、迅速に問題を検出してくれることです。ツールによっては、複数の (多数の) ウェブページに対して、一括的にテストを実行することも可能です。

その一方で、自動テストにはカバレッジの限界があります。Deque Systems によると、axe を用いればアクセシビリティの問題を6割近く検出できるそうですが (参考 : The Automated Accessibility Coverage Report - Deque)、一般的には、自動テストツールによるアクセシビリティの問題の検出は、せいぜい3割程度と言われています。いずれにしても、自動テストだけでアクセシビリティ検証を完結することはできず、人間による手動テストも不可欠と言えます。

ウェブサイトやアプリケーションを運用する組織において、アクセシビリティ検証を効率的、効果的、そして持続的に行なうには、自動テストと手動テストを、バランスよく組み合わせたいものです。自動テストは「広く」そして「早く」、手動テストは「深く」そして「丁寧に」検証することに長けていると考えると、たとえば以下のようにテスト運用を検討することができそうです。

すべてページに対して自動テストを行なう

ウェブサイト内のすべてのページに対してアクセシビリティ検証を行なうには、自動テストが向いているでしょう。拙作ですが「axe-test.js」のようなスクリプトを用いて、サイト全体をまとめて一括テストすることもできます。これを定期的に繰り返す、たとえば1日でサイト全体に対する自動テストを実施して、そこで検出された問題を、次回の自動テストまでに可能な範囲で改修する、というサイクルを回すことによって、サイト全体におけるアクセシビリティの問題を量的に捕捉しつつ、改善状況をモニターすることができます。

一点、懸念となるのは、(全体のページ数や、サイト公開時点でのアクセシビリティ担保の度合いにもよりますが) 自動テストの結果、問題の検出数が膨大になることです (数千件にのぼることも珍しくありません)。その数に圧倒されて思考停止に陥るのを防ぐために、組織の中で以下の認識合わせをしておくとよいでしょう。

自動テストの頻度は月1回でもよいですし、それだと改修のサイクルを回すのに間隔が短すぎるようでしたら、2ヶ月ごと、あるいは3ヶ月ごとにしてもよいでしょう。

なお、自動テスト一回あたりの問題の検出数を減らす目的で、テスト対象を小分けにする (何回目かで一巡することでサイト全体がテストされる体にする) 運用は、あまりおすすめしません。自動テストを繰り返す中で、テスト対象に一貫性がないと、評価指標を比較する (改善状況をモニターする) ことができないからです。あるいは、テスト項目をあらかじめ絞ってしまう運用も、おすすめできません。取り組むべきアクセシビリティ要件を限定的なものと誤認識してしまう組織風土を作ってしまいかねないからです。

主要なページに対して手動テストを行なう

人間による手動テストは、自動テストよりも精度の高いアクセシビリティ検証を可能にしますが、ウェブサイト内のすべてのページに対して手動テストを実施することは現実的ではありません。代わりに、以下に挙げるような主要なページに対象を絞って、定期的な手動テストを実施することを検討するとよいでしょう。

これらの主要なページに対する手動テストの頻度は、少なくとも年1回、可能であればより高頻度 (たとえば半年に1回、など) でできればよいですが、上述のサイト全体の自動テスト (とそれに伴う改修) も同時に回すことを考慮に入れて、無理のないサイクルにするのがよいと思います。なお、手動テストに際しては、人間による見落としを未然に防ぐために、対象ページに対して自動テストも併せて実施することをおすすめします。

すべてのページ更新に対して自動テストを行なう

ウェブサイトには、ページの更新がつきものです。そして、ページ更新を重ねてゆくにつれて、もともとアクセシブルだったウェブサイトが、徐々にアクセシブルでなくなってゆくということも、ままあることです。こうした「経年劣化」を防ぐには、ページが更新されるたびにアクセシビリティを検証し、問題があれば即時に解消することを組織として習慣化することが不可欠です。

ページ更新に対しては手動テストを行なうのが理想ではありますが、手動テストにこだわるあまり更新された一部のページに対してのみテストを実施するよりは、すべてのページ更新に対して自動テストを実施するほうがよいでしょう。更新されたページの URL を自動的に取得できる仕組みがあれば、その URL に対して自動テストツールを走らせるようにしておくことで、運用の省力化も期待できます。

共通コンポーネントのリリース時に手動テストを行なう

ウェブサイトによっては、パターンライブラリー (デザインシステム) を整備しているところもあることでしょう。パターンライブラリーを構成する個々の UI コンポーネントは、サイト内の様々な箇所に適用されるという意味で影響範囲が大きいため、その新規公開や更新に際しては、確実にアクセシビリティを担保したいところです。おすすめなのは、UI コンポーネントのリリース前に手動テストを実施し、アクセシビリティの問題がないことをリリース条件にすることです。これを継続することで、アクセシブルな実装が、安定してサイト全体に行き渡ることが期待できます。

組織にフィットした持続可能なアクセシビリティ検証をルーティン化する

ここまでの検討をまとめると、以下のようなテスト運用が、ひとつのモデルとして見えてきます。

もちろんこれは「唯一の正解」ではなく、組織によって最適解は異なることでしょう。大事なのは、ウェブサイトやアプリケーションを運用する各々の組織にフィットした持続可能なテスト運用を、ルーティン化して継続することです。採用する自動テストツールの特徴や、組織固有のリソースの制約なども加味しながら、現実的な落とし所を探る形になるかと思いますが、この記事で試みた検討が、多少なりともご参考になれば幸いです。