mcpField
A
accessibility-audit

accessibility-audit

github.com/mohitagw15856デザイン・UI1.5k55 回インストール6 日前に更新
リポジトリ

accessibility-audit について

WCAG 2.2 に基づき、視覚、運動、認知、スクリーンリーダー利用を含む構造化されたアクセシビリティ監査を作成するスキルです。インターフェースを評価し、修正の優先順位を決めるチーム向けです。

主な機能

  1. 01WCAG 2.2 に基づく監査構成
  2. 024 分野のアクセシビリティを網羅
  3. 03問題を WCAG 基準に対応付け
  4. 04優先度と工数を示した修正案
  5. 05手動・自動テストの指針
  6. 06コントラスト測定の案内

活用シーン

  1. 01画面やコンポーネントの監査
  2. 02デザイン仕様の確認
  3. 03アクセシビリティ修正の優先順位付け
  4. 04キーボードとスクリーンリーダーテストの計画

インストール

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

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

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

詳細

アクセシビリティ監査スキル

このスキルでは、WCAG 2.2 ガイドラインに基づく体系的なアクセシビリティ監査を行います。視覚、運動、認知、スクリーンリーダーのアクセシビリティを対象とし、見つかった各問題に優先順位を付けて修正方法を示します。

必須入力

提示された情報をもとに作業してください。以下の情報が不足している場合も、完全な出力を作成してください。不足分は妥当な仮定で補い、(仮定、要確認) と明記して、最後に仮定の一覧を記載します。中核となる対象そのものが不明で、書く内容が何もない場合に限り、最初に質問してください。

  • 監査対象(画面、コンポーネント、製品全体、デザイン仕様)
  • UI の説明または画像
  • 対象とする WCAG レベル(A/AA/AAA。デフォルトは AA。多くの法域で法的基準となっています)
  • 支援技術を利用するユーザーがいることがわかっていますか?(はい/いいえ。はいの場合は、該当するもの:スクリーンリーダー/スイッチアクセス/音声操作/拡大表示)
  • プラットフォーム(Web/iOS/Android/デスクトップアプリ)

プログラムによる補助

コントラスト比は目視で判断できません。AA の基準値は 4.5:1 です。白に対する #777777 は 4.478(不適合)、#767676 は 4.54(適合)です。スクリーンショットをどれだけ 見ても、この差は判別できません。計算してください:

npx --yes notugly fix "#8ab4f8" "#ffffff"     # ratio, APCA, and the nearest passing colour
npx --yes notugly onepager <url> --out review.html   # every pairing, printable
npx --yes notugly vision                      # which colours merge for colour-blind viewers

notugly fix は比率、APCA の明度コントラスト、選択済みの色に最も近い適合色を返します。色相と彩度は同じです。 推定値ではなく、以下の表にこれらの数値を記載してください。

決定論的で依存関係はゼロ、モデル呼び出しもありません。そのため実行コストがかからず、毎回同じ結果が得られます。

1.4.3 コントラスト(最低限)および 1.4.11 非テキストのコントラストについては、修正表のすべての行に評価ではなく測定済みの比率を記載してください。ユーザーが HEX 値ではなくスクリーンショットを提示した場合は、そのことを監査に明記してください。推定した比率は監査結果ではありません。

出力形式


アクセシビリティ監査:[コンポーネントまたは画面名]

対象基準: WCAG 2.2 レベル[AA] プラットフォーム:[プラットフォーム] 日付:[日付]


監査概要

カテゴリ見つかった問題重大中程度軽微
知覚可能
操作可能
理解可能
堅牢
合計

全体的な適合状況: ✅ 適合/🟡 軽微な問題あり/🔴 AA 基準に不適合


知覚可能

1.1 テキストによる代替
  • すべての画像に内容を説明する代替テキストがある(ファイル名や「画像」ではない)
  • 装飾画像には、スクリーンリーダーが読み飛ばせるよう alt="" が指定されている
  • 表示ラベルのないアイコンにアクセシブルネームがある
  • 複雑な画像(グラフ、図)に詳細な説明がある

見つかった問題:[具体的な問題の一覧、または「なし」]

1.3 適応可能
  • コンテンツ構造に、見た目の書式だけでなくセマンティック HTML(見出し、リスト、ランドマーク)が使われている
  • DOM 上の読み上げ順序が視覚的な順序と一致している
  • フォーム入力にラベルが関連付けられている(ラベルとしてプレースホルダーテキストを使っていない)
  • データテーブルに適切な見出しとスコープが設定されている

見つかった問題:

1.4 判別可能
  • テキストのコントラスト比が 4.5:1 以上(通常のテキスト)、または 3:1 以上(18px 以上の大きなテキスト)
  • UI コンポーネントの背景に対するコントラスト比が 3:1 以上
  • 情報が色だけで伝えられていない
  • コンテンツを失うことなくテキストを 200% まで拡大できる
  • 音声が自動再生されない

見つかった問題:


操作可能

