自動アクセシビリティスキャナーは高速でスケーラブル、そして貴重な第一の防御線ですが、調査によると実際のWCAG違反のうち検出できるのは30～57%に過ぎないことが一貫して示されています。スキャナーの限界や見逃してしまう点、そして多層的なテスト戦略の構築方法を理解することは、コンプライアンスとインクルージョンに本気で取り組むすべての人にとって不可欠です。

自動アクセシビリティスキャンを実行し、ダッシュボードがグリーンで返ってくると、ほっと胸をなでおろしたくなります。しかし不都合な真実があります。そのきれいなレポートは、実際にはサイトの本当のアクセシビリティ障壁の大半を隠しているかもしれません。調査や独立した研究は一貫して、自動スキャナーが実際のWCAG違反のうち検出できるのはおよそ30%〜57%に過ぎないことを示しています。つまり、障害のあるユーザーが日々直面している問題の半分から3分の2は、ほとんどのチームが頼りにしているツールからは完全に見えないということです。

自動アクセシビリティテストの現状

自動アクセシビリティテストは急速に普及しており、それにはもっともな理由があります。アクセシビリティの問題をスクリーニングするために自動化へと向かうチームが増えています。ある2024年の調査では、回答者の50%が潜在的な問題を特定するために自動アクセシビリティツールを使用していると答え、これは2023年の40%から増加しています。その魅力は明らかです。スキャナーは高速で比較的安価であり、CI/CDパイプラインに直接統合できます。スケールにおいて、明白で反復可能なルールベースの違反を検出します。欠落したalt属性、ラベルのないフォーム入力、アクセシブルネームが空のボタンなどです。

しかし、カバレッジの上限は、どのスキャナーベンダーも突破できていない厄介な問題です。Dequeによると「平均してWCAGの問題の57%を自動的に見つけることができる」が、それでもツールは手動レビューが必要な不完全なコンポーネントとして返すことがあるとされています。この57%という数字は、現実的な測定手法を用い、市場で最も成熟し信頼されているアクセシビリティエンジンの1つによって達成された、楽観的な側の値です。他の推計はかなり低くなります。自動ツールが検出できるWCAG違反はおよそ30〜40%であり、残りの60〜70%は手動テストが必要です。

30%と57%の差は、分母をどう定義するかに帰着します。Dequeは、理論的なアプローチではなく現実的なアプローチを取り、多数のサイトをサンプリングし、実際に文書化されたアクセシビリティ欠陥のうち、axe-coreを使ってどれだけ検出できたかを測定することで57%という数字に到達しました。研究者が代わりに、WCAGのすべての達成基準を理論的な集合としてカバレッジを測定すると、数字は急激に低下します。この記事執筆時点で、WCAG 2.2レベルAおよびAAにフィルタリングし、承認された自動テストルールのみを表示すると、55の達成基準のうち部分的または完全にカバーされているのは17に過ぎません。どのように切り取っても、自動テストには大きな——そして法的にも危険な——ギャップが残ります。

問題をさらに悪化させているのは、そのギャップが外からは非常に見えにくいことです。スキャンに合格すると、安全であるというシグナルが積極的に発せられ、まさにそのときにチームは調査をやめがちです。ダッシュボードはグリーン。リリースは進む。実際の障害のあるユーザーは、実際の障壁にぶつかります。

スキャナーが実際に得意なこと

カバレッジギャップに踏み込む前に、自動ツールが本当に得意としていることを明確にしておく価値があります。ツールは高速で、一貫性があり、DOMを読むだけで判断できる事柄のチェックにおいて疲れを知りません。アクセシビリティ自動化は、altテキストの欠如、空のリンク、不適切なフォームラベル、低いカラーコントラスト比といった一般的なWCAG違反を確実に検出できます。これらは構造的で二値的なチェックです。属性が存在するかしないか、コントラスト比が4.5:1を満たすか満たさないか、という具合です。

毎年上位100万件のホームページを分析するWebAIM Millionレポートは、こうした検出可能なエラーがどれほど蔓延しているかを生々しく示しています。95.9%のホームページでWCAG 2の失敗が検出されました。最も一般的な6つのカテゴリ——低コントラストのテキスト、altテキストの欠如、フォームラベルの欠如、空のリンク、空のボタン、文書言語の欠如——は、検出されたすべてのエラーの96%を占めており、これら最も一般的なエラーは過去7年間ずっと同じです。自動ツールは、こうした頻度が高く複雑性の低い違反をスケールで表面化させる点では本当に役に立ちます。問題は、これらの問題だけを修正しても、サイトには依然として大半の実際の障壁が残るということです。

