ログイン

ウェブアクセシビリティのテスト方法：自動化ツール、手動テスト、スクリーンリーダー

3 min read
- 翻訳の目的と文脈を把握する - 原文の意味・トーン・文体を正確に保持する - 数字や記号などの表記を原文どおり維持する - 固有名詞や既存の訳語がある用語は適切に扱う - 原文の改行・段落構成をそのまま保つ テスト斧・全体の意味と文脈を把握する ・原文のトーンとスタイルを維持する ・日本語で一般的な用語を選択する ・数値や記号などは原文どおり維持する ・改行やテキスト構造をそのまま保つ スクリーンリーダー

ほとんどのウェブサイトは依然として基本的なアクセシビリティチェックに不合格であり、2026年の WebAIM Million レポートでは、100万件のホームページにわたって5,600万件以上の固有のエラーが見つかりました。このガイドは、ウェブサイトの所有者、開発者、コンプライアンス担当者に向けて、自動スキャナー、手動による実地チェック、実際のスクリーンリーダーによるテストまで含めた完全なテストスタックを解説し、本当に重要な問題を確実に検出できるプログラムを構築できるようにします。

この数字は無視できません。2026年の WebAIM Million レポートによると、100万件のホームページに対する自動スキャンで、5,600万件を超える個別のアクセシビリティエラーが検出されました。これは1ページあたり平均56.1件のエラーで、前年から10%以上増加しています。しかも、自動ツールが検出できるのは潜在的な WCAG 違反の約30〜40%に過ぎないため、問題の真の規模はそれよりはるかに大きくなります。もしあなたのアクセシビリティテスト戦略が、1つのブラウザー拡張機能によるスキャンだけで始まり終わっているのであれば、ユーザーが日々直面している障壁のごく一部しか見えていません。

なぜ多層テスト戦略が「必須」なのか

ウェブアクセシビリティテストは単発のイベントではなく、ツール、人間の判断、そして実際の経験にまたがる一つの「専門領域」です。Web Content Accessibility Guidelines (WCAG) は、一般に POUR と呼ばれる4つの基本原則に基づいています。コンテンツは知覚可能 (Perceivable)、操作可能 (Operable)、理解可能 (Understandable)、そして堅牢 (Robust)でなければなりません。自動ツールは、画像に alt 属性が「付いているか」を検証することはできますが、その alt テキストが実際に画像を意味のある形で説明しているかどうかを判断することはできません。スクリプトはボタンにラベルがあることを確認できますが、スクリーンリーダーユーザーが、そのボタンを押すと何が起こるのかを文脈の中で理解できるかどうかまでは教えてくれません。

このため、本気で取り組むアクセシビリティプログラムは必ず3つのアプローチを重ね合わせます。大規模に、体系的で再現性のある違反を検出するための自動スキャン。人間の判断を要する基準を評価するための手動テスト。そして、これらのツールに日常的に依存しているユーザーの実体験を検証するための支援技術テスト、特にスクリーンリーダーによるテストです。各レイヤーは、他のレイヤーの死角を補完します。どれか1つでも省略すれば、いずれユーザーからの苦情、監査の不合格、あるいは法的リスクとして表面化する「穴」が残ることになります。

2023年末時点の最新 W3C 標準である WCAG 2.2 は、既存の WCAG 2.1 の要件をすべて維持しつつ、キーボードナビゲーション、タッチ操作、認知アクセシビリティに関するユーザビリティをより重視しています。多くの組織にとって、これに基づいてテストすることは「選択肢」ではなく、米国の ADA から 2025年6月に施行された European Accessibility Act に至るまで、規制によってますます義務付けられています。どのようにテストするかを理解することが、コンプライアンスを現実的なものにする実務的な土台なのです。

自動テスト：最初の防衛ライン

自動ツールはテストプロセスを加速し、CI/CD パイプラインにシームレスに統合されることで、チームがアクセシビリティエラーを早期かつ頻繁に検出・修正できるようにします。自動ツールは「フィルター」として理解するのが最適です。すべてを検出できるわけではありませんが、最も一般的で測定可能な違反を、人間のレビュアーでは到底かなわない速度で、安定して検出します。スペルチェックのようなものだと考えてください。不可欠ではあるものの、熟練した編集者の代わりにはなりません。

