accessibility-testing

アクセシビリティテスト

このスキルにより、エージェントは Web ページやコンポーネントを対象に、Web Content Accessibility Guidelines（WCAG）2.1 の適合レベル AA および AAA に照らした徹底的なアクセシビリティ監査を実施できます。エージェントは、「知覚可能」「操作可能」「理解可能」「堅牢」の 4 つの原則に関する違反を特定し、具体的なコード修正を含む構造化された適合レポートを作成します。自動チェック（色のコントラスト、代替テキストの欠落、ARIA の誤用）、半自動チェック（キーボード操作のフロー、フォーカス管理）、手動チェックのガイダンス（スクリーンリーダーの読み上げ、認知負荷）を網羅します。

ワークフロー

1. 監査範囲と適合目標を定める：監査対象となるページ、コンポーネント、ユーザーフローを決め、目標を WCAG 2.1 AA（法的要件として最も一般的）または AAA（最高レベルの適合）のどちらにするかを定めます。対象とする支援技術を特定します。スクリーンリーダー（Windows の NVDA、macOS/iOS の VoiceOver、Android の TalkBack）、キーボードのみの操作、拡大ツールなどです。

2. 自動スキャンを実行する：axe-core または Lighthouse を使用して、アクセシビリティの自動分析を実行します。これらのツールでは、代替テキスト属性の欠落、色のコントラスト比の不足、フォームラベルの欠落、ID の重複、無効な ARIA ロール、ドキュメント言語の欠落など、WCAG 違反のおよそ 30～40％を自動検出できます。各違反について、WCAG の達成基準（例：1.4.3 コントラスト（最低限））、重大度（致命的、深刻、中程度、軽微）、該当する HTML 要素、CSS セレクターのパスを記録します。

3. キーボード操作をテストする：Tab、Shift+Tab、Enter、Space、Escape、矢印キーのみを使って、すべてのインタラクティブなフローを手動でたどります。フォーカス順が視覚的な順序と一致すること、フォーカスインジケーターが見えること（コントラスト比 3:1 以上の 2px 以上のアウトライン）、モーダルダイアログでフォーカスが正しくトラップされること、キーボードトラップが存在しないことを確認します。キーボードユーザーがマウスユーザーなら完了できるタスクを完了できないフローがあれば、その内容を記録します。

4. スクリーンリーダーでテストする：少なくとも 1 つのスクリーンリーダーでページを操作し、すべてのコンテンツが正しく読み上げられることを確認します。画像に意味のある代替テキスト（装飾画像には alt=""）があること、見出しが論理的な階層を形成していること（レベルを飛ばさないこと）、ランドマーク（<nav>、<main>、<aside>）が存在すること、動的コンテンツの更新が aria-live 領域を通じて通知されることを確認します。

5. 適合レポートを作成する：WCAG の原則と達成基準ごとに整理した構造化レポートを作成します。各違反について、達成基準の番号と名称、重大度、該当する要素の HTML スニペット、不適合となる理由の説明、具体的なコード修正を記載します。原則ごとの合格数と不合格数、および全体の適合に関する記述を含む概要表も作成します。

6. 修正コードを提示する：違反ごとに、具体的な修正内容を示す修正前と修正後のコードスニペットを提示します。修正を要素ごとに個別に行うのではなく、開発者が体系的に対処できるよう、コンポーネントまたはページ領域ごとに修正をまとめます。

使用方法

エージェントに URL、HTML のブロック、または React/Vue コンポーネントを渡します。目標とする適合レベル（AA または AAA）と、必要な支援技術を指定します。エージェントはコンテンツを監査し、コード修正を含む構造化レポートを返します。

例

例 1：WCAG 準拠監査レポート

ユーザーの依頼：「このログインフォームが WCAG 2.1 AA に準拠しているか監査してください。」

<div class="login">
  <img src="logo.png">
  <input type="text" placeholder="Username">
  <input type="password" placeholder="Password">
  <div class="btn" onclick="login()">Sign In</div>
  <p style="color: #aaa; font-size: 12px;">Forgot your password?</p>
</div>

エージェントの回答 — アクセシビリティ監査レポート：

#	基準	重大度	要素	問題
1	1.1.1 非テキストコンテンツ	重大	<img src="logo.png">	画像に alt 属性がありません。スクリーンリーダーで画像の内容を説明できません。
2	1.3.1 情報と関係性	重大	<input placeholder="Username">	入力欄に関連付けられた <label> がありません。プレースホルダーテキストはラベルの代わりにはなりません。
3	1.3.1 情報と関係性	重大	<input placeholder="Password">	上記と同じラベルの問題があります。
4	1.4.3 コントラスト（最低限）	深刻	<p style="color: #aaa">	白い背景に対するテキスト色 #aaa のコントラスト比は 2.32:1 です。このサイズのテキストには AA 準拠のために 4.5:1 が必要です。
5	2.1.1 キーボード	重大	<div class="btn" onclick>	<div> はキーボードでフォーカスできません。ユーザーは Tab キーでこのボタンに移動したり、ボタンを起動したりできません。
6	4.1.2 名前、役割、値	重大	<div class="btn" onclick>	要素にセマンティックな役割がありません。スクリーンリーダーではボタンではなく、汎用テキストとして読み上げられます。