なぜギャップが存在するのか：スキャナーが評価できないもの

カバレッジの上限は、エンジニアリングの失敗ではなく、人間の判断なしに機械が評価できることの根本的な限界です。このギャップが存在するのは、機械がコンテキストやユーザーの意図、見出し階層が意味をなしているか、altテキストが正確かといった主観的な問題を理解できないからです。スキャナーは、画像にalt属性があることは確認できます。しかし、その属性が"photo-123-final-v2.jpg"と書かれているのか、本当に有用な説明になっているのかは判断できません。ツールは画像にaltテキストがあることをフラグできますが、そのテキストが実際に画像をうまく説明しているかどうかを判断できるのは人間だけです。

以下は、自動検出から一貫して逃れてしまう主な問題カテゴリです。

スクリーンリーダーでの体験: 自動ツールは、スクリーンリーダーがコンテンツをどのように読み上げるかを「聞く」ことができません。ARIA属性の妥当性はチェックできますが、その結果としての読み上げがユーザーにとって意味をなすかどうかは判断できません。フィールドには技術的には有効なaria-labelが付いていても、実際のNVDAやJAWSユーザーには意味不明な文字列として読み上げられるかもしれません。
論理的な読み順とフォーカス順序: 実際には、スクリーンリーダーユーザーが情報にアクセスするとき、視覚的には問題なく読めるレイアウトでも読み順が意味をなさないことがよくあります。カラムレイアウトでは、スクリーンリーダーはカラム1の1行目、次にカラム2の1行目という順に読み上げるため、混乱を招きます。スキャナーはDOM順序を単独で解析し、視覚的なレイアウトがどのようにその順序を変形させているかという、視覚ユーザーのコンテキストを持ちません。
コンテキストにおける意味のあるリンク・ボタンテキスト: 自動ツールはリンクが存在するか、テキストを含んでいるかはチェックできますが、そのリンクの目的が明確かどうかを常に判断できるわけではありません。同じページに「続きを読む」というリンクが5つあっても、自動チェックはすべて合格しますが、それぞれがどこへ導くのかを理解する必要がある実ユーザーにとってはすべて不合格です。
動的コンテンツとライブリージョン: 自動ツールは、動的に読み込まれるコンテンツに関する問題を検出することはできません。動的更新が追加された後に再度テストを実行する必要がありますが、それでもスクリーンリーダーがそれを読み上げるかどうかをツールは判断できません。
認知アクセシビリティと平易な言葉: 自動化は見出し順序やラベルの有無といった構造的な問題は検出できますが、可読性や明瞭さ、指示が分かりやすいかどうかは評価できません。複雑な複数ステップのチェックアウトで、エラーメッセージが分かりにくい場合、構造的には「クリーン」でも、認知障害のあるユーザーにとっては非常にアクセシブルでない可能性があります。
複雑なインタラクションにおけるキーボード操作: 自動化は基本的なキーボードフォーカスと操作性はテストできますが、複雑な複数ステップのインタラクション、カスタムジェスチャー、代替入力デバイスを完全に検証することはできません。カスタムのカレンダーウィジェットは、理論上は完全にキーボード操作可能でも、実際には完全なトラップになっているかもしれません。
重なり合う視覚要素とグラデーションのコントラスト: 自動ツールはコントラスト比を評価できますが、重なり合う要素、テキストの背後にある画像、可読性を妨げる動的に変化するコンテンツなどを常に考慮しているわけではありません。

クリーンな自動スキャンは、自動化で検出できる30〜40%の問題に対処したことを意味します。残りの60〜70%は未テストです。自動テストだけに基づいてWCAG準拠を主張してはいけません。

特に印象的な証拠が1つあります。イギリスの政府系アクセシビリティ擁護者が、意図的に142のアクセシビリティ障壁を持つウェブページを作成し、そのページを13の自動アクセシビリティツールで分析した研究です。最も性能の良かったツールでさえ、障壁の40%しか特定できませんでした。最も性能の悪かったツールは13%しか見つけられませんでした。既知で文書化された問題を持つ制御されたページを使い、ツールに有利な条件を整えても、結果は厳しいものでした。そしてツールを組み合わせても完全な解決にはなりません。6つのツールを並行して使用しても、WCAG 2の達成基準の半分はカバーされず、違反の6割は見逃されます。