2.1 キーボードで操作可能
  • すべてのインタラクティブ要素にキーボード(Tab キー)でアクセスできる
  • キーボードトラップがない
  • カスタムコンポーネントがキーボード操作に対応している(メニューでは矢印キー、モーダルを閉じるときは Escape)
  • ナビゲーションが繰り返されるページで、ナビゲーションをスキップするリンクを利用できる

見つかった問題:

2.4 ナビゲーション可能
  • 常にフォーカスが見える(代替手段なしに outline: none で消されていない)
  • フォーカス順序が論理的で予測可能である
  • ページ/画面に内容を説明するタイトルがある
  • リンクテキストが内容を説明している(「ここをクリック」や「続きを読む」ではない)
  • 見出しの階層が適切である(H1 → H2 → H3。階層を飛ばさない)

見つかった問題:

2.5 入力モダリティ
  • タッチターゲットが少なくとも44x44pxある
  • 簡単な代替手段なしに、複雑なジェスチャー(ピンチ、マルチタッチ)が必要な機能がない
  • モーションやドラッグ操作には、ボタンによる代替手段がある

見つかった問題:


理解しやすさ

3.1 読みやすさ
  • ページの言語が設定されている(lang 属性)
  • 一般的でない単語、略語、専門用語が説明されている
3.2 予測しやすさ
  • 画面間でナビゲーションに一貫性がある
  • コンポーネントの動作に一貫性がある(同じボタンは同じ動作をする)
  • フォーカスや入力によって予期しないコンテキストの変化が起きない
3.3 入力支援
  • エラーメッセージで該当するフィールドが特定され、エラーが平易な言葉で説明されている(「入力が無効です」だけではない)
  • 必須フィールドがラベルで示されている(色やアスタリスクだけではない)
  • フォームで、可能な場合はエラーの修正方法が提案されている

見つかった問題:


堅牢性

4.1 互換性
  • HTML が有効で、適切に構造化されている
  • ARIA のロールと属性が正しく使用されている(壊れたセマンティクスの修正に使われていない)
  • 状態メッセージ(成功、エラー、読み込み中)が、フォーカスを変更せずにスクリーンリーダーに通知される

見つかった問題:


優先度別の修正リスト

優先度問題WCAG 基準修正工数
🔴 重大[問題][例:1.4.3 コントラスト][具体的な修正][低/中/高]
🟡 中程度[問題]
🟢 軽微[問題]

優先度の定義:

  • 🔴 重大:障害のあるユーザーのアクセスを妨げます。法的リスクがあります。公開前に修正してください。
  • 🟡 中程度:大きな使いづらさがあります。次のスプリントで修正してください。
  • 🟢 軽微:ベストプラクティスです。ロードマップに沿って対応してください。

すぐにできる改善(1時間未満で修正)

[代替テキストの追加、色の変更によるコントラストの修正、lang 属性の追加など、簡単に修正できる問題を列挙してください。これらはすぐにリリースできます。]


テストの推奨事項

  • 手動キーボードテスト: フロー全体を Tab キーで移動します。マウスを使わずにすべてのタスクを完了できますか?
  • スクリーンリーダーテスト: VoiceOver(Mac/iOS)、NVDA または JAWS(Windows)。すべてのコンテンツと操作にアクセスできますか?
  • 色のコントラストチェック: Stark(Figma プラグイン)または WebAIM Contrast Checker を使用します
  • 自動スキャン: Axe DevTools または Lighthouse のアクセシビリティ監査(問題の約30%を自動的に検出できます)

品質チェック

  • 問題が具体的な WCAG 基準に対応付けられている
  • 重大な問題すべてに具体的な修正案がある
  • すぐにできる改善が大規模な修正と分けられている
  • 優先順位付けのための工数見積もりが含まれている
  • テストの推奨事項が含まれている

アンチパターン

  • 自動スキャンツールだけに頼らないでください。自動チェックで検出できる問題は約30%です。キーボードとスクリーンリーダーによる手動テストが必要です
  • 影響を受けるユーザーが少ないという理由だけで、問題を「軽微」と分類しないでください。そのユーザーにとっては、すべてのアクセスが妨げられる場合があります
  • 壊れたセマンティクスを修正するために ARIA のロールを追加しないでください。まず適切なセマンティック HTML を使用し、ARIA は最終手段としてください
  • テキストの色のコントラストと UI コンポーネントの色のコントラストを混同しないでください。必要な最小比率はそれぞれ異なります(4.5:1 対 3:1)
  • 問題のない通常の操作経路だけを監査しないでください。エラー状態、空の状態、読み込み状態もアクセシビリティ要件を満たす必要があります

トリガーフレーズの例

  • 「このデザインのアクセシビリティを監査してください」
  • 「[画面/コンポーネント] の WCAG 準拠状況を確認してください」
  • 「[UI の説明] の a11y 監査をしてください」
  • 「このデザインにはどのようなアクセシビリティの問題がありますか?」

コメント