アクセシビリティ監査 + 修正 PR

コース構成

このコースで学ぶこと

1. 01

   a11y は後回しになりがち

   新機能の納期に追われ、a11y は『次のスプリントで』と先送り。Claude Code で監査と修正を継続化する。

   WCAG 2.1 AA の項目は数百ありますが、自動で検出できる違反だけでも対処すれば品質は大きく改善します。axe や pa11y などの自動監査ツールを CI に組み込み、検出された違反を Claude が修正案として PR 化する流れにすれば、後回しの言い訳が消えます。

   • alt 属性の欠落
   • コントラスト不足
   • フォーカス順序の異常
   • ARIA ラベルの不足
   • 見出し階層の崩れ
   自動監査ツールの選定
2. 02

   自動監査ツールの選定

   axe-core ベースが標準。pa11y / Lighthouse CI も併用。

   bash

   # axe-core (CLI)
   npm i -D @axe-core/cli
   pnpm dlx axe https://staging.example.com --rules wcag2a,wcag2aa
   
   # pa11y
   npm i -D pa11y
   pnpm dlx pa11y https://staging.example.com --standard WCAG2AA
   
   # Lighthouse CI
   npm i -D @lhci/cli
   lhci autorun --collect.url=https://staging.example.com

   a11y は後回しになりがち監査結果から修正 PR を作る
3. 03

   監査結果から修正 PR を作る

   axe の JSON 出力を Claude に渡して、ファイル別の修正案を実装させる。

   text

   > a11y-audit.json（axe 出力）を読み込み、各違反について修正 PR を作成。
   
   ## 処理
   1. 違反を severity でソート（critical / serious / moderate / minor）
   2. critical / serious のみ自動修正（moderate 以下は別途人間判断）
   3. 各違反について:
      - 該当ファイル・行番号を特定
      - 修正案（HTML / CSS / TSX 上での具体的な変更）
      - テストを書ける場合は併せて追加
   4. ファイル単位で 1 commit、機能単位で 1 PR
   5. PR 本文に WCAG 違反項目・修正前後の比較を含める

   出力イメージ自動修正 PR の diff（抜粋）

     components/○○.tsx
   - <img src={icon} />
   + <img src={icon} alt="○○のアイコン" />
   
     components/○○.tsx
   - <div onClick={onOpen}>開く</div>
   + <button type="button" onClick={onOpen}>開く</button>
   
   # critical 3 件 / serious 5 件 を修正、moderate 4 件は人間判断へ
   …（PR 本文に WCAG 対応表を添付）

   自動監査ツールの選定Claude 自動修正の限界と人間判断
4. 04

   Claude 自動修正の限界と人間判断

   自動修正できるもの / できないもの の境界線を理解する。

   • ✅ alt 属性追加（コンテキストから推測可能）
   • ✅ ARIA ラベル追加
   • ✅ 見出し階層の修正（h1 → h2 等の置換）
   • ✅ フォーカス順序の tabindex 修正
   • ⚠ コントラスト不足（デザインシステム全体の変更が必要、勝手にやらない）
   • ❌ 構造の大改修（人間設計が必要）
   監査結果から修正 PR を作る継続的監視と Skill 化
5. 05

   継続的監視と Skill 化

   CI に組み込み、新規違反を検知 → 自動 PR、を回す。

   手を動かす

   0 / 5

   • `.github/workflows/a11y.yml` に axe + Claude のステップを追加
   • PR ごとに自動監査、新規違反が出たら Claude が修正案 PR
   • 週次で『現在の WCAG 違反数』をダッシュボード化
   • 3 ヶ月で違反数を 80% 削減を目標
   • デザインシステムレベルの問題は別途プロジェクト化

   Lv.8 — Code Review

   理解度チェック

   1. Q1.a11y 監査の自動修正 PR で、AI に任せていい範囲と人間判断が必要な範囲の境界は？

      Aalt 追加・ARIA ラベル等の局所修正は AI、コントラスト・色覚に関わる修正はデザイナーと相談B全部 AI に任せるC全部人間で対応するD見出し階層は AI、それ以外は無視する

   2. Q2.a11y 監査自動化パイプラインの目的として最も適切なのは？

      AWCAG への適合を 1 度だけ確認するBPR ごとに axe / pa11y で自動監査し、新規違反を継続的に検知 → 修正提案までを回すCサイトのデザインを刷新するDLighthouse のパフォーマンススコアを上げる

   3. Q3.a11y 自動修正 PR の入力として最も妥当なものは？

      A対象ページの URL またはビルド成果物、axe / pa11y の違反レポート、リポジトリのコードB経費精算 CSVCクライアントの個人情報DSlack の DM 履歴
   Claude 自動修正の限界と人間判断