アクセシビリティテスト完全ガイド｜WCAG 2.2対応の検証手順・ツール・自動化まで

Webサイトやアプリを公開したあと「スクリーンリーダーで読み上げられない」「キーボードだけでは操作できない」という問い合わせを受けた経験はないでしょうか。2024年4月の改正障害者差別解消法施行により、民間事業者にも合理的配慮の提供が義務化されました。Webサイトのアクセシビリティ確保は「環境の整備」として努力義務に位置づけられていますが、対応を怠ると行政指導や民事訴訟のリスクが生じます（出典: Web担当者Forum）。

アクセシビリティテストは、障害の有無・年齢・利用環境を問わず、すべてのユーザーがWebコンテンツを利用できるかを検証するプロセスです。自動ツールによる機械的なチェックと、スクリーンリーダーやキーボード操作による手動検証を組み合わせることで、WCAGやJIS規格への適合度を測定し、改善点を特定します。

アクセシビリティテストが求められる背景

法制度の動き

2024年4月1日に施行された改正障害者差別解消法では、民間事業者に対して合理的配慮の提供が法的義務となりました。Webアクセシビリティそのものは「環境の整備」として努力義務ですが、合理的配慮を適切に提供するための基盤と位置づけられています（出典: 政府広報オンライン）。

海外では、アメリカのADA（Americans with Disabilities Act）やEUのEuropean Accessibility Actに基づくWeb訴訟が年々増加しています。日本でも今後、同様の流れが進む可能性は高く、早期のアクセシビリティ対応が事業リスクの軽減に直結します。

ビジネス上のメリット

アクセシビリティ対応は法令遵守だけの話ではありません。適切な見出し構造・代替テキスト・セマンティックHTMLの使用はSEOの評価向上にも寄与します。また、高齢者や一時的な障害（骨折による片手操作など）を持つユーザーにもサービスを届けられるため、潜在的な利用者層が広がります。

WCAG 2.2とJIS X 8341-3の関係

適合レベルの構造

WCAG（Web Content Accessibility Guidelines）は、W3Cが策定する国際的なアクセシビリティ基準です。適合レベルはA・AA・AAAの3段階で構成されており、一般的にはAA準拠が求められます。

適合レベル	対象	達成基準数（WCAG 2.2）
A	最低限のアクセシビリティ要件	32
AA	標準的な対応水準（推奨）	23
AAA	最高水準の対応	31

WCAG 2.2で追加された主な達成基準

WCAG 2.2は2023年10月にW3C勧告として公開されました（出典: W3C）。WCAG 2.1から9つの達成基準が追加され、達成基準4.1.1（構文解析）が廃止されています。

追加された達成基準のうち、実務で特に影響が大きいものを挙げます。

2.4.11 フォーカスが隠されない（最小）（AA）: キーボードフォーカスを受けた要素が、作成者が配置したコンテンツによって完全に隠されないことが求められます
2.5.7 ドラッグ動作（A）: ドラッグ操作が必要な機能には、シングルポインター（クリックやタップ）で代替できる手段の提供が必須です
2.5.8 ターゲットサイズ（最小）（AA）: インタラクティブ要素のタッチ領域は最低24×24 CSSピクセルが求められます
3.3.7 冗長な入力（A）: 同一プロセス内で以前入力した情報の再入力を求める場合、自動入力または選択肢の提示が必要です

JIS X 8341-3との対応関係

JIS X 8341-3:2016は、WCAG 2.0をベースとした日本産業規格です。現在、WCAG 2.2に対応したJIS規格の改正が検討されており、2026年度中の改正が見込まれています（出典: バーンワークス）。

WCAGは後方互換性を維持しているため、現行JIS X 8341-3:2016に準拠した対応を行っていれば、改正後も大幅な手戻りは発生しません。ただし、WCAG 2.2で追加されたフォーカスの外観やターゲットサイズに関する基準は早めに取り入れておくことを推奨します。

アクセシビリティテストの全体フロー

アクセシビリティテストは「計画→自動検証→手動検証→改善→再検証」のサイクルで進めます。

ステップ1: 目標と範囲の設定

テスト開始前に、以下の3点を明確にします。

適合レベル: A・AA・AAAのどこを目標とするか（一般的にはAA）
対象ページ: サイト全体か、主要導線のみか
対応度合い: 準拠・一部準拠・配慮のいずれを目指すか

「準拠」はすべての達成基準を満たすことを意味し、「一部準拠」は一部の基準で例外を認める対応です。「配慮」はベストエフォートでの対応を指します。

ステップ2: 自動ツールによる一次検証

自動ツールで検出可能な問題（代替テキストの欠落、コントラスト比不足、見出しレベルの飛びなど）を洗い出します。自動ツールで検出できる問題はWCAG達成基準全体の約30〜40%とされており、手動検証との併用が必須です。

ステップ3: 手動テストによる二次検証

キーボード操作・スクリーンリーダー・拡大表示など、実際の支援技術を使って検証します。自動ツールでは判定できない「情報の論理的な順序」「代替テキストの適切さ」「フォーカス移動の自然さ」といった項目を確認します。

