アクセシビリティテストの進め方：自動検査から手動確認、支援技術、CI/CD運用まで

greeden

1年前

Webアクセシビリティとは、障害の有無、年齢、利用環境にかかわらず、必要な情報や機能を使えるように設計する考え方です。

その品質は、自動検査だけでも、公開直前の目視確認だけでも判断できません。

自動検査、手動確認、支援技術による確認、ユーザーテストを組み合わせ、要件定義から運用まで同じ判定基準を使う必要があります。

Webアクセシビリティの基本と最初に確認する領域を先に整理したい場合は、基礎記事もあわせて参照してください。

アクセシビリティテストの要点

自動検査は、機械が判定できる問題を繰り返し確認するために使います。
手動確認は、キーボード操作、フォーカス順、拡大時の表示など、実際の振る舞いを確かめるために使います。
支援技術による確認は、見出し、フォーム、状態変化が利用者へ正しく伝わるかを確かめるために使います。
ユーザーテストは、基準への適合だけでは見つけにくい迷いや認知負荷を観察するために使います。
CI/CDと受け入れ基準へ組み込み、変更による品質低下を継続的に検知します。

4層のテストが補い合う範囲

四つの方法は優劣で選ぶものではなく、検出できる問題の違いに応じて重ねます。

テスト層	確認すること	見つけやすい問題	限界
自動検査	HTMLや実行中の画面をルールで検査	ラベル不足、ARIAの不整合、構造上の問題	文言の分かりやすさや操作全体の妥当性は判断しにくい
手動確認	キーボード、拡大、色、動き、モバイル操作を確認	フォーカスの迷子、表示の重なり、操作不能	確認者の手順と経験によって結果が揺れやすい
支援技術による確認	スクリーンリーダーや拡大機能で主要フローを操作	読み順、名前、役割、状態変化の伝達不良	利用環境の組み合わせを無制限には試せない
ユーザーテスト	利用者が目的を達成する過程を観察	専門用語、予測しにくい動作、過度な認知負荷	参加者の結果だけで全利用者を代表することはできない

回帰とは、変更前には使えていた機能が、別の修正の影響で使えなくなることです。

自動検査を継続的に実行し、手動確認と支援技術による確認を変更範囲に応じて繰り返すと、回帰を公開前に見つけやすくなります。

対象範囲と終了条件を先に決める

テストを始める前に、対象ページ、利用環境、合格条件を決めます。

対象範囲が曖昧なままでは、確認したページと未確認のページを区別できず、結果の説明もできません。

優先するページと操作

最初に、利用者の目的達成へ直結する流れを選びます。

トップページから目的の情報へ移動する。
検索結果や一覧から詳細ページを開く。
フォームへ入力し、エラーを修正して送信する。
アカウントへログインし、設定を変更する。
商品を選び、購入確認まで進む。

すべてのページを同じ深さで調べるのではなく、利用頻度、事業上の重要度、操作できない場合の影響をもとに優先順位を付けます。

利用環境の組み合わせ

PC、スマートフォン、ブラウザ、支援技術の組み合わせは、実際の利用状況とサービスの対象者をもとに選びます。

例として、WindowsとNVDA、macOSまたはiOSとVoiceOver、AndroidとTalkBackを候補にし、画面幅の縮小、文字の拡大、ダーク表示、動作削減の設定も確認します。

受け入れ基準

受け入れ基準（DoD）とは、作業を完了と判断するための具体的な条件です。

WCAG 2.2の追加達成基準と実務上の読み方も確認し、採用する版と適合レベルをプロジェクト内でそろえます。

対象にした自動検査で、合意した重大度の違反が残っていない。
主要シナリオをキーボードだけで完了できる。
見出し、ランドマーク、フォームのラベル、エラーが支援技術へ論理的に伝わる。
拡大や狭い画面幅でも、必要な情報と操作が欠けたり重なったりしない。
既知の制約、未確認の環境、残っている問題を記録している。

自動検査の違反が0件でも、WCAGへの適合や利用しやすさ全体を保証するわけではありません。

自動検査を開発工程へ組み込む

自動検査は、ルールとして表現できる問題を、同じ条件で繰り返し調べる方法です。

コンポーネント、画面、サイト内の複数ページという単位ごとに検査を配置すると、問題が入り込んだ場所を切り分けやすくなります。

対象	ツール例	役割
コンポーネント	Jestとjest-axe	部品単位の基本的な違反を検出する
画面操作	Playwrightとaxe、Cypressとcypress-axe	表示後の画面と主要操作を検査する
複数ページ	pa11y-ci	登録したURLをまとめて検査する
品質指標	Lighthouse CI	継続的な計測としきい値の監視に使う

コンポーネントの検査例

import { axe, toHaveNoViolations } from 'jest-axe';
import { render } from '@testing-library/react';
import Button from '../Button';

expect.extend(toHaveNoViolations);