自動ツールが安定して検出できる代表的な問題カテゴリには、画像の alt テキストの欠如または空の alt テキスト、不十分な色コントラスト比、ラベルが関連付けられていないフォームフィールド、空のリンクまたはボタンテキスト、ページ言語宣言の欠如、見出し構造の重複または欠落などがあります。WebAIM Million のデータによると、検出されたエラーの96.4%はわずか6つのカテゴリに集中しています。つまり、自動ツールを継続的に適用することで、人間のレビュアーがインターフェースに触れる前に、違反件数を大幅に減らすことができるのです。

代表的な自動テストツール

axe-core / axe DevTools（Deque Systems）は、おそらく業界で最も広く採用されているアクセシビリティテストエンジンです。そのオープンソースコアは、他の多数のツールやテストフレームワークに組み込まれています。ブラウザー拡張機能は Chrome、Firefox、Edge で動作し、レンダリングされた DOM に対する即時フィードバックを開発者に提供します。エンジニアリングチーム向けには、axe-core は Cypress、Playwright、Selenium、Jest と統合でき、既存のテストスイートにアクセシビリティチェックを直接組み込むことが容易です。

WAVE（WebAIM）は、ブラウザー拡張機能兼オンライン評価ツールで、コンテンツ上に色分けされたアイコンを直接オーバーレイすることで、ページ内の視覚的なフィードバックを提供します。コードを読まずにアクセシビリティの問題を理解する必要があるコンテンツ編集者や非技術系のステークホルダーに特に適しています。WAVE は、エラー、警告、構造要素、ARIA ロールをハイライトし、マークアップとユーザー体験の関係を一目でわかるようにします。

Google Lighthouse は Chrome DevTools に直接組み込まれており、パフォーマンス、SEO、ベストプラクティスのチェックと並行してアクセシビリティ監査を実行します。開発中のフロントエンドの簡易監査に非常に適しており、コマンドラインから実行して CI に統合することもできます。そのアクセシビリティスコアは内部的に axe-core によって支えられているため、カバー範囲は重なりつつも完全に同一ではありません。

Pa11y は、パイプライン統合向けに設計されたコマンドラインツール兼 Node.js ライブラリです。axe と HTML_CodeSniffer エンジンの両方をサポートし、設定ファイルから複数の URL をテストでき、ダッシュボードやチケットシステムに適した機械可読なレポートを出力します。大規模サイトのモニタリングや、URL を定期的に一括監査する必要がある組織に特に有用です。

axe を CI/CD パイプラインに統合する

アクセシビリティのリグレッションを防ぐ最も効果的な方法は、それを他のバグと同じように扱い、本番に到達する前に検出することです。axe-core を CI パイプラインに統合すると、すべてのプルリクエストが自動的にスキャンされ、違反が許容閾値を超えた場合にビルドを失敗させるように構成できます。以下は Playwright と @axe-core/playwright パッケージを用いた最小限の例です。

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test.describe('Homepage accessibility', () => {
  test('should have no automatically detectable WCAG violations', async ({ page }) => {
    await page.goto('https://your-site.com/');
    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
      .analyze();
    expect(results.violations).toEqual([]);
  });
});

このテストはアプリケーションにアクセスし、レンダリングされたページに対して WCAG 2.x レベル A および AA のルールに絞って axe-core を実行し、違反が1件でも返された場合は失敗します。これを GitHub Actions のワークフローに組み込めば、main へのプッシュやすべてのプルリクエスト時に実行させることができます。成熟したプロジェクトに初めて自動アクセシビリティテストを導入すると、既存の問題が数十件見つかることもある点に注意してください。すべてのデプロイを即座にブロックするのではなく、まずはベースラインとなる違反件数を設定し、修正を進めながら閾値を段階的に厳しくしていくとよいでしょう。