修正 — 修正後のコード：

<form class="login" onsubmit="login(event)">
  <img src="logo.png" alt="Acme Corp logo">

  <label for="username">Username</label>
  <input id="username" type="text" autocomplete="username" required>

  <label for="password">Password</label>
  <input id="password" type="password" autocomplete="current-password" required>

  <button type="submit" class="btn">Sign In</button>

  <a href="/forgot-password" style="color: #595959; font-size: 14px;">
    Forgot your password?
  </a>
</form>

変更内容：画像に alt を追加し、プレースホルダーだけの入力欄を明示的な <label> 要素に置き換え、<div> をセマンティックな <button> に置き換え、リンクの色を #aaa（2.32:1）から #595959（7.0:1）に変更し、適切な送信処理のためにフォームを <form> 要素で囲み、autocomplete 属性を追加しました。

例 2：React コンポーネントの修正

ユーザーの依頼：「この React 通知コンポーネントのアクセシビリティの問題を修正してください。」

修正前（アクセシビリティに問題あり）：

function Notification({ message, onClose }) {
  return (
    <div className="notification">
      <span>{message}</span>
      <span className="close-x" onClick={onClose}>✕</span>
    </div>
  );
}

修正後（アクセシビリティ対応済み）：

function Notification({ message, onClose }) {
  return (
    <div role="alert" aria-live="assertive" className="notification">
      <p>{message}</p>
      <button
        type="button"
        onClick={onClose}
        aria-label="Dismiss notification"
        className="close-btn"
      >
        ✕
      </button>
    </div>
  );
}

適用した修正：（1）role="alert" と aria-live="assertive" を追加し、通知が表示されたときにスクリーンリーダーがすぐに読み上げるようにしました。（2）<span onClick> を <button> に置き換え、キーボードでフォーカスできるようにし、操作可能なコントロールとして読み上げられるようにしました。（3）「✕」だけではスクリーンリーダーの利用者にボタンの目的が伝わらないため、aria-label="Dismiss notification" を追加しました。（4）適切なテキストの意味付けのため、内側の <span> を <p> に変更しました。

ベストプラクティス

• まず自動化ツールを実行します。ただし、それだけに頼らないでください：axe-core で検出できる WCAG の問題はおよそ 30～40% です。残りの 60～70% には、キーボードの手動テスト、スクリーンリーダーでの確認、認知面のレビューが必要です。
• ARIA バリデーターだけでなく、実際のスクリーンリーダーでテストしてください：ARIA マークアップが正しい要素でも、読み上げが分かりにくい場合があります。VoiceOver と NVDA では、同じマークアップでも解釈が異なることがあります。
• 中程度の問題より先に、重大度が「重大」または「深刻」の問題を修正してください：アクセスを完全に妨げる違反（キーボード操作ができない、機能を持つ画像に alt テキストがないなど）を、見た目上の問題（装飾要素のコントラストがわずかに不足しているなど）より優先してください。
• ARIA を使う前にセマンティック HTML を使用してください：<button> に role="button" は不要です。<nav> に role="navigation" は不要です。ARIA はセマンティック HTML で十分でない場合に修正手段として使うものであり、セマンティック HTML の代替ではありません。
• CI パイプラインにアクセシビリティチェックを組み込んでください：自動テストで axe-core または pa11y を実行し、新たな違反が本番環境に到達する前に検出してください。重大な違反がある場合はビルドを失敗させます。
• アクセシビリティに関する判断を文書化してください：コンポーネントが意図的にガイドラインから逸脱する場合（例：カスタムのコンボボックスパターン）は、その理由と同等のアクセスを維持するために採用した代替アプローチを文書化してください。

エッジケース

• クライアントサイドルーティングを使用するシングルページアプリケーション：ページ遷移時にブラウザーのページ読み込みが発生しないため、スクリーンリーダーは新しいコンテンツの通知を受けません。ルートの変更を通知するには aria-live="polite" 領域を使用するか、新しいページの <h1> にプログラムでフォーカスを移動してください。
• 初回レンダリング後に読み込まれる動的コンテンツ：ページ読み込み後に JavaScript で挿入されたコンテンツは、aria-live 領域に含めるか、フォーカスを明示的に管理しない限り、スクリーンリーダーから認識されません。トースト通知には aria-live="assertive" を使用し、フィードの更新には aria-live="polite" を使用してください。
• 複雑なデータテーブル：セルの結合、複数階層のヘッダー、並べ替え可能な列を含むテーブルには、scope、headers、aria-sort 属性を明示的に指定する必要があります。スクリーンリーダーのユーザーが、各データセルにどのヘッダーが適用されるか理解できることを確認してください。
• カスタムのインタラクティブウィジェット（スライダー、日付選択ツール、コンボボックス）：これらには、対応するネイティブ HTML がありません。WAI-ARIA Authoring Practices 1.2 のパターンに厳密に従い、各ウィジェットの種類について指定されている完全なキーボード操作モデルを実装してください。
• サードパーティの埋め込みコンテンツ（iframe、ウィジェット）：サードパーティの iframe 内部のアクセシビリティは修正できません。問題を記録し、<iframe> に説明的な title 属性を追加してください。また、埋め込みコンテンツがユーザーフローに不可欠な場合は、アクセシブルな代替手段を用意してください。