test('Buttonに自動検出できる違反がない', async () => {
  const { container } = render(<Button>送信</Button>);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

このテストが通っても、「送信」という文言が画面の目的に合うか、操作後の結果が利用者へ伝わるかまでは判断できません。

画面単位の検査例

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

test('トップページをaxeで検査する', async ({ page }) => {
  await page.goto('http://localhost:3000/');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa'])
    .analyze();

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

実際の導入では、認証、データ準備、検査対象、除外理由をテストコードと運用記録に残します。

複数ページを検査する設定例

{
  "defaults": {
    "standard": "WCAG2AA",
    "timeout": 30000,
    "concurrency": 4
  },
  "urls": [
    "http://localhost:3000/",
    "http://localhost:3000/search",
    "http://localhost:3000/contact"
  ]
}

コード例のURL、実行コマンド、しきい値は、対象システムの構成と利用しているツールの版に合わせて調整してください。

手動確認で見る8項目

手動確認は「見た感じに問題がない」で終わらせず、操作と期待結果をチェック項目にします。

キーボード操作：TabとShift+Tabで論理的な順に移動でき、EnterやSpaceで操作できるかを確認します。
フォーカス表示：現在位置が常に見え、モーダルを閉じた後に起点へ戻るかを確認します。
コントラストと色：文字、アイコン、境界線、エラー、フォーカス表示を確認し、色だけに意味を持たせていないかを調べます。
画像と代替テキスト：情報を伝える画像には目的に合う代替テキストを付け、装飾画像は読み上げ対象から外します。
見出しとランドマーク：見出し階層とheader、nav、main、aside、footerの役割が内容の構造と一致するかを確認します。
拡大とリフロー：文字や画面を拡大しても、内容の欠落、重なり、意図しない横スクロールが起きないかを確認します。
動きと点滅：動作削減の設定を尊重し、停止できない動きや危険な点滅がないかを確認します。
モバイル操作：タッチ対象の大きさと間隔、画面の向き、複雑なジェスチャーの代替操作を確認します。

キーボード操作を詳しく確認する場合は、キーボード操作とフォーカス表示の実務手順も役立ちます。

モーダルを確認する例

「お問い合わせ」ボタンでモーダルを開く場合は、開閉できるかだけでなく、次の一連の振る舞いを確認します。

ボタンへキーボードで移動し、EnterまたはSpaceで開く。
モーダルのタイトルまたは最初に操作すべき要素へフォーカスが移る。
モーダルの外へ不用意にフォーカスが抜けない。
Escで閉じる。
開くために使ったボタンへフォーカスが戻る。

このように、開始条件、操作、期待結果を一続きで書くと、確認者が変わっても判定をそろえやすくなります。

支援技術で主要フローを確かめる

支援技術とは、スクリーンリーダーや画面拡大など、情報の取得や操作を補助する技術です。

スクリーンリーダーでは、画面の見た目を読み上げるのではなく、HTMLから得られる名前、役割、状態、構造を利用者へ伝えます。

見出し一覧だけで、ページの内容と順序を把握できるか。
ランドマークを使って、ナビゲーションや本文へ移動できるか。
入力欄のラベル、補足、必須状態、エラーが関連付けられているか。
ダイアログの名前と状態が伝わり、開閉後のフォーカス位置が適切か。
検索結果や保存完了などの更新が、必要なタイミングで伝わるか。

role="status"とrole="alert"は通知の緊急度が異なるため、すべての更新を強い割り込みとして扱わないようにします。

読み上げ確認の実装まで調べる場合は、スクリーンリーダーと読み上げ環境の検証項目を参照してください。

ユーザーテストで実利用の障壁を見つける

ユーザーテストは、参加者が目的を達成する過程を観察し、迷い、誤操作、理解しにくい表現を見つける方法です。

WCAGへの適否を判定する試験とは目的が異なるため、両者を置き換えることはできません。

目的を決める：キーボードだけで購入確認まで進めるかなど、検証したい行動を一つに絞ります。
現実的なタスクを書く：商品検索、カートへの追加、住所入力、確認というように、普段の利用に近い流れにします。
参加条件を決める：支援技術、端末、利用経験など、対象サービスに関係する条件を整理します。
同意と記録方法を説明する：画面、音声、発言を記録する範囲と利用目的を事前に伝えます。
行動を観察する：完了の可否だけでなく、止まった場所、戻った操作、誤解した表現を記録します。

進行役は参加者の能力を試すのではなく、サイトの設計を検証していると説明し、必要以上に答えを誘導しないようにします。

問題を修正できるレポートへ変える

指摘は一件ずつチケットに分け、再現から修正確認まで同じ情報を使えるようにします。

項目	記載内容	例
What	観察した事実	Tab移動がヘッダー内で循環し、本文へ進めない
Where	URL、画面、部品、再現経路	トップページのグローバルナビゲーション
Why	利用者への影響	キーボード利用者が主要内容へ到達できない
Which	対応する基準や社内要件	採用したWCAG達成基準と受け入れ基準
How	修正案と期待結果	本文へ移動するスキップリンクを追加する
Evidence	確認に使える証跡	動画、スクリーンショット、HTML断片、読み上げ記録

優先度は「基準番号が若いから高い」といった形式ではなく、目的を完了できるか、影響する利用者が多いか、回避手段があるか、危険があるかをもとに決めます。

P1：主要な目的を完了できない、情報を取得できない、または安全上の危険がある。
P2：主要な流れを大きく妨げ、現実的な回避手段が限られる。
P3：回避手段はあるが、操作や理解に継続的な負担が生じる。
P4：改善候補として記録し、次の設計や改修時に扱う。

CI/CDと定期確認を組み合わせる

CI/CDとは、コードの変更を継続的に検査し、ビルドや公開の工程へつなげる仕組みです。

アクセシビリティ検査を品質ゲートとして置くと、既知の問題が再び混入した場合や、新しい違反が加わった場合に変更を確認できます。

name: accessibility-ci
on: [push, pull_request]

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

これは構成例であり、利用中のNode.js、各アクション、検査ツールの対応版とプロジェクトの起動方法を確認してから採用します。

検査を失敗させる条件は、既存サイトの問題数、変更範囲、誤検知の扱いを踏まえて段階的に決めます。

タイミング	実施例
コード変更ごと	コンポーネント検査、主要画面の自動検査
リリース前	変更範囲の手動確認、主要シナリオのキーボード操作、支援技術によるスモークテスト
大規模改修時	対象範囲を広げた手動確認、複数環境での支援技術確認
定期的な改善時	ユーザーテスト、既知課題の再評価、受け入れ基準の見直し

スモークテストとは、主要機能が大きく壊れていないかを短時間で確かめる確認です。

頻度は固定の正解ではないため、変更の大きさ、利用者への影響、チームの体制に応じて決めます。

受け入れ基準のチェックリスト

☐ 採用するWCAGの版、適合レベル、対象ページを記録した。
☐ 自動検査の対象、重大度、除外理由を記録した。
☐ 主要シナリオをキーボードだけで完了できた。
☐ フォーカスの移動と表示を確認した。
☐ 見出し、ランドマーク、フォーム、エラーを支援技術で確認した。
☐ 拡大、狭い画面幅、動作削減、画面の向きを確認した。
☐ 変更箇所に対応する回帰テストを追加または更新した。
☐ 既知の制約と残課題をリリース記録へ残した。

運用をチームへ定着させる

テストを一度実施して終えると、画面追加や文言変更のたびに判断基準が失われます。

コンポーネントごとに、名前、役割、状態、キー操作、フォーカス、コントラストの仕様を持たせ、設計、実装、テストで共有します。

アクセシブルなデザインシステムの仕様と運用へ落とし込むと、同じ部品を使う画面で判断を再利用できます。

デザインレビューでは、色、ラベル、状態変化、フォーカス順を確認する。
実装時は、部品単位の自動検査と主要操作のテストを追加する。
レビュー時は、検査結果だけでなく、キーボード操作と読み上げを確認する。
公開後は、問い合わせとユーザーテストの結果を課題台帳へ追加する。
残課題には、影響、回避手段、担当、再確認の時期を付ける。

よくある質問

自動検査が0件なら、手動確認は不要ですか

不要にはなりません。

自動検査は、ルールで判定できる範囲を繰り返し調べるものであり、文言の理解しやすさ、フォーカスの流れ、操作後の納得感までは判断できないためです。

すべての支援技術を毎回確認する必要がありますか

対象者と利用状況をもとに代表環境を決め、変更ごとのスモークテストと、改修時の詳しい確認を分けます。

未確認の環境がある場合は、確認済みの範囲と一緒に記録します。

既存サイトの問題が多く、CIをすぐ必須化できません

変更した範囲で新しい問題を増やさない条件から始め、重大な既存問題を優先順位に沿って減らします。

除外は固定せず、理由、影響、見直し時期を記録します。

アクセシビリティテストを品質管理の流れにする

アクセシビリティテストの目的は、検査結果を並べることではなく、利用者が情報を取得し、操作を完了できる状態を保つことです。

自動検査で繰り返せる問題を早く見つけ、手動確認と支援技術で実際の振る舞いを確かめ、ユーザーテストで基準だけでは見えにくい障壁を捉えます。

その結果を受け入れ基準、CI/CD、課題台帳へ戻せば、担当者の経験だけに依存しない改善サイクルになります。

アクセシビリティは、公開前の一度きりの検査ではなく、要件、実装、テスト、改善をつなぐ運用課題です。株式会社greedenは、Webアクセシビリティチェックサービスを通じて、現状の確認から継続的な改善の第一歩まで支援しています。