重要な制約: 自動ツールが検出できる WCAG 違反は約30〜40%です。必要不可欠ではありますが、それだけでは不十分です。アクセシビリティの障壁の全体像を明らかにするには、手動テストが不可欠です。

手動テスト：機械が判断できないこと

手動テストは、自動ツールでは構造的にカバーできないギャップを埋めます。これは、理想的には WCAG に精通し支援技術にも慣れたテスターが、定められた手順に従ってページやインタラクションを確認することを意味します。目的は、自動スキャナーがすでに見つけたものを再確認することではなく、人間の判断を要する基準を評価することです。読み上げ順序は論理的か。モーダルが開いた後のフォーカス管理は妥当か。エラーメッセージは本当に役に立つのか、それとも単に「無効な入力」とだけ表示しているのか。

実践的な手動テストセッションでは、いくつかの明確な領域をカバーします。最初はキーボードのみのナビゲーションです。マウスを外し、Tab、Shift+Tab、Enter、Space、矢印キーだけを使ってインターフェース全体を操作します。すべてのインタラクティブ要素—リンク、ボタン、フォームフィールド、ドロップダウンメニュー、日付ピッカー、モーダル、タブ—は、マウスなしで到達・操作できなければなりません。フォーカスが（意図的な場合を除き、モーダル内でフォーカスを保持すべきときなど）閉じ込められてはなりません。視覚的なフォーカスインジケーターは、追跡できるほど明確である必要があります。WCAG 2.2 では成功基準 2.4.11 Focus Appearance が追加され、フォーカスインジケーターの最小サイズとコントラスト要件が定められましたが、これはほぼ必ず手動チェックが必要になります。

2つ目の領域はコンテンツと構造のレビューです。見出し階層に批判的な目を向けてページを読みます。見出しはページのアウトラインを表現すべきです。ページタイトルには <h1>、大きなセクションには <h2>、小セクションには <h3> を用い、レベルを飛ばさないようにします。リンクテキストが単独でも意味を持つかを確認します（「2025 Annual Report をダウンロード」は良い例ですが、「click here」は良くありません）。意味のあるコンテンツを持つ画像には正確な alt テキストが付いているか、装飾目的の画像には空の alt 属性（alt=''）が設定されているかを確認します。フォームラベルも確認します。すべての入力欄には、プレースホルダーだけでなく、プログラム的に関連付けられたラベルが必要です。

3つ目の領域は動的インタラクションと ARIAです。シングルページアプリケーション、モーダル、ライブ検索結果、カルーセル、アコーディオンなど、JavaScript を多用するインターフェースは、静的スキャナーが見落としがちなアクセシビリティの課題を生み出します。モーダルが開いたとき、フォーカスはその中に移動するか。閉じたとき、フォーカスはトリガーとなった要素に戻るか。ライブリージョン（検索結果数、フォームのバリデーションメッセージなど）が更新されたとき、それは支援技術に対してアナウンスされるか。誤った ARIA の使用は、アクセシビリティリグレッションの最も一般的な原因の1つです。WebAIM Million のデータは一貫して、ARIA 属性を使用しているページは、使用していないページより平均してエラーが大幅に多いことを示しています。これは ARIA が悪いからではなく、しばしば誤って実装されているからです。

