mcpField
A
accessibility-audit

accessibility-audit

github.com/rampstackcoテスト・品質1.0k314 回インストール2 週間前に更新
リポジトリ

accessibility-audit について

製品・Webチーム向けの、技術スタックに依存しないアクセシビリティ監査スキルです。WCAG 2.1 AAを基準に、自動スキャンとキーボード、スクリーンリーダー、視覚、認知面の確認を組み合わせ、修正計画を作成します。

主な機能

  1. 01WCAGの原則に沿った監査
  2. 02自動・手動テストの併用
  3. 03重要度に基づく問題の優先付け
  4. 04レポートと修正計画の作成
  5. 05データやツール不足の記録

活用シーン

  1. 01公開前のアクセシビリティ確認
  2. 02コンプライアンス審査の準備
  3. 03監査結果や苦情への対応
  4. 04定期的なアクセシビリティ点検

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rampstackco/claude-skills --skill accessibility-audit

インストール後、Claude Code で/accessibility-auditを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
references/
aria-patterns.md
audit-report-template.md
wcag-quick-reference.md

詳細

アクセシビリティ監査

徹底したアクセシビリティ監査を実施し、改善計画を作成します。特定の技術スタックには依存しません。WCAG 2.1 AA を基準とし、該当する場合は AAA に関する注記も含めます。

このスキルでは、qa-testing や design-standards のアクセシビリティチェックよりも踏み込んだ監査を行います。アクセシビリティそのものを目標とする場合に使用してください。


使用する場合

  • リリース前のアクセシビリティ検証
  • コンプライアンス対応の準備(ADA、EN 301 549、AODA、Section 508)
  • 監査での指摘や苦情を受けた後の改善
  • 年次または四半期ごとのアクセシビリティ健全性チェック
  • これまでアクセシビリティを優先してこなかったチームへの導入

使用しない場合

  • デプロイ後の一般的な QA(qa-testing を使用してください)
  • コンポーネント単位のアクセシビリティ実装(frontend-component-build を使用してください)
  • デザイントークンのカラーコントラスト(design-standards または brand-identity を使用してください)

必須入力

  • 監査対象のサイトまたは製品
  • 対象範囲(サイト全体、特定のセクション、特定のユーザーフロー)
  • 対象とする標準(最も一般的なのは WCAG 2.1 AA です)
  • 個別の懸念事項や既知の問題
  • 利用可能なツール(自動スキャナー、スクリーンリーダー、手動テスト)

フレームワーク:WCAG の 4 原則

WCAG では、4 つの原則に基づいてアクセシビリティを整理しています。監査では、それぞれを詳しく確認します。

1. 知覚可能

情報と UI は、ユーザーが知覚できる形で提示される必要があります。

監査項目:

  • テキストによる代替。 装飾目的ではないすべての画像に説明的な alt テキストがあること。装飾画像には alt="" を使用すること。複雑な画像(チャート、インフォグラフィック)には長い説明を用意すること。
  • 時間依存メディア。 動画にキャプションがあること。事前収録された音声には文字起こしがあること。必要な場合、ライブ音声にはリアルタイムキャプションがあること。
  • 適応可能。 コンテンツの構造が、視覚的なスタイルだけでなく、マークアップ(セマンティック HTML)によって伝えられること。CSS を無効にした場合にも、読み上げ順序が適切であること。
  • 識別可能。 情報を伝える手段が色だけに限られていないこと。テキストコントラストが AA 基準を満たしていること(通常のテキストは 4.5:1、大きなテキストは 3:1)。UI 要素のコントラストが 3:1 以上であること。音声を一時停止、停止、またはミュートできること。
2. 操作可能

UI コンポーネントとナビゲーションは操作可能である必要があります。

監査項目:

  • キーボード操作可能。 すべての機能をキーボードだけで利用できること。キーボードトラップがないこと。フォーカスが視認できること。
  • 十分な時間。 制限時間を調整、一時停止、または延長できること。自動更新されるコンテンツを一時停止できること。
  • 発作や身体的反応。 1 秒間に 3 回を超えて点滅するコンテンツがないこと。
  • ナビゲーション可能。 スキップリンクがあること。各ページに説明的なタイトルがあること。フォーカス順序が論理的であること。リンクの目的がテキストまたは文脈から明確であること。ページを見つける方法が複数あること(サイトマップ、検索、ナビゲーション)。見出しとラベルが説明的であること。
  • 入力方法。 ポインタジェスチャーにキーボードでの代替手段があること。ポインタ操作のキャンセルをサポートしていること(有効化はマウスダウン時ではなく、マウスアップ時に行う)。ラベルとアクセシブルな名前が一致していること。動きによって起動する機能に代替手段があること。
3. 理解可能

