ci-cd

CI/CD アクセシビリティスキル

正規のソース：mgifford/ACCESSIBILITY.md の examples/CI_CD_ACCESSIBILITY_BEST_PRACTICES.md このスキルはそのファイルをもとに作成されています。判断に迷った場合は、例を正としてください。 正規のガイドには、このスキルとの同期は自動ではないと記載されています。 定期的にこのファイルを正規のガイドと照合してください。

CI/CD のアクセシビリティチェックを追加、レビュー、または保守する際は、以下のルールを適用してください。

監査時に AI スキルと自動スキャナーを使い分ける方法については、 このリポジトリの AI_AUDIT_GUIDE.md を参照してください。

---

中核となる原則

CI は、既知のアクセシビリティ上のリグレッションを防ぎ、テスト済みのセマンティクスを維持し、人によるレビューのための証拠を作成できます。**CI だけで WCAG への適合を立証することはできません。**自動ルール、スコア、スナップショット、AI の出力はアクセシビリティ評価の入力であり、評価の代わりにはなりません。このガイドでは、対象範囲内のコンテンツについて WCAG 2.2 AA を目標としますが、この目標自体は適合を主張するものではありません。この AA の目標のもとで確認された AAA レベルの指摘は、プロジェクトが特定の基準を明示的に required に引き上げない限り、デフォルトで advisory ではなく obligation: aspirational（目に見える、ブロックしない挑戦目標）となります。

原則：ページの読み込みだけでなく、ユーザーのタスク全体と関連する状態をテストすること。高速で決定論的なチェックをローカルで実行し、CI でも繰り返すこと。明示的でレビュー可能なルールを使って既知のリグレッションをブロックすること。アクセシビリティ、パフォーマンス、セキュリティ、機能のシグナルを区別すること。最終的にレンダリング、サニタイズ、最適化された出力をテストすること。重大度、代替手段、例外、リリース判断は人が担うこと。ワークフローとエージェントには、タスクに必要な最小限の権限を与えること。

---

重大度の尺度（このスキル）

レベル	意味
Critical	中核的なタスク、または安全性が重要なタスクを完了できず、妥当なアクセシブルな代替手段もない
Serious	主要なタスクが妨げられる、または安全でない、信頼性の低い、もしくは大きな負担を伴う回避策が必要となる
Moderate	タスクは引き続き実行可能だが、大きな困難、混乱、遅延、または情報の損失が生じる
Minor	影響は限定的で、タスクは理解可能かつ操作可能なままである

ツールのラベル（axe の critical／serious／moderate／minor、Lighthouse のスコア）はトリアージのための入力であり、プロジェクトの重大度ではありません。実際に影響を受けるタスクへのユーザーの影響を評価した後にのみ、この分類に対応付けてください。

---

多層テストモデル

アクセシビリティ要件をすべて網羅するツールはありません。影響を受けるタスクとリグレッションの可能性および影響の大きさに応じて、レイヤーを選択してください。

レイヤー	有効な対象	立証できないこと
静的解析／リンター	検出可能なソースパターンへの迅速なフィードバック	実行時の挙動や最終出力
ユニット／コンポーネントテスト	安定したコンポーネントの契約（名前、ロール、状態）	ページ全体の読み上げやフォーカス順
ブラウザのルールスキャン（axe-core）	レンダリングされた状態で検出可能なルール	WCAG の完全な網羅性やユーザビリティ
セマンティックアサーション（ロールクエリ、ARIA スナップショット）	アクセシビリティツリーの構造と変更	スクリーンリーダーによる正確な読み上げ
視覚チェック	テーマ／レイアウトのリグレッション、フォーカスインジケーター	意味、キーボード操作、またはテキストによる代替
エンドツーエンドテスト	操作性、フォーカス、状態の変化、エラー	それ自体では支援技術との相互運用性
手動テストと支援技術によるテスト	品質、順序、操作、互換性	すべての構成における普遍的な挙動

自動化では完了できないチェックには、skills/manual-testing/SKILL.md を使用してください。

---

重要：ツールを選ぶ前に CI の契約を定義する

各チェックについて、対象となるユーザータスク／ページ／コンポーネント／状態、コマンドと設定ファイル、ツール／ブラウザー／ランタイム／ルールセットのバージョン、結果が警告するのか、ブロックするのか、成果物のみを生成するのか、ベースライン／期待される結果、失敗時の担当者と対応プロセス、既知の誤検知と未テストの要件、レビュー用に保持する証跡を記録します。