実践的な手動テストチェックリスト

  • キーボードナビゲーション: すべてのインタラクティブ要素を Tab で移動し、論理的な順序であること、フォーカストラップがないこと、WCAG 2.2 SC 2.4.11 を満たす視覚的なフォーカスインジケーターがあることを確認します。
  • 見出し構造: HeadingsMap や WAVE ツールバーのようなブラウザー拡張機能を使い、レベル飛ばしのない論理的な階層になっているかを検証します。
  • リンクとボタンテキスト: すべてのインタラクティブ要素に、記述的で一意なアクセシブルネームが付いていることを確認します。「click here」や「learn more」が何十回も繰り返されているような状態は避けます。
  • フォームのアクセシビリティ: すべてのフィールドに明示的なラベルがあること、エラーメッセージが具体的でプログラム的に関連付けられていること、必須フィールドが支援技術で伝えられる形で示されていることを確認します。
  • 色とコントラスト: 自動ツールが不確実とフラグを立てたテキストや UI コンポーネントを手動で確認します。2026年の WebAIM Million レポートでは、83.9% のホームページでコントラスト不足のテキストが見つかっており、これは最も一般的なアクセシビリティの失敗です。
  • タッチターゲットのサイズ: WCAG 2.2 SC 2.5.8 は、インタラクティブターゲットを少なくとも 24×24 CSS ピクセル（推奨ベストプラクティスは 44×44 ピクセル）とすることを求めています。小さなボタン、アイコンのみのリンク、モバイルナビゲーション要素を確認します。
  • ズームとリフロー: ブラウザーのズームを 200% と 400% にしてテストします。400% でも横スクロールなしでコンテンツがリフローする必要があります（WCAG SC 1.4.10）。

スクリーンリーダーテスト：実ユーザー体験に最も近い代理

スクリーンリーダーテストはアクセシビリティプログラムの中で最も負荷が高い一方、最も多くを明らかにしてくれます。スクリーンリーダーユーザーは、ウェブページをテキストとセマンティック情報の線形なストリームとして体験します。視覚的なレイアウトは関係ありません。見出し、ランドマーク、リスト、テーブル、フォームラベル、ARIA ロールがナビゲーションの骨格です。この骨格が壊れていたり欠けていたりすると、自動チェックをどれだけ通過していても、そのページは事実上使い物になりません。

2023年末から2024年初頭にかけて実施された WebAIM Screen Reader User Survey によると、JAWS は依然として最も一般的に挙げられるデスクトップの主要スクリーンリーダーで、回答者の 40.5% を占めています。NVDA は 37.7% で僅差で続きます。VoiceOver はデスクトップの主要市場で 9.7% を占めるにとどまりますが、モバイルデバイスでは圧倒的なスクリーンリーダーであり、モバイルスクリーンリーダーユーザーの 70.6% が利用しています。つまり、包括的なテストプログラムでは最低限、Windows 上の Chrome と NVDA、Windows 上の Chrome と JAWS、そして iOS 上の Safari と VoiceOver をカバーすべきです。

主要なスクリーンリーダーの概要

JAWS（Job Access With Speech、Freedom Scientific 開発）は、何十年にもわたりエンタープライズ環境におけるゴールドスタンダードであり続けています。Microsoft Office との深い統合、非標準アプリケーション向けの高度なスクリプティング、AI による画像説明などを備えています。JAWS は有償ライセンス（標準ライセンスは約 $1,000、家庭向けサブスクリプションは年 $95 程度）を必要とするため、カジュアルなテストには導入しづらいものの、プロフェッショナルなスクリーンリーダーユーザー向けにエンタープライズレベルのワークフローが機能するかを検証するには不可欠です。

NVDA（NonVisual Desktop Access）は無料かつオープンソースで、何百万人ものユーザーに信頼されています。機能セットは、日常的なウェブ利用の大半において JAWS に匹敵するまでに成長しており、USB ドライブから任意の Windows マシン上で実行できるポータビリティにより、スクリーンリーダーテストを始める多くの開発チームにとって実用的な選択肢となっています。NVDA と Chrome の組み合わせは、実利用において2番目に一般的なスクリーンリーダーとブラウザーの組み合わせです。

VoiceOver はすべての macOS および iOS デバイスに標準搭載されており、インストールは不要です。デスクトップでは Safari との組み合わせが最適です。iPhone や iPad では、他を大きく引き離す主要スクリーンリーダーです。サイトにモバイルトラフィックが多い場合—そして多くのサイトがそうですが—iOS 上の VoiceOver はテストマトリクスに必須です。タッチスクリーンでのジェスチャーベースのナビゲーションモデルは、デスクトップのキーボードナビゲーションとは意味のある違いがあり、モバイル特有のアクセシビリティ問題は、実際の iOS デバイスでテストしなければ発見できません。

