WCAG 2.2チェックリスト｜A・AA全55項目と確認方法・axe検査手順

WCAG 2.2 のチェックリストとは、W3C のウェブアクセシビリティ指針 WCAG 2.2（2023年10月5日勧告、2024年12月12日更新版）の達成基準を、レベル A・AA の 55 項目（廃止された 4.1.1 を含めると 56 行）について「何を・どう確認し・どう直すか」まで落とし込んだ一覧です。 各項目に「自動・手動・両方」の確認区分、axe-core 4.13.0 の対応ルール名、NG → OK の HTML を付けました。

さらに、違反を意図的に含めたサンプルページを Playwright 1.56.1 + @axe-core/playwright 4.13.0 で検査した実行出力、修正後の再検査で 0 件になるまでの流れ、Tab キーでフォーカス順を記録した結果、コントラスト比を計算する Python の出力を載せています。すべて実際に動かした結果です。

WCAG 2.2 チェックリストの早見表

WCAG 2.2 A・AA 全項目チェックリスト（確認方法・axe ルール・NG → OK）

「確認」列は axe-core 4.13.0 のルールで検出できるかを基準に、自動（ルールでほぼ判定できる）、両方（一部を検出し、残りは目視）、手動（ルールがない）に分けています。 「exp」は experimental（既定で実行されない実験的ルール）、「既定無効」は axe.run() の既定では動かないルール（タグやルール名で明示すると動く。後述）です。名称は WAIC の WCAG 2.2 日本語訳に合わせました。

1. 知覚可能（20 項目）

2. 操作可能（20 項目）

3. 理解可能（13 項目）

4. 堅牢（2 項目 + 廃止 1）

集計： 55 項目のうち「自動」1、「両方」19、「手動」35。自動検査で手がかりが得られるのは 20 項目（36%） で、残りは人が操作して確かめます（Deque の 57% は課題の件数ベースで、測り方が違います）。

WCAG 2.2 で追加された 9 基準の確認手順（2.1 からの差分）

WCAG 2.1 で AA 対応済みのサイトが 2.2 に上げるとき、新たに見る項目は AA までなら 6 つです。2.5.8 の target-size 以外は axe-core にルールがないため、手順を決めておくと確認が速くなります。

4.1.1 構文解析は廃止されました。2.2 に対しては確認不要で、2.0 / 2.1 への適合を報告する場合も正誤表で「HTML・XML では常に満たすとみなす」とされています。axe-core 4.13.0 でも duplicate-id は既定で無効です（id の重複が ARIA 参照を壊す問題は duplicate-id-aria が 4.1.2 の観点で検出します）。

Playwright + axe-core で自動検査する手順（実行結果つき）

自動検査の最短ルートは、Playwright で開いたページに @axe-core/playwright を当てることです。 Node 22.22 / Playwright 1.56.1 / @axe-core/playwright 4.13.0（内蔵 axe-core 4.13.0）で実行しました。

npm install playwright@1.56 @axe-core/playwright@4.13.0
# Chromium が未導入なら: npx playwright install chromium

検査対象：違反を意図的に含めたサンプル（bad.html）