ブランチ保護で実際に必須とされていない限り、チェックをマージゲートとして説明してはいけません。警告を失敗として説明してはいけません。

スコアは適合率ではありません。 Lighthouse のアクセシビリティスコアが 100 でも、WCAG への適合率が 100％という意味ではありません。また、90 でもページのアクセシビリティが 90％という意味ではありません。これは、Lighthouse が単一の設定で実行した監査項目に重み付けした結果です。リグレッションの調査には、個々の監査結果を使用してください。スコアのしきい値は追加のシグナルとして使えますが、それだけをゲートにしてはいけません。チームがブロック対象と決めた特定のルール／タスクについても失敗と判定してください。パフォーマンス予算は分けて管理してください。パフォーマンススコアによってアクセシビリティの深刻度を上げたり下げたりしてはいけません。

{
  "ci": {
    "collect": { "staticDistDir": "./_site", "numberOfRuns": 1 },
    "assert": {
      "assertions": { "categories:accessibility": ["warn", { "minScore": 0.9 }] }
    },
    "upload": { "target": "filesystem", "outputDir": ".lighthouseci" }
  }
}

これは警告であり、ブロックはしません。調査後にしきい値を引き上げたり、"error" に変更したりすることは有効な場合がありますが、それでもしきい値が適合性を証明するわけではありません。

---

重要：あらゆる PR で、さまざまな状態と設定を対象に axe-core を実行する

ページの準備が整った後、さらに関連する操作の後にも、意味のある状態をスキャンしてください。ユーザーがメニューを開いたり、フォームを送信したり、別の操作を完了したりする必要がある場合、初期ルートだけをスキャンしてはいけません。

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

const colorSchemes = ['light', 'dark'] as const;