TalkBack は Google の Android 向けスクリーンリーダーで、モバイルスクリーンリーダーユーザーのおよそ 35% に利用されています。オーディエンスに Android ユーザーが含まれる場合、TalkBack によるテストもモバイルアクセシビリティプログラムの一部とすべきです。

効果的なスクリーンリーダーテストの進め方

まず、モニターを消すか目を閉じてください。目的は、画面を見ることができない人の体験を疑似的に再現することです。スクリーンリーダーのコマンドだけを使ってページをナビゲートします。NVDA と JAWS では、特に重要なナビゲーションパターンは次のとおりです。矢印キーや「すべて読み上げ」コマンドでページを線形に読み進めること。H キーで見出し間を移動すること。NVDA では D、JAWS では ; を使って main、navigation、footer などのランドマーク間を移動すること。インタラクティブ要素だけを Tab で移動すること。そしてフォームモードを使って入力フィールドとやり取りすることです。

ナビゲートしながら、次の点を自問してください。読み上げ順序は論理的か。ページタイトルは読み上げられたときに意味をなしているか。画像は意味のある形で説明されているか、それとも文脈なしに「image」とだけ読み上げられていないか。フォームフィールドはラベル、種類、現在値を読み上げているか。エラーのある状態でフォームを送信したとき、エラーメッセージは読み上げられ、簡単に見つけられるか。動的コンテンツが更新されたとき—通知バナー、ローディング状態、検索結果数など—その更新は、ユーザーが戻って探しに行かなくてもよいようにアナウンスされているか。

スクリーンリーダーは、読み上げモード、フォームモード、アプリケーションモードなど、異なるモードでの操作を可能にしており、それぞれでまったく異なる結果を生むことがあります。ある要素が一方のモードでは正しく動作しても、別のモードでは何のエラーもなく失敗することがあります。同じインタラクションは、必ず複数のナビゲーションモードでテストしてください。

現代のウェブアプリケーションで最も一般的かつ深刻な失敗の1つが、フォーカス管理の破綻です。モーダルダイアログが開いたとき、フォーカスはその中に移動しなければなりません。閉じたとき、フォーカスはそれをトリガーした要素に戻る必要があります。シングルページアプリケーションが新しいビューに遷移したとき、ページタイトルとメイン見出しは読み上げられなければなりません。フォーム送信時にエラーが発生した場合、フォーカスはエラーサマリーまたは最初の不正なフィールドに移動すべきです。これらのパターンは、どの自動ツールでも検証できません。スクリーンリーダーを起動したテスターが必要です。

長く続くアクセシビリティテストプログラムを構築する

組織が犯しがちな最も一般的な誤りは、アクセシビリティテストを一度きりの監査として扱うことです。今日合格したサイトでも、コンテンツの公開、機能のリリース、サードパーティスクリプトの更新に伴い、明日には新たな違反が生じます。アクセシビリティは、開発ライフサイクルに継続的なプラクティスとして組み込まれるべきであり、定期的なチェックボックスであってはなりません。

持続可能なプログラムには、並行して動く3つのレイヤーがあります。自動レイヤーはすべてのコードコミットで実行され、本番に到達する前にリグレッションを検出します。手動レイヤーは、新機能の開発に合わせてスプリントごとに実行されます。最後のゲートではなく、開発中のチェックとして行うのです。支援技術レイヤーは、フォーム、ナビゲーションの変更、モーダル、動的コンテンツ、ユーザーフローなど、重要なインタラクションパターンを含む機能の受け入れテストの一部として実行されます。多くのチームにとって、それは少なくとも Chrome 上の NVDA と iOS 上の VoiceOver を意味します。

優先順位付けも重要です。監査で50件の問題が見つかったとしても、そのすべてが同じ重みを持つわけではありません。WCAG の違反は影響度によって分類されます。コンテンツを一部のユーザーにとって完全に利用不能にする「重大」な問題は、「深刻」な問題よりも先に修正すべきであり、深刻な問題は「中程度」や「軽微」な問題よりも優先されます。まずはページタイプ全体に影響するパターンに注目してください。ナビゲーションがキーボードユーザーにとって壊れているなら、ナビゲーションテンプレートを修正すれば、すべてのページで一度に改善できます。フォームのエラーハンドリングがアクセシブルでないなら、そのパターンを修正することで、すべてのフォームが改善されます。