ステップ4: 問題の分類と優先度付け

検出された問題を影響度と修正コストで分類し、対応の優先順位を決定します。

優先度	基準	例
高	操作不能・情報取得不可	フォームが送信できない、画像に代替テキストがない
中	操作可能だが困難	コントラスト比が基準値をわずかに下回る
低	軽微な改善事項	見出しレベルの順序が一部不適切

ステップ5: 修正と再検証

修正後に同じテスト項目を再実行し、問題が解消されたことを確認します。新たな問題が発生していないかの回帰テストも実施します。

主要テストツールの機能比較

代表的なアクセシビリティチェックツールを、用途・対応基準・特徴で整理します。

ツール名	種別	費用	対応基準	主な特徴
axe DevTools	ブラウザ拡張	無料版あり	WCAG 2.0/2.1/2.2	誤検出が少なく開発者向け。深刻度別に問題を分類
Lighthouse	ブラウザ内蔵	無料	WCAG 2.0/2.1	Chrome DevToolsから実行可能。SEO・パフォーマンスも同時に計測
WAVE	Webサービス	無料	WCAG 2.0/2.1	問題箇所を画面上に視覚的にオーバーレイ表示
miChecker	デスクトップ	無料	JIS X 8341-3:2016	総務省提供。高齢者・視覚障害者の見え方シミュレーション搭載
Pa11y	CLI/CI連携	無料（OSS）	WCAG 2.0/2.1	コマンドラインで実行でき、CI/CDパイプラインに組み込みやすい
Siteimprove	SaaS	有料	WCAG 2.0/2.1/2.2	大規模サイトのモニタリングに対応。ダッシュボードで傾向分析

（参考: Webexpert、参考: i3DESIGN）

ツール選定の目安

個人・小規模サイト: Lighthouse + miChecker の組み合わせで十分カバーできます
中規模サイト（50〜200ページ）: WAVE + axe DevToolsでページ単位の詳細チェックを行い、miCheckerでJIS基準との照合を補完します
大規模サイト（200ページ超）: Pa11yやSiteimproveを導入し、定期的な自動スキャンで問題の早期検知を仕組み化します

ツールごとに検出ルールが異なるため、Lighthouseでスコア100であってもmiCheckerでJIS基準のエラーが検出されるケースがあります。必ず複数ツールでクロスチェックしてください。

手動テストの実施手順

自動ツールだけでは検出できない問題を洗い出すために、手動テストは不可欠です。

キーボード操作テスト

マウスを一切使わず、キーボードだけでサイトの主要操作を完了できるかを検証します。

確認項目:

Tabキーですべてのインタラクティブ要素（リンク・ボタン・フォーム）にフォーカスが到達するか
フォーカスの移動順序がコンテンツの論理的な順序と一致しているか
フォーカスインジケーター（枠線やハイライト）が視覚的に識別できるか
モーダルダイアログ内でフォーカスがトラップされ、背景要素に移動しないか
Escapeキーでモーダルを閉じられるか

スクリーンリーダーテスト

Windows環境ではNVDA（無料）、macOS環境ではVoiceOver（OS標準搭載）を使用します。

NVDAの基本操作（参考: freeeアクセシビリティガイドライン）:

操作	キー
ブラウズモード/フォーカスモード切替	NVDA + Space
次の見出しへ移動	H
次のリンクへ移動	K
次のフォーム要素へ移動	F
次のランドマークへ移動	D
要素リスト表示	NVDA + F7

※ NVDAキーのデフォルトはInsertキー

確認項目:

画像に意味のある代替テキストが設定されているか（装飾画像はalt=""で読み飛ばされるか）
見出しレベルが正しい階層構造を形成しているか（H1→H2→H3の順序）
フォームの各入力欄にラベルが紐づいているか
ページのランドマーク（nav, main, footerなど）が適切に設定されているか
動的に追加されるコンテンツ（AJAX読み込みなど）がライブリージョンとしてアナウンスされるか

色とコントラストの検証

WCAG 2.2 AA基準では、通常テキストに4.5:1以上、大きなテキスト（18pt以上、または太字14pt以上）に3:1以上のコントラスト比が必要です。

ブラウザのDevToolsでコントラスト比を直接確認できます（Chrome: 要素を選択 → Styles → カラーピッカー）
色覚特性のシミュレーションには、Chrome DevToolsのRendering → Emulate vision deficienciesが使えます
色だけに依存した情報伝達がないか確認します（例: エラーを赤色のみで示す→アイコンやテキストを併用）

CI/CDパイプラインへの組み込み

アクセシビリティテストを開発フローに組み込むことで、リリース前に問題を検出できます。

axe-coreをPlaywrightと組み合わせる例

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

test('トップページのアクセシビリティ検証', async ({ page }) => {
  await page.goto('https://example.com');

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag22aa'])
    .analyze();

  expect(results.violations).toEqual([]);
});

GitHub Actionsで定期実行する設定例

# .github/workflows/a11y.yml
name: Accessibility Test
on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 3 * * 1'  # 毎週月曜3時に実行

jobs:
  a11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test a11y.spec.js