for (const colorScheme of colorSchemes) {
  test(`home page in ${colorScheme} mode`, async ({ page }) => {
    await page.emulateMedia({ colorScheme });
    await page.goto('/');
    await expect(page.getByRole('main')).toBeVisible();

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

test('navigation is tested while expanded', async ({ page }) => {
  await page.goto('/');
  await page.getByRole('button', { name: 'Menu' }).click();
  await expect(page.getByRole('navigation', { name: 'Main' })).toBeVisible();

  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

スキャンで違反が見つからなかった場合でも、それはテスト対象の範囲内で違反が見つからなかったという意味にすぎません。障壁が存在しないことを意味するわけではありません。PR で axe-core のチェックが欠けている場合は重大です。カラースキームのテストが欠けている場合も、未テストのスキームでのみテーマ固有のリグレッションが発生することが多いため、カバレッジの不足にあたります。

不必要に高コストな組み合わせを避けつつ、該当する組み合わせをカバーしてください。デスクトップと狭い画面へのリフローが必要なビューポート、システム／ライト／ダークのテーマ、デフォルトと高コントラスト、強制カラー、視差効果の低減、デフォルト／ホバー／フォーカス／アクティブ／無効／読み込み中／成功／エラーの各状態、サインイン済み／サインアウト／タイムアウト／権限の各状態を対象にします。通常の変更ではペアワイズ法またはリスクベースのカバレッジを使用し、リスクの高いコンポーネント（認証、決済、安全性、主要なナビゲーション）ではすべての組み合わせをテストしてください。

---

重大：セマンティックアサーションと ARIA スナップショット

ロールとアクセシブルネームに基づくクエリは、有用な契約となります。

test('contact form exposes its controls and error', async ({ page }) => {
  await page.goto('/contact');
  const email = page.getByRole('textbox', { name: 'Email address' });
  await expect(email).toBeVisible();
  await page.getByRole('button', { name: 'Send message' }).click();
  await expect(page.getByText('Enter an email address')).toBeVisible();
  await expect(email).toHaveAttribute('aria-invalid', 'true');
});

test('main navigation retains its semantic structure', async ({ page }) => {
  await page.goto('/');
  await expect(page.getByRole('navigation', { name: 'Main' }))
    .toMatchAriaSnapshot(`
      - navigation "Main":
        - list:
          - listitem:
            - link "Home"
    `);
});

スナップショットの変更をレビューしてください。機械的に更新してはいけません。ARIA スナップショットが表すのはアクセシビリティツリーであり、すべてのスクリーンリーダーが読み上げる内容の記録ではありません。音声出力は、支援技術製品、ブラウザー、OS、設定、モード、ユーザーの操作にも左右されます。

Guidepup の仮想スクリーンリーダー（ユニットレベル、正確な読み上げ出力）：

import { virtual } from '@guidepup/virtual-screen-reader';

it('announces the dialog title and action buttons', async () => {
  document.body.innerHTML = `
    <dialog open aria-labelledby="dlg-title">
      <h2 id="dlg-title">Confirm deletion</h2>
      <button>Delete</button>
    </dialog>`;
  await virtual.start({ container: document.body });
  const spoken = await virtual.spokenPhraseLog();
  expect(spoken).toContain('Confirm deletion');
  await virtual.stop();
});

---

重大：ビジュアルおよびユーザー設定のリグレッションテスト

ビジュアルテストでは、テキストの切り詰め、フォーカスインジケーターの欠落、テーマ固有のコントラストの変化、リフローのリグレッションを検出できます。実質的に異なるテーマや強制カラーの動作については、レビュー済みのベースラインを個別に維持してください。スクリーンショットの一致だけをコントラストテストに使用してはいけません。アンチエイリアス、透明度、グラデーション、レンダリングの違いにより、ピクセル比較の信頼性が低くなるためです。コントラストが重要な箇所では、計算後の色を確認し、目視でも検査してください。テストの再現性を高めるために視差効果の低減をエミュレートしても、スクリーンショットを通すためだけに製品からアニメーションを削除してはいけません。

重要：リスク指標とビルドゲート

Reflow リスクや Focus Visible テストなどの動作チェック（skills/behavioral-a11y/SKILL.mdを参照）が示すのは指標であり、適合性の判定ではありません。ターゲットごとの偽陽性確率がわずかであっても、多数のページ、コンポーネント、状態、ビルドにわたると累積します。また、ウェブサイトでの検出結果は、共有テンプレートやコンポーネント全体で相関することがよくあります。すべての指標をビルドをブロックする失敗に変換すると、ノイズが多く信頼性の低い CI となり、根本にあるパターンを修正する代わりにチェックを回避するよう促してしまいます。

結果	CI でのデフォルトの扱い
確定的に確認された失敗	ブロックする場合があります
レビュー済みのベースラインに対して確認された回帰	ブロックする場合があります
リスク指標	報告し、レビューに回します
cantTell	カバレッジが不完全であることを報告します
テストエラー	スキャンの健全性に関する失敗として報告します
レビュー済みの例外	レビューの有効期限が切れるまではブロックしません

結果が機械可読であるという理由だけで、自動的にブロックするよう定めてはいけません。初めて検出されたリスク指標はレビューされておらず、規範上の例外（たとえば、SC 1.4.10 の二次元レイアウトの例外）に該当しないことも確認されていません。これを根拠にブロックすると、未レビューのシグナルを確認済みの失敗として扱うことになります。

「CI でのデフォルトの扱い」をpolicy.handlingに対応付けます。確定的に確認された失敗またはレビュー済みの回帰はreport（ブロックする場合があります）、リスク指標またはcantTellは、人が確認または却下するまでreviewとし、決してsuppressにしてはいけません。レビュー済みの例外をsuppressにするのは、以下に示す抑制の詳細をすべて記録する場合に限ります。handlingはobligationとは独立しています。CI での扱いを、根拠となる標準がrequiredかどうかの代わりに使ってはいけません。あるターゲットのノイズが多いという理由で、ルールやエンジン全体を無効にしてはいけません。代わりに、対象を限定した個別の検出結果を抑制してください。アクセシビリティ検出結果の追跡：ポリシーの分類を参照してください。

フリート全体およびサイト全体のスキャンでは、さらに次のことが必要です。影響を受けるインスタンスと根本原因のクラスターを区別し、それぞれを報告すること（影響を受ける URL ごとに問題を一つずつ報告しないこと）。重大度を決める前に、新しい検出結果をレビュー済みのベースラインと比較すること。スキャンに使用した検出器、ブラウザー、ベースラインのバージョンを記録すること。レビュー済みの例外すべてに、担当者、理由、有効期限を設定すること。また、偽陰性を調査するため、一見問題がない結果を定期的にサンプリングすること。検出結果のないチェックも、偽陰性がゼロであると証明されたわけではありません。

上記で使用しているフィクスチャ／PR／定期スキャンの実施頻度、および一意の検出結果、影響を受けるインスタンス、影響を受けるページ、根本原因のクラスターの定義については、skills/behavioral-a11y/SKILL.mdを参照してください。

---

重要：CI ワークフローのセキュリティ

アクセシビリティのワークフローにも、ビルド／デプロイのワークフローと同じ制御を適用してください。

• サードパーティのアクションはタグではなく、レビュー済みの完全なコミット SHA に固定してください — タグは変更される可能性がありますが、コミット SHA は変更されません
• ワークフローまたはジョブのレベルで、最小限の GITHUB_TOKEN 権限を明示的に宣言してください
• 後続のステップで Git アクセスが不要な場合は、チェックアウト時に persist-credentials: false を設定してください
• 信頼できない PR コードを実行するワークフローでは pull_request_target を避けてください
• 信頼できない値は環境変数またはファイルを通して渡し、シェルの展開は引用符で囲んでください — 実行可能なスクリプトのテキストに直接埋め込まないでください
• フォークや信頼できないコードにシークレットを公開しないでください
• 実用的な場合は、AI／変換ステップのネットワークアクセスとツールを制限してください
• タイムアウト、同時実行の制御、上限付きのクロール制限を追加してください
• アップロードされた HTML、JSON、スクリーンショット、トレース、ログは機密情報を含む可能性があるものとして扱ってください
• アーティファクトの保持期間は、レビューに必要な期間を超えないようにしてください
• デプロイや外部システムの変更が可能なワークフローには、環境と必須レビュー担当者を設定してください
• トークンの権限、イベントコンテキスト、ツール、プラットフォームの制御によって実際に確認できない限り、ワークフローが「シークレットにアクセスできない」または「マージできない」と断言しないでください

name: Accessibility checks

on:
  pull_request:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read

concurrency:
  group: accessibility-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  accessibility:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - name: Check out repository
        uses: actions/checkout@<reviewed-full-commit-sha>
        with:
          persist-credentials: false
      - name: Set up Node.js
        uses: actions/setup-node@<reviewed-full-commit-sha>
        with:
          node-version-file: .nvmrc
          cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npm run build
      - run: npm run test:a11y:ci
      - name: Upload debugging evidence after failure
        if: failure()
        uses: actions/upload-artifact@<reviewed-full-commit-sha>
        with:
          name: accessibility-test-evidence-${{ github.run_id }}
          path: test-results
          retention-days: 7

有効化する前に、現在の公式ドキュメントでアクションと入力が存在することを確認し、各アクションのリリースを完全なコミット SHA に解決し、依存するアクションのコードとリリースノートをレビューしてください。また、信頼できない PR に特権シークレットが渡されないようフォーク時の動作を検証し、ビルドの経路が本番環境と一致していることを確認したうえで、まずテストブランチでワークフローを実行してください。

---

重大：定期スキャンと GitHub Accessibility Scanner

定期スキャンでは、変化、依存関係の変更、PR テストで見落とされたページを検出できます。既知の問題が残っていても、スキャンを継続してください — 問題が一つ開いているだけで毎回スキャンを一時停止すると、新たなリグレッションが見えなくなる可能性があります。アラート疲れを理由に一時停止するよりも、重複排除、安定したフィンガープリント、明確な担当者の設定を優先してください。

各定期スキャンでは、許可された対象 URL とクロール範囲、公開状態と認証済み状態、頻度／タイムアウト／リソース制限、Issue の重複排除とクローズの動作、レポートの保持と秘匿化、トリアージの担当者、スキャナーまたは対象が利用できない場合の動作を定義してください。認証シークレット、セッションデータ、機密コンテンツをログ、Issue 本文、アーティファクト、AI プロンプトに含めないでください。

GitHub Accessibility Scanner（github/accessibility-scanner）はパブリックプレビュー中のアクションであり、インターフェース、権限、Copilot との連携が変更される可能性があります — 導入する直前に、最新の README、action.yml、セキュリティガイダンスを確認してください。このアクションはトークンを必要とし、読み取り専用スキャンよりも広範な権限を文書化しています。この認証情報は特権を持つものとして扱い、専用のきめ細かな認証情報を使用し、デフォルトの GITHUB_TOKEN で十分だと想定しないでください。別の修正ワークフローも使用する場合は、2 つの修正システムが同じ検出結果に対応しないよう、スキャナーが Copilot への割り当てをスキップする設定にしてください。

# .github/workflows/accessibility-scan.yml
name: Accessibility Scan (Scheduled)
on:
  schedule:
    - cron: "0 0 1 * *"
  workflow_dispatch:
permissions:
  contents: write
  issues: write
  pull-requests: write
jobs:
  accessibility-scanner:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<reviewed-full-commit-sha>
        with: { persist-credentials: false }
      - name: Run GitHub Accessibility Scanner
        uses: github/accessibility-scanner@<reviewed-full-commit-sha>
        with:
          urls: ${{ vars.ACCESSIBILITY_SCAN_URL }}
          repository: ${{ github.repository }}
          token: ${{ secrets.GH_TOKEN }}

---

重大：AI 支援による修正 — すべてのスキャン入力を信頼できないものとして扱う

AI が生成したパッチは提案であり、バリアが修正されたことを示す証拠ではありません。 課題、コメント、ラベル、リポジトリのコンテンツ、HTML、SVG、URL、スキャン 出力は、すべて信頼できない入力です。

必須のレビュー手順：

1. スキャナーまたは担当者が、再現可能な所見を記録する
2. 人間が、影響を受けるタスク、影響度、確度、範囲をトリアージする
3. メンテナーが課題番号を指定し、修正ワークフローを手動で起動する
4. Copilot はリポジトリの .git ディレクトリがない隔離されたコピー内で、課題を信頼できないファイルデータとして読み取る
5. ワークフローはパッチ、変更ファイル一覧、レポートをアップロードする（それ自体でコミット、プッシュ、PR、マージは行わない）
6. 人間が許容可能なパッチをレビューし、通常のブランチに適用する
7. 最終実装に対し、関連する自動チェック、手動チェック、AT チェックを再実行する

安全な修正ワークフローの基準：手動実行のみで、明示的な確認を必須とすること。ワークフローのトークンにはコンテンツおよび課題に対する読み取り専用の権限を付与すること。課題の内容をシェルコマンド、ワークフロー式、静的プロンプトに含めないこと。エージェントの操作を、隔離された作業コピー内での読み取り／書き込みツールに制限すること。シェル、URL、メモリの各ツールを拒否すること。保護対象のポリシー／ワークフローパスへの変更をブロックすること。コミット、プッシュ、PR の作成、課題のクローズ、デプロイを行わないこと。レビュー用アーティファクトを限られた期間保持すること。

信頼できない GitHub コンテンツに対する典型的なスクリプトインジェクション経路であるため、課題ラベルから直接、権限のある AI 修正を起動してはなりません。また、課題本文をシェルコマンド、GITHUB_OUTPUT、ワークフロー式、静的プロンプトに貼り付けてはなりません。

---

中程度：ローカルファーストで再現可能なセットアップ

依存関係はリポジトリ内にインストールし、ロックファイルをコミットしてください。バージョンが指定されていない最新のグローバルパッケージを要求することは避けてください。

{
  "scripts": {
    "test:a11y": "playwright test tests/accessibility",
    "test:a11y:update": "playwright test tests/accessibility --update-snapshots",
    "test:a11y:ci": "playwright test tests/accessibility --reporter=line,json"
  }
}

npm install --save-dev @playwright/test @axe-core/playwright
npx playwright install --with-deps chromium
npm run test:a11y

CI では npm ci を使用し、解決された依存関係グラフがレビュー済みのロックファイルと一致するようにしてください。

---

中程度：シフトレフト戦略

問題はフィードバックが速いものから遅いものへ順に検出してください。（1）フレームワーク固有の a11y ルールを使ったエディター内／ローカルの lint、（2）変更ファイルのみを対象とするコミット前ゲート（husky+lint-staged または pre-commit。合計実行時間は ≤30–60s に抑える）、（3）CI で再実行する PR ゲート。ブロッキングするリグレッションがあれば失敗させ、アーティファクトへのリンクを公開すること、（4）所見への自動ラベル付けと傾向指標を含む、定期的な詳細スキャン。UI に影響するコミットは、ローカル／コミット前チェックに合格し、PR の CI チェックがすべて成功しない限り、受け入れてはなりません。

---

ベースライン、抑制、例外

既存の所見を割り当てて修正する間は、新たなリグレッションを防ぐことを優先してください。ベースラインは一時的な一覧であり、既存のバリアが許容可能であることの証明ではありません。抑制／例外には、次のすべてを含めてください。影響を受ける正確なルール／ファイル／要素／ルート／タスク、理由と裏付けとなる証拠、ユーザーへの影響と利用可能な回避策、責任者とリンクされた課題、有効期限またはレビュー日、そして実用上可能な最も限定された範囲。レビュー済みの一例だけが例外である場合に、ルール全体を抑制してはなりません。CI を成功させることだけを目的に、スナップショットやベースラインを更新してはなりません。

これは policy.suppression に求められる詳細（範囲、理由、証拠、責任者、レビュー日または有効期限）と同じです。機械可読な所見では、この用語を使用してください。抑制は決して解決ではありません。抑制された所見も記録に残り、指定されたレポートまたは適用の対象からのみ除外されます。

---

持続可能な自動化

すべての PR で高速かつ対象を絞ったチェックを実行し、全件クロールと大規模なブラウザーマトリックスは、定期実行、リリース、またはリスクの高い変更のために確保してください。更新を見えなくしてしまうことなく高速化できる場合は、レビュー済みの依存関係をキャッシュしてください。必要な証拠を破棄できない場合は、古くなった実行をキャンセルしてください。アーティファクトの保持期間は必要な範囲に限ってください。同じ証拠を提供するスキャナーの重複は避けてください。質問に答えられる場合は、AI より先に決定論的なツールを使用してください。

---

完了の定義チェックリスト

• 各チェックについて、影響を受けるユーザータスク、ページ、コンポーネント、状態が定義されている
• 依存関係、ブラウザー、アクション、設定のバージョンが管理され、レビュー可能である
• 最終的にレンダリングされた出力をテストしている（ソーステンプレートだけではない）
• 該当するテーマ、設定、ビューポート、インタラクション状態を網羅している
• 自動化の結果を、文書化された制限の範囲内で解釈している （スコア ≠ 適合性、ツールの重大度 ≠ プロジェクトの重大度）
• 必須の手動テストとATテストを完了しているか、正確に引き継いでいる
• 新たな重大および深刻な障壁を、認識しながら導入していない
• 検出結果に、再現可能な証拠と担当者が含まれている
• 抑制と例外が限定的で、正当化され、追跡され、日付が記録されている
• ワークフローの権限、信頼されていない入力の処理、シークレット、アーティファクトをレビューしている
• アクションの参照にはタグではなく、レビュー済みの完全なコミット SHA を使用している
• 後続のステップで Git アクセスが不要な箇所では、persist-credentials: false を設定している
• 信頼されていない PR コードを実行するワークフローでは、pull_request_target を避けている
• AI による修正ワークフローは手動トリガーのみで、トークンのスコープは読み取り専用、 シェル／URL／メモリツールを拒否し、自身でコミット／プッシュ／マージを行わない
• 本番環境で使用する前に、テストブランチで最終的なワークフローを検証している
• ドキュメントとこのスキルを同期させている（自動ではありません）

---

WCAG の主要な基準（自動化による検出範囲）

• 1.1.1 テキスト以外のコンテンツ（A）— axe-core／Lighthouse で検出可能
• 1.3.1 情報と関係性（A）— axe-core で検出可能
• 1.4.3 コントラスト（最低限）（AA）— Lighthouse／axe-core で検出可能（視覚的な確認も必要）
• 4.1.2 名前、役割、値（A）— axe-core と aria スナップショットで検出可能
• 4.1.3 ステータスメッセージ（AA）— axe-core で部分的に検出可能

自動化でカバーできる WCAG の問題は、多く見積もっても約 30～40％です。手動テストと 支援技術によるテストを組み合わせてください。skills/manual-testing/SKILL.md を参照してください。

---

参考資料

• ベストプラクティスの完全ガイド
• skills/behavioral-a11y/SKILL.md — リフローリスクとフォーカス可視化リスクの指標、結果の用語、規模拡大時の誤検出に関するガイダンス
• シフトレフト自動化ガイド
• GitHub Accessibility Scanner の統合
• GitHub Actions の安全な使用に関するリファレンス
• GitHub：スクリプトインジェクション
• Lighthouse CI のドキュメント
• axe-core/playwright
• Playwright aria スナップショット
• Guidepup 仮想スクリーンリーダー
• GitHub Accessibility Scanner

標準の対象範囲： これらのルールは WCAG 2.2 AA を対象としています。 https://www.w3.org/TR/wcag-3.0/ を監視してください。