自動化への過度な依存がもたらす法的リスク

これはユーザー体験に関する理論的な懸念にとどまりません。アクセシビリティ非準拠に対する法的リスクは急激に高まっており、自動スキャンに合格しても訴訟においてほとんど保護にはなりません。2024年には、ウェブサイトまたはモバイルのアクセシビリティ障壁を訴える訴訟が、米国の裁判所で4,000件以上提起されました。 2025年上半期だけでADAウェブサイト訴訟は2,014件に達し、2024年から37%増加しました。

裁判外和解の平均額は$30,000、裁判判決の平均額は$85,000です。さらにすべてのケースで$30,000〜$175,000の弁護費用が上乗せされます。さらに悪いことに、一度和解しても安全が保証されるわけではありません。2025年の連邦デジタルアクセシビリティ訴訟の45〜46%は、過去にすでに訴えられた企業を標的にしていました。訴えられた後、自動ツールが指摘した箇所だけをつぎはぎ的に修正し、より広範な構造的ギャップに対処しなければ、次の原告にとって格好の標的になるだけです。

また、アクセシビリティウィジェットやオーバーレイを、準拠への近道とみなす一般的な誤解にも触れておく価値があります。2025年のデータによると、アクセシビリティウィジェットを導入しているウェブサイトに対して456件のADA訴訟が提起されており、これは全訴訟の22.64%を占めています。これは、アクセシビリティウィジェットを追加するだけでは包括的な解決策にならないことを強調しています。自動ツールが検出できるWCAGの問題は30%に過ぎません。つまり、自動検出のみに依存するツールやウィジェットは、定義上、問題の大半を放置していることになります。本当に価値のあるアクセシビリティSDK——たとえばAccsibleのような——と、法的・規制上の反発に直面してきたオーバーレイ製品を分けるものは、自動修正と、虚偽の保証ではなく誠実で多層的な準拠戦略へのコミットメントを組み合わせているかどうかです。

実際に機能する多層テスト戦略

カバレッジギャップへの答えは、自動スキャナーを捨てることではありません。それらを包括的な戦略の「最後」ではなく「最初の」レイヤーとして正しく使うことです。WCAG 2.2の86の達成基準のうち、70%は、基準を適切に解釈し、自動アクセシビリティ技術の射程外にあるグレーゾーンに適用するために人間によるレビューが必要です。つまり、人間の判断は任意ではなく、標準そのものによって構造的に要求されているのです。

堅牢なアクセシビリティテストプログラムは、通常3つのレイヤーで機能します。

自動スキャン（継続的）: axe-coreのようなスキャナーをCI/CDパイプラインに統合し、すべてのビルドで実行します。構造的で二値的な違反を本番に到達する前に捕捉します。しきい値を設定し、新たな重大な違反があればビルドを失敗させます。これは明白な問題に対するセーフティネットであり、高速でスケーラブルかつ安価です。開発の早い段階から頻繁に自動ツールを実行しましょう。axeやWAVEをCI/CDパイプラインに統合し、コードがQAに到達する前に問題を検出します。これによりアクセシビリティテストを左シフトし、修正コストが最も低い段階で問題を捕捉できます。
専門家による手動監査（定期的）: 深いアクセシビリティ知識を持つ人々が、完全なWCAGチェックリストに基づいて構造化された手動監査を実施します。手動アクセシビリティテストは、スクリーンリーダー、キーボードナビゲーション、拡大ソフトウェアなどの支援技術を実際に使ってウェブサイトを操作する訓練された専門家によって実施されます。彼らはコンテキストとユーザー体験——論理的なフォーカス順序と直感的なナビゲーション、フォームやエラーメッセージの明瞭さ、複雑なコンテンツ内での読みやすさ——を評価します。手動監査は通常、四半期ごと、または大きな機能をリリースする際に実施され、トラフィックの最も多いユーザージャーニーをエンドツーエンドでカバーすべきです。完全手動と完全自動の中間に位置するガイド付き手動アクセシビリティ監査は、カバレッジギャップを狭め、このアプローチでカバレッジが80%に達するという推計もあります。
支援技術とユーザーテスト（継続的）: サイトのアクセシビリティ問題を特定するのに、自動ツールだけに頼ることはできません。すべてのウェブサイトプロジェクトにはユーザーテスト戦略が必要であり、その中にアクセシビリティユーザーグループ——スクリーンリーダーユーザー、キーボードのみのユーザー、聴覚障害のあるユーザー、運動障害のあるユーザー——を含めることが強く推奨されます。実際の障害のあるユーザーは、どんなチェックリストでも想定していない問題を見つけます。WindowsではNVDAとJAWS、macOSとiOSではVoiceOver、AndroidではTalkBackでテストしましょう。キーボードだけを使って、チェックアウトやサインアップフロー全体を操作してみてください。コンテンツが読み上げられたときにどのように聞こえるか、実際に耳で確かめてください。