情報と操作は理解可能である必要があります。

監査項目:

  • 読みやすさ。 ページの言語が指定されていること(<html lang="...">)。一般的でない単語や略語に定義または展開形があること。対象ユーザーに適した読解レベルであること。
  • 予測可能。 フォーカスによって予期せずコンテキストが変化しないこと。入力によって予期せずコンテキストが変化しないこと。ページ間でナビゲーションが一貫していること。見た目が似ているコンポーネントは、同様に動作すること。
  • 入力支援。 エラーが明確に特定されること。入力にラベルと手順が用意されていること。可能な場合はエラーの修正方法が示されること。法的な確約や金融取引を扱うページでは、送信前にエラーを確認して修正できること。
4. 堅牢

コンテンツは、現在および将来のユーザーエージェントで動作するだけの堅牢性を備えている必要があります。

監査項目:

  • 互換性。 マークアップが有効であること。UI コンポーネントの名前、ロール、値をプログラムで判別できること。ステータスメッセージをプログラムで判別でき、読み上げられること。

監査方法

ステージ 1:自動スキャン

優先度の高いページを自動スキャナーで検査します。これらのツールで問題の 30~50%は検出できますが、残りは見逃します。

ツール:

  • axe DevTools(ブラウザー拡張機能)
  • Lighthouse(Chrome DevTools のアクセシビリティ監査)
  • WAVE(ブラウザー拡張機能)
  • Pa11y(一括スキャン用の CLI)

出力: ページごとの自動検出結果の一覧。

ステージ 2:キーボードによる手動テスト

マウスを取り外します。キーボードのみを使って、優先度の高いユーザーフローを操作します。

テスト項目:

  • Tab キーと Shift+Tab キーで、論理的な順序でインタラクティブ要素間を移動できる
  • Enter キーでボタンとリンクを操作できる
  • Space キーでボタンを操作できる(チェックボックスの切り替えもできる)
  • 矢印キーで複合ウィジェット内(タブ、メニュー、リストボックス)を移動できる
  • Escape キーでモーダル、ポップオーバー、メニューを閉じられる
  • フォーカスが常に視覚的に確認できる
  • モーダルやポップオーバーを閉じた後、フォーカスが適切な位置に戻る
  • キーボードトラップがない(常にフォーカスを外へ移動できる)

記録: キーボード操作が機能しなくなるフローを記録します。

ステージ 3:スクリーンリーダーによるテスト

少なくとも 1 種類の実際のスクリーンリーダーでテストするか、データ利用可能性のルールに従って対応できない点を明記します。組み合わせごとに動作上の違いがあります。

一般的な組み合わせ:

  • VoiceOver + Safari(macOS / iOS)
  • NVDA + Firefox または Chrome(Windows)
  • JAWS + Chrome(Windows。商用ですが、企業でよく使われています)
  • TalkBack + Chrome(Android)

テスト項目:

  • ページ構造(見出し、ランドマーク)が正しく読み上げられる
  • フォームのラベルが入力欄とともに読み上げられる
  • エラーが発生したときに読み上げられる
  • ステータスの変化(読み込み、成功、エラー)が読み上げられる
  • モーダルを開いたときに、そのコンテキストが読み上げられる
  • 画像に適切な代替テキストが設定されている(または装飾画像として正しく識別される)
ステージ 4:視覚的なテスト

アクセシビリティの視覚的な側面を確認します。

テスト項目:

  • すべてのテキストと背景の組み合わせで色のコントラストを確認する(コントラストチェッカーを使用)
  • UI 要素のコントラスト(アイコン、境界線、フォーカスリングは 3:1)
  • 色覚異常のシミュレーション(最低限、第二色覚異常)
  • 200% にズームしてもコンテンツが使いやすく、横スクロールが発生しない
  • ビューポート幅 320px でリフローする
  • テキスト間隔を適用しても(行間、文字間隔)、コンテンツが切れない
  • 動きを減らせる(prefers-reduced-motion が適用される)
ステージ 5:認知アクセシビリティ

見落とされがちですが、インクルーシブな製品には不可欠です。

テスト項目:

  • 読解レベルが適切である
  • 説明が明確である
  • エラーメッセージに、エラーが発生したことだけでなく、修正方法が説明されている
  • 送信前にフォームの内容を修正できる
  • 制限時間を回避または延長できる
  • 重要なコンテンツが、前のページの内容を覚えていることに依存しない