CI/CDに組み込む際のポイントは以下の通りです。

プルリクエスト単位で実行: 新規コードのマージ前にアクセシビリティ違反を検出できます
定期スキャン: 週次などでサイト全体をスキャンし、既存ページの劣化を監視します
しきい値の設定: 初期段階ではviolationsの件数上限を設定し、段階的にゼロを目指す運用が現実的です

よくある問題と修正パターン

アクセシビリティテストで頻出する問題とその修正方法を整理します。

画像の代替テキスト不備

<!-- 修正前: 代替テキストなし -->
<img src="chart.png">

<!-- 修正後: 内容を説明する代替テキスト -->
<img src="chart.png" alt="2025年のアクセシビリティ対応率の推移を示す折れ線グラフ。1月の45%から12月の78%まで上昇。">

<!-- 装飾画像の場合: 空のalt属性 -->
<img src="decoration.png" alt="">

フォームラベルの欠落

<!-- 修正前: ラベルなし -->
<input type="email" placeholder="メールアドレス">

<!-- 修正後: label要素で紐づけ -->
<label for="email">メールアドレス</label>
<input type="email" id="email" placeholder="example@example.com">

コントラスト比不足

/* 修正前: コントラスト比 2.5:1（不合格） */
.text-light {
  color: #999999;
  background-color: #ffffff;
}

/* 修正後: コントラスト比 4.6:1（AA合格） */
.text-light {
  color: #767676;
  background-color: #ffffff;
}

フォーカスインジケーターの非表示

/* 修正前: フォーカスインジケーターを消している */
*:focus {
  outline: none;
}

/* 修正後: 視認性の高いフォーカススタイル */
*:focus-visible {
  outline: 3px solid #1a73e8;
  outline-offset: 2px;
}

ターゲットサイズの不足（WCAG 2.2新基準）

/* 修正前: タッチ領域が小さい */
.icon-button {
  width: 16px;
  height: 16px;
}

/* 修正後: 最低24×24px（WCAG 2.2 AA基準） */
.icon-button {
  min-width: 24px;
  min-height: 24px;
  padding: 4px;
}

試験結果の公開と運用

公開すべきドキュメント

JIS X 8341-3に基づく試験を実施した場合、以下の3点を公開することが推奨されています。

ウェブアクセシビリティ方針: 対象範囲、目標とする適合レベル、対応度合いを記載
試験結果: 各達成基準の適合/不適合を一覧化したチェックリスト
試験対象ページリスト: どのページを対象に試験したかの一覧

デジタル庁のウェブアクセシビリティ検証結果ページ（出典: デジタル庁）が公開フォーマットの参考になります。

継続的な運用体制

アクセシビリティテストは一度実施して完了ではありません。以下のタイミングで再検証を行う運用ルールを整備します。

コンテンツ更新時: 新規ページ追加や大幅なデザイン変更のタイミング
定期検証: 四半期ごとなど、一定周期での再テスト
フィードバック対応: ユーザーからのアクセシビリティに関する問い合わせを受けた際
基準改定時: WCAG新バージョンやJIS規格改正のタイミング

まとめ

アクセシビリティテストは、自動ツール（axe・Lighthouse・miChecker）で効率的に問題を検出し、キーボード操作やスクリーンリーダーによる手動テストで自動ツールの検出限界を補う、二段構えの検証プロセスです。

WCAG 2.2ではターゲットサイズやフォーカスの外観など、モバイル利用を意識した新基準が加わりました。JIS X 8341-3も2026年度中にWCAG 2.2ベースへ改正される見込みのため、新基準への早期対応がリスク低減につながります。

CI/CDパイプラインにaxe-coreやPa11yを組み込めば、コード変更のたびにアクセシビリティ品質を自動検証でき、問題の蓄積を防げます。まずはLighthouseとmiCheckerの2ツールで現状のスコアを把握し、優先度の高い問題から段階的に改善を進めてください。

アクセシビリティテストが求められる背景#

法制度の動き#

ビジネス上のメリット#

WCAG 2.2とJIS X 8341-3の関係#

適合レベルの構造#

WCAG 2.2で追加された主な達成基準#

JIS X 8341-3との対応関係#

アクセシビリティテストの全体フロー#

ステップ1: 目標と範囲の設定#

ステップ2: 自動ツールによる一次検証#

ステップ3: 手動テストによる二次検証#

ステップ4: 問題の分類と優先度付け#

ステップ5: 修正と再検証#

主要テストツールの機能比較#

ツール選定の目安#

手動テストの実施手順#

キーボード操作テスト#

スクリーンリーダーテスト#

色とコントラストの検証#

CI/CDパイプラインへの組み込み#

axe-coreをPlaywrightと組み合わせる例#

GitHub Actionsで定期実行する設定例#

よくある問題と修正パターン#

画像の代替テキスト不備#

フォームラベルの欠落#

コントラスト比不足#

フォーカスインジケーターの非表示#

ターゲットサイズの不足（WCAG 2.2新基準）#

試験結果の公開と運用#

公開すべきドキュメント#

継続的な運用体制#

まとめ#