3つのレイヤーすべてを実装すると、組み合わせたカバレッジは実世界の問題の80〜90%に近づきます。これは、自動化単独の30〜57%という上限から劇的な改善です。目標は初日からの完璧さではなく、誠実な善意の努力を示し、継続的にギャップを埋めていく体系的で文書化されたプロセスです。

アクセシビリティを開発ワークフローに統合する

最も重要な文化的変化は、アクセシビリティをリリース前のチェックリストから、継続的な実践へと位置づけ直すことです。多くの組織は、訴訟を恐れたときに一度だけ依頼する監査のように扱うという誤りを犯しがちですが、本来は各スプリントに組み込まれるべき品質基準です。監査が本番システムの問題を明らかにする頃には、それを修正するコストは、設計段階で対処していればかかったであろうコストの5〜10倍になっています。

まず、アクセシビリティ基準を「完了の定義」の一部に組み込みましょう。開発者が新しいコンポーネントを出荷するときには、簡単な自動チェックが自動的に実行されるべきです。デザイナーが新しいパターンを作成するときには、デザインが引き渡される前に、カラーコントラストとフォーカス状態がレビューされるべきです。コンテンツ編集者が新しい画像を追加するときには、「altテキストが必要だ」というだけでなく、「意味のあるaltテキストとはどのようなものか」を明確に理解している必要があります。

コンプライアンス担当者にとって、実務的な意味を持つのはドキュメンテーションです。自動テストを実行しても、その結果に決して対処しないチームもあります。これは何の価値も生まず、問題を認識していながら修正しなかったという文書を生み出すだけであり、法的な場面では不利に働きます。アクセシビリティプログラムが防御可能であるのは、継続的改善の合理的で誠実なプロセスを示せる場合だけです。定期的なスキャン、文書化された所見、是正ロードマップ、そして学んだことに基づいて行動している証拠が必要です。WCAG準拠は、一度達成して終わりの二値的な状態ではなく、維持し続ける姿勢なのです。

Accsibleのようなツールは、この多層アプローチを支援するために存在します。アクセシビリティ改善をユーザー体験に直接組み込むSDKを提供し、リアルタイムの問題を表面化させ、手動監査プロセスを置き換えるのではなく補完します。適切なオーバーレイやSDKは、訴訟に対する魔法の盾ではありません。それは、自動化でできることとできないことを認識した、思慮深いプログラムの1コンポーネントに過ぎません。

主なポイント

自動スキャナーはスタート地点であり、ゴールではない。 最高のツールであっても、実際のWCAG違反のうち検出できるのは30〜57%です。クリーンなスキャンレポートは、サイトがアクセシブルであることを意味しません。検出可能なサブセットの問題に対処したことを意味するだけです。
WCAGの達成基準の大半は人間の判断を必要とする。 スクリーンリーダーでの体験、論理的な読み順、コンテキストにおける意味のあるリンクテキスト、認知的な明瞭さ、複雑なキーボードインタラクションなどは、いずれも自動化では構造的に信頼できる答えを出せない領域です。
法的環境は惰性に対して厳しい。 2025年には5,100件を超える連邦ADAウェブサイト訴訟が提起され、和解金は通常$30,000〜$85,000に加えて弁護費用がかかり、被告のほぼ半数はすでに過去に訴えられていました。これは、表面的な修正だけでは不十分であることを示唆しています。
自動スキャン、専門家による手動監査、実際の支援技術テストという3層戦略は、カバレッジを80〜90%に近づけることができ、 裁判所や規制当局が期待する、文書化された誠実な準拠姿勢を提供します。
アクセシビリティを左シフトする。 設計・開発段階で問題を捕捉するコストは、リリース後の是正コストのごく一部で済みます。自動チェックをCI/CDに統合し、アクセシビリティを「完了の定義」の一部とし、トラフィックの多いユーザージャーニーに対して定期的な手動監査を実施しましょう。

なぜ自動アクセシビリティスキャナーは問題の30%しか検出できないのか（そしてその対処法）