python3 -m http.server 7740 で配信し、http://localhost:7740/bad.html として検査しました。

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">
  <style>
    .note { color: #999999; background: #ffffff; }
    .btn-small { width: 16px; height: 16px; padding: 0; border: 1px solid #ccc; background: #eee; }
    a:focus, button:focus { outline: none; }
  </style>
</head>
<body>
  <img src="logo.png">
  <a href="/"><img src="home-icon.png" alt=""></a>
  <h1>備品の予約</h1>
  <h3>予約フォーム</h3>
  <p class="note">※ 予約は1人3件までです。</p>
  <form action="/reserve" method="post">
    <input type="text" placeholder="備品名">
    <input type="email" placeholder="連絡先メール" autocomplete="mail-address">
    <select><option>会議室A</option><option>会議室B</option></select>
    <input type="checkbox" id="agree"> 利用規約に同意する
    <div onclick="submitForm()" style="color:#0a5fd0; cursor:pointer;">送信</div>
  </form>
  <p>
    <button class="btn-small" type="button"></button>
    <button class="btn-small" type="button"></button>
    <button class="btn-small" type="button"></button>
  </p>
  <div aria-labelledby="missing-id" role="region"><p>お知らせ: 今月の点検日は第2金曜日です。</p></div>
  <ul>
    <li><a href="/items">こちら</a></li>
    <li><a href="/items/1" tabindex="5">詳細</a></li>
  </ul>
</body>
</html>

検査スクリプト（scan.mjs）と実行結果

// scan.mjs — 実行: node scan.mjs http://localhost:7740/bad.html
import { chromium } from 'playwright';
import { AxeBuilder } from '@axe-core/playwright';

const browser = await chromium.launch();
const context = await browser.newContext(); // browser.newPage() 直接では動かない（後述）
const page = await context.newPage();
await page.goto(process.argv[2]);
const results = await new AxeBuilder({ page })
  .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa']) // WCAG 2.2 AA までに絞る
  .analyze();
await browser.close();

const nodes = results.violations.reduce((n, v) => n + v.nodes.length, 0);
console.log(`axe-core ${results.testEngine.version} | violations: ${results.violations.length} rules / ${nodes} nodes | incomplete: ${results.incomplete.length}`);
for (const v of results.violations) console.log(`${v.id} | ${v.impact} | ${v.nodes.length} | ${v.tags.filter(t => /^wcag\d{3,4}$/.test(t))}`);
for (const i of results.incomplete) console.log(`incomplete: ${i.id} | ${i.nodes.length}`);

$ node scan.mjs http://localhost:7740/bad.html
axe-core 4.13.0 | violations: 11 rules / 17 nodes | incomplete: 1
autocomplete-valid | serious | 1 | wcag135
button-name | critical | 3 | wcag412
color-contrast | serious | 1 | wcag143
document-title | serious | 1 | wcag242
html-has-lang | serious | 1 | wcag311
image-alt | critical | 1 | wcag111
label | critical | 1 | wcag412
link-name | serious | 1 | wcag244,wcag412
meta-viewport | moderate | 1 | wcag144
select-name | critical | 1 | wcag412
target-size | serious | 5 | wcag258
incomplete: aria-valid-attr-value | 1

つまずき： browser.newPage() でページを作ると analyze() が次のエラーで止まります。browser.newContext() → context.newPage() の順にすると解決します。

Error: Please use browser.newContext()
 Please check out https://github.com/dequelabs/axe-core-npm/blob/develop/packages/playwright/error-handling.md
    at AxeBuilder.analyze (.../node_modules/@axe-core/playwright/dist/index.mjs:218:13)

ノード単位のメッセージ（violations[n].nodes[m].any[0].message）には、直すための数値がそのまま入っています。

color-contrast  Element has insufficient color contrast of 2.84 (foreground color: #999999, background color: #ffffff,
                font size: 12.0pt (16px), font weight: normal). Expected contrast ratio of 4.5:1
target-size     Target has insufficient size (16px by 16px, should be at least 24px by 24px)
incomplete      ARIA attribute element ID does not exist on the page: aria-labelledby="missing-id"

この出力から、自動検査の性格が 3 つ読み取れます。

• placeholder="備品名" のテキスト入力は label に引っかからず、チェックボックスだけが検出されました。axe は placeholder をアクセシブルな名前として受け入れるため、見える <label> を付けるかは手動で判断します（3.3.2）
• <div onclick> の「送信」と a:focus{outline:none} は検出されません。キーボード操作（2.1.1）とフォーカスの可視化（2.4.7）は手動確認の領域です
• aria-labelledby="missing-id" は violations ではなく incomplete（判定保留）に入ります。レポートでは incomplete も必ず出力します

修正して再検査

11 ルールをチェックリスト表の NG → OK のとおりに直し（lang="ja"、<title>、user-scalable=no の削除、alt、color:#595959、<label> と autocomplete="email"、ボタンに aria-label と min-width:24px; min-height:24px、リスト内リンクに display:inline-block; padding:4px 0）、手動確認の分として <div onclick> を <button type="submit"> に、outline:none を :focus-visible のスタイルに、tabindex="5" を削除、aria-labelledby の参照先を実在する <h2 id="news-heading"> にしました。

$ node scan.mjs http://localhost:7740/good.html
axe-core 4.13.0 | violations: 0 rules / 0 nodes | incomplete: 0

既定設定で走らせたときとの違い（target-size と best-practice）

タグを指定せず new AxeBuilder({ page }).analyze() とすると結果が変わります。 同じ bad.html での比較です。

default  : 14 rules -> autocomplete-valid, button-name, color-contrast, document-title, heading-order,
           html-has-lang, image-alt, label, landmark-one-main, link-name, meta-viewport, region, select-name, tabindex
withRules: target-size 5 nodes

既定では best-practice ルール（heading-order、landmark-one-main、region、tabindex）が混ざり、逆に target-size は走りません。axe-core 4.13.0 で既定無効なのは target-size、duplicate-id、duplicate-id-active、audio-caption、color-contrast-enhanced、aria-roledescription、identical-links-same-purpose、landmark-complementary-is-top-level、meta-refresh-no-exceptions の 9 ルールで、withTags() か withRules(['target-size']) で明示すると実行されます。WCAG のタグを明示して「適合に関わる違反」を 0 にし、best-practice は別枠で扱うと、2.5.8 を見落としません。

自動で検出できる範囲の目安と、手動確認の手順

axe-core の開発元 Deque は、2021年3月10日公開の調査で「自動テストはアクセシビリティ課題の 57% を検出できる」と報告しています。 2,000 件超の監査、13,000 ページ超、約 30 万件の課題を対象に、達成基準の数ではなく課題の件数で測った結果です。

"when we shifted the definition of 'accessibility coverage' beyond the number of WCAG Success Criteria to total volume of issues, the true impact of automated testing became clear"（カバー率の定義を達成基準の数から課題の総量に変えたとき、自動テストの本当の効果が明らかになった）

つまり 件数では半分以上を自動で拾えますが、項目では 55 のうち 35 が手動です。次の 5 つを型にすると、1 ページ 15〜30 分で回せます。

キーボード確認の一部は Playwright で記録できます。 Tab を押すたびに document.activeElement のタグ・type・名前を出力する 15 行ほどのスクリプトで、bad.html は次のようになりました。

$ node taborder.mjs http://localhost:7740/bad.html
 1: a "詳細"
 2: a ""
 3: input[text] ""
 4: input[email] ""
 5: select[select-one] "会議室A 会議室B"
 6: input[checkbox] ""
 7: button[button] ""
 8: button[button] ""
 9: button[button] ""
10: a "こちら"

tabindex="5" の「詳細」が最初に来て（2.4.3）、名前のないリンクとボタンが並び（4.1.2）、<div onclick> の「送信」には一度もフォーカスが当たりません（2.1.1）。修正後の good.html では「送信」ボタンに 7 番目で到達し、順序も見た目どおりになりました。

コントラスト比を計算する（Python、4.5:1 / 3:1 の判定）

コントラスト比は WCAG 2.2 の定義どおり「相対輝度」から計算できます。 sRGB 各成分を 0〜1 にして 0.04045 以下なら 12.92 で割り、それ以外は ((値 + 0.055) / 1.055) の 2.4 乗。相対輝度 L = 0.2126R + 0.7152G + 0.0722B、コントラスト比 = (L1 + 0.05) / (L2 + 0.05)（L1 は明るい方）です。

# contrast.py — WCAG 2.2 のコントラスト比を計算して 4.5:1 / 3:1 / 7:1 を判定（Python 3.11、標準ライブラリのみ）
def linear(c: int) -> float:
    s = c / 255
    return s / 12.92 if s <= 0.04045 else ((s + 0.055) / 1.055) ** 2.4

def luminance(hex_color: str) -> float:
    h = hex_color.lstrip("#")
    r, g, b = (int(h[i:i + 2], 16) for i in (0, 2, 4))
    return 0.2126 * linear(r) + 0.7152 * linear(g) + 0.0722 * linear(b)

def contrast(fg: str, bg: str) -> float:
    l1, l2 = sorted((luminance(fg), luminance(bg)), reverse=True)
    return (l1 + 0.05) / (l2 + 0.05)

def judge(ratio: float) -> str:
    return " / ".join(f"{name}:{'OK' if ratio >= th else 'NG'}"
                      for name, th in [("AA通常(4.5)", 4.5), ("AA大・UI(3)", 3.0), ("AAA(7)", 7.0)])

for fg, bg in [("#999999", "#ffffff"), ("#767676", "#ffffff"), ("#0a5fd0", "#ffffff"), ("#ff9800", "#ffffff")]:
    r = contrast(fg, bg)
    print(f"{fg} on {bg}: {r:.2f}:1  {judge(r)}")

$ python3 contrast.py
#999999 on #ffffff: 2.85:1  AA通常(4.5):NG / AA大・UI(3):NG / AAA(7):NG
#767676 on #ffffff: 4.54:1  AA通常(4.5):OK / AA大・UI(3):OK / AAA(7):NG
#0a5fd0 on #ffffff: 5.90:1  AA通常(4.5):OK / AA大・UI(3):OK / AAA(7):NG
#ff9800 on #ffffff: 2.16:1  AA通常(4.5):NG / AA大・UI(3):NG / AAA(7):NG

axe が報告した #999999 の 2.84 と、この計算の 2.85 は丸めの違いです。白地のグレーは #767676 が 4.5:1 を満たす最も明るい値（4.54:1）なので、注記の色の下限として覚えておくと便利です。オレンジ（#ff9800）はアイコンや枠線に使っても 3:1 に届かないため、濃くするか輪郭線を足します。

JIS X 8341-3:2016 と 2024年4月の法改正との関係

JIS X 8341-3:2016 の達成基準は WCAG 2.0（ISO/IEC 40500:2012）と同一です。 2.1・2.2 で追加された基準は JIS に含まれないため、WCAG 2.2 AA を満たしていれば JIS の AA 相当も満たし、追加基準の分だけ 2.2 の方が広い関係になります（JIS 向けの試験結果では 4.1.1 を「満たす」として報告します）。

2024年4月1日施行の改正障害者差別解消法では、民間事業者にも「合理的配慮の提供」が義務化されました（それまでは努力義務）。ウェブアクセシビリティの事前対応は同法の「環境の整備」に位置づけられ、こちらは努力義務のままです。つまり WCAG や JIS への準拠そのものが法的義務になったわけではありませんが、個別の求めに応じて代替手段を用意する義務はあり、サイトが使える状態であるほど合理的配慮の負担は小さくなります。

優先順位の付け方（影響が大きい順）とチーム運用（PR でのチェック）

55 項目を一度に満たそうとせず、「使えない」を先に、「使いにくい」を後に直します。 axe の impact（critical / serious / moderate / minor）は目安になり、最終的な順位はページの役割で決めます。

ページの順番は「全ページ共通部品（ヘッダー・フッター・ナビ）→ フォームなど目的達成に必須のページ → アクセス上位ページ」の順に直すと、1 回の修正で効く範囲が最大になります。

PR ごとの自動検査（@playwright/test）

自動検査は PR のたびに回し、「WCAG タグの違反 0 件」をマージ条件にします。 @playwright/test 1.56.1 で、baseURL を http://localhost:7740 にした設定で実行しました。

// tests/a11y.spec.mjs — PR ごとに回す WCAG 2.2 AA の自動検査
import { test, expect } from '@playwright/test';
import { AxeBuilder } from '@axe-core/playwright';

const WCAG_AA = ['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'];

for (const path of ['/good.html', '/bad.html']) {
  test(`WCAG 2.2 AA の自動検査: ${path}`, async ({ page }) => {
    await page.goto(path);
    const results = await new AxeBuilder({ page }).withTags(WCAG_AA).analyze();
    // 失敗時に「どのルールが何件」かが一目でわかる形にして比較する
    const summary = results.violations.map(v => `${v.id} (${v.impact}) x${v.nodes.length}`);
    expect(summary).toEqual([]);
  });
}

$ npx playwright test
  ✓  1 tests/a11y.spec.mjs:8:3 › WCAG 2.2 AA の自動検査: /good.html (686ms)
  ✘  2 tests/a11y.spec.mjs:8:3 › WCAG 2.2 AA の自動検査: /bad.html (657ms)

    Error: expect(received).toEqual(expected) // deep equality
    - Expected  -  1
    + Received  + 13
    - Array []
    + Array [
    +   "autocomplete-valid (serious) x1",
    +   "button-name (critical) x3",
    +   "color-contrast (serious) x1",
    +   "document-title (serious) x1",
    +   "html-has-lang (serious) x1",
    +   "image-alt (critical) x1",
    +   "label (critical) x1",
    +   "link-name (serious) x1",
    +   "meta-viewport (moderate) x1",
    +   "select-name (critical) x1",
    +   "target-size (serious) x5",
    + ]
  1 failed
  1 passed (2.7s)

violations をそのまま toEqual([]) と比べると失敗時の差分が巨大な JSON になります。「ルール id (impact) x件数」の配列に変換してから比べると、PR のログだけで何を直せばよいかがわかります。CI では npm ci → npx playwright install --with-deps chromium → 検査対象をローカル起動 → npx playwright test tests/a11y.spec.mjs の順で動かします（CI 自体はこの記事の検証環境では実行していません）。

よくある質問

Q. 目標は AA と AAA のどちらにすべきですか？ A. 一般的には AA です。W3C 自身が、AAA はすべてのコンテンツで満たせるとは限らないため、方針として全体に AAA を求めることを推奨していません。まず A・AA の 55 項目を満たし、AAA は 1.4.6 コントラスト（高度）など効果の大きいものを選んで加えます。

Q. axe で違反 0 件なら WCAG 2.2 に準拠したと言えますか？ A. 言えません。この記事の区分では 55 項目中 35 項目は手動確認が必要で、Deque も課題の件数ベースで約 57% が自動検出の範囲としています。0 件は「手動確認に進める状態」と考えます。

Q. WCAG 2.1 で AA 対応済みのサイトは、2.2 で何を追加すればよいですか？ A. AA までなら 2.4.11、2.5.7、2.5.8、3.2.6、3.3.7、3.3.8 の 6 項目です。4.1.1 は廃止されたので確認不要です。固定ヘッダー、ドラッグ操作、小さいアイコンボタン、ログイン画面、複数ステップのフォームがあるページから見ると効率的です。

Q. placeholder だけのフォームは axe を通りましたが、問題ありませんか？ A. axe の label ルールは placeholder をアクセシブルな名前として受け入れますが、入力を始めると消え、拡大時に読みにくくなるため、見える <label> を付けることを推奨します。自動検査を通ることと、3.3.2 を十分に満たすことは別物です。

まとめ

• WCAG 2.2 は全 86 項目、目標にする A・AA は 55 項目（廃止の 4.1.1 を含めると 56 行）。2.2 で 9 項目が追加され、AA までの追加は 6 項目
• 自動検査で手がかりが得られるのは 55 項目中 20 項目。Deque の調査でも件数ベースで約 57% なので、手動確認は必須
• axe-core はタグを明示して実行する。既定では best-practice が混ざり、2.5.8 の target-size は走らない
• @axe-core/playwright は browser.newContext() 経由のページが必須。newPage() 直接では "Please use browser.newContext()" で止まる
• 手動確認は 5 つの型（キーボード・200%/400% 拡大・320px リフロー・コントラスト・スクリーンリーダー）。Tab 順の記録は Playwright で補助できる
• コントラストは相対輝度から計算できる。白地のグレーは #767676 が 4.5:1 の下限、UI 部品は 3:1
• JIS X 8341-3:2016 は WCAG 2.0 相当。2024年4月の法改正は合理的配慮の義務化であり、WCAG 準拠の義務化ではない

株式会社RJCでは、アクセシビリティの自動検査と手動確認をプロジェクトの中で仲間と学び合い、誰もが使える画面づくりを実践しています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。