ワークフロー

  1. 範囲を定めます。 サイト全体ですか? 特定のフローですか? 特定のページテンプレートですか?
  2. 自動スキャンを実行します。 ページごとに検出結果を記録します。
  3. キーボードで手動テストを行います。 優先度の高いすべてのフローをテストします。
  4. スクリーンリーダーでテストします。 少なくとも 1 つの組み合わせでテストします。
  5. 視覚面を確認します。 コントラスト、ズーム、色覚異常、動きを確認します。
  6. 認知面を確認します。 読解レベル、エラーへの対応、制限時間を確認します。
  7. WCAG に照らして評価します。 達成基準ごとに評価します(レベル A、AA、AAA)。
  8. 検出結果に優先順位を付けます。 重大(ユーザーの利用を妨げる)、重要(体験を損なう)、軽微(仕上げ)。
  9. レポートを作成します。 references/audit-report-template.md のテンプレートを使用します。
  10. 修正計画を作成します。 工数と影響の見積もりを含め、順序立てて修正内容をまとめます。

重大度の分類

優先順位付けのために使用します。

重大(P0):

  • 支援技術を使用するユーザーのユーザーフロー全体を妨げます
  • 重要なページを完全に利用できなくします
  • 例:ラベルのないフォーム、フォーカス管理のないモーダル、キーボードで操作できない主要な CTA

重要(P1):

  • 支援技術を使用するユーザーの利用体験を大幅に損ないます
  • 例:重要な画像の代替テキストがない、本文のコントラストが低い、エラーが通知されない

軽微(P2):

  • 例外的なケースや特定の支援技術の組み合わせに影響します
  • 例:軽微なフォーカス順序の問題、装飾画像の alt 属性がない、例外的なケースでのキーボード操作

仕上げ(P3):

  • アクセシビリティを向上させる AA を超える改善ですが、適合性を妨げるものではありません
  • 例:AAA のコントラスト目標、動きを抑えた表示のバリエーション追加、インラインの外国語の単語への言語属性

よくある失敗パターン

  • 自動スキャンだけに頼る。 問題の 30〜50%しか検出できません。残りの 50〜70%は、キーボード、スクリーンリーダー、認知面のテストで見つかります。
  • ホームページだけをテストする。 ホームページは通常、最もアクセシブルです。問題は深い階層のフローに潜んでいます。
  • アクセシビリティを一度きりのプロジェクトとして扱う。 アクセシビリティはデプロイのたびに損なわれます。開発サイクルに組み込みましょう。
  • 根本原因を調べずに修正する。 問題が起きた理由を理解せずに個々の問題へパッチを当てても、新たな問題が発生し続けます。
  • スクリーンリーダーでのテストを無視する。 きちんと行うのは難しく、簡単に省略されます。「アクセシブルだと思っていた」という想定外の事態が起きる最大の原因です。
  • AA と AAA を混同する。 AAA が適切な目標となることはほとんどありません。多くの製品において、AA が実用的な基準です。
  • アクセシビリティをデザイナーまたは開発者だけの責任と捉える。 コンテンツ、プロダクト、QA、リーダーシップの全員が参加する必要があります。
  • 適合性とアクセシビリティを同じものと考える。 WCAG への適合は最低基準であり、上限ではありません。実際のユーザーが使いづらさを感じる場合もあります。

出力形式

デフォルトの出力は、包括的な監査レポート accessibility-audit.md です。

構成:

  1. エグゼクティブサマリー
  2. 方法論(使用したツール、テストしたページ、使用したスクリーンリーダー)
  3. WCAG の原則ごとの調査結果
  4. 重大な調査結果(P0):具体的な URL と修正内容
  5. 重要な調査結果(P1)
  6. 軽微な調査結果(P2)
  7. 仕上げ(P3)
  8. 修正ロードマップ(順序付けと優先順位付け)
  9. 付録(自動スキャンの全結果、キーボード操作のメモ、スクリーンリーダーのメモ)

さらに、調査結果ごとに 1 行を設けた修正状況管理用のスプレッドシートを作成します。


必要なデータが入手できない場合

このスキルの出力は、単独では生成できないデータ、測定値、またはツールの実行結果に依存します。必要な入力、ツール、またはデータソースが利用できない、あるいは検証できない場合、認められる出力は、未解決の点を明記した成果物です。何が必要だったのか、実際に何を入手または検証できたのか、出力のどの部分に影響するのかを記載します。成果物を完成させるために必要な数値を捏造、推定、または補間することは、決して認められません。未解決の点を明示すれば、それで回答は完結です。


参考ファイル

  • references/audit-report-template.md - 監査レポートの完全なテンプレート。
  • references/wcag-quick-reference.md - 監査チェック項目を含む、WCAG 2.1 AA 基準の要約。
  • references/aria-patterns.md - 判断に役立つ ARIA パターン。セマンティック HTML を優先する原則、一般的なインタラクティブウィジェット(アコーディオン、タブ、モーダル、トグル、開示、ナビゲーション)、ライブリージョン、非表示パターン、ラベル付け、状態インジケーター、アンチパターン。

コメント