コンプライアンス担当者にとって、ドキュメント化は必須です。どのページをテストしたか、どのツールや支援技術を使用したか、どの違反が見つかったか、どのような是正措置をいつ実施したかを記録するアクセシビリティテストログを維持してください。このドキュメントは、アクセシビリティ監査や法的手続きの際に、適合を達成・維持するための継続的な誠実な取り組みを示すうえで非常に重要な証拠となります。

テスト戦略におけるオーバーレイウィジェットの役割

Accsible SDK のようなアクセシビリティオーバーレイウィジェットは、多層的なアクセシビリティ戦略の中で意味のある役割を果たします。特に、より深い是正作業が進行中の間に、既存コンテンツに対して即時の改善を提供する必要がある組織にとって有用です。適切に実装されたオーバーレイは、テキストサイズの変更、コントラスト調整、キーボードナビゲーションの強化など、一般的な障壁に対処する支援ツールをユーザーに提供し、サイト全体を作り直すことなくプレゼンテーションレイヤーの問題を軽減できます。

しかし、オーバーレイはテストの代わりにはなりません。テストプログラムを置き換えるのではなく、補完するものです。最も効果的なアプローチは、オーバーレイを使ってプログラム的に対処可能な表層的・プレゼンテーションレイヤーの問題を解消しつつ、自動スキャン、手動テスト、スクリーンリーダー検証を用いて、コードレベルの修正を要する構造的な問題—壊れたセマンティクス、欠落した ARIA ロール、アクセシブルでないカスタムウィジェットなど—を特定・是正することです。オーバーレイが最も効果を発揮するのは、基盤となるコードベースがすでにテストされており、残っているギャップが根本的なインタラクション障壁ではなく、ユーザープリファレンスの領域にある場合です。

オーバーレイを含むあらゆるアクセシビリティツールを評価する際には、それが実際のスクリーンリーダーでテストされているかどうかを確認してください。見た目にはアクセシビリティツールバーを提供していても、ページにフォーカストラップや ARIA の競合を生み出してしまうウィジェットは、状況を改善するどころか悪化させています。このガイドで紹介したテスト手法は、ツールが動作するサイトだけでなく、アクセシビリティツールそのものにも適用されます。

重要なポイント

  • 単一のツールだけでは不十分です。 自動スキャナーが検出できる WCAG 違反は 30〜40% に過ぎません。完全なプログラムには、自動テスト、手動レビュー、実際の支援技術テストが、補完的なレイヤーとして連携することが必要です。
  • アクセシビリティを左にシフトさせましょう。 axe-core や Pa11y を CI/CD パイプラインに統合すれば、違反は本番に到達する前に検出されます。本番での修正は、時間、評判、法的リスクの面で指数関数的にコストが増大します。
  • ユーザーが実際に使っているスクリーンリーダーでテストしましょう。 デスクトップでは NVDA + Chrome と JAWS + Chrome が主流であり、モバイルでは iOS 上の VoiceOver が支配的です。最低限これらの組み合わせをカバーし、モーダル、フォームエラー、SPA のルート変更など、自動ツールでは決して検出できない動的インタラクションをテストしてください。
  • 個別の事例ではなくパターンを修正しましょう。 見出し構造が壊れているなら、テンプレートを修正します。フォームのエラーハンドリングがアクセシブルでないなら、コンポーネントを修正します。体系的な修正は、場当たり的なパッチよりも桁違いに大きな価値をもたらします。
  • アクセシビリティテストを「継続的」にし、「定期的」にとどめないこと。 今日の監査に合格したサイトも、時間とともに劣化します。すべてのコミットでの自動テスト、すべてのスプリントでの手動テスト、すべての重要な機能に対する支援技術テストを開発ライフサイクルに組み込めば、アクセシビリティは「是正プロジェクト」ではなく、プロダクトの維持される特性となります。