Claude Media
Claudeのaccessibility-reviewスキルでWCAG 2.1 AA監査を回す
Claude CodeCoworkチュートリアル

Claudeのaccessibility-reviewスキルでWCAG 2.1 AA監査を回す

designプラグインのaccessibility-reviewは、コントラスト・キーボード・タッチターゲット・スクリーンリーダーをWCAG 2.1 AAで見る監査スキルです。導入、呼び方、基準表の読み方を扱います。

読了目安 約11分

accessibility-reviewは、Anthropicの公式リポジトリにあるdesignプラグインのスキルです。デザインやページを渡すと、WCAG 2.1のAAを物差しに、コントラスト、キーボード操作、タッチターゲット、スクリーンリーダーの順で監査し、重要度付きの表で返します。

この記事では導入と呼び方、スキルが見る基準の中身、出力フォーマット、そして基準表に混ざっている1つの注意点までを順に扱います。手元の画面やコンポーネントに対して、リリース前に一度かけるところまでが範囲です。

accessibility-reviewは何を監査するスキルか

定義ファイル(SKILL.md)の説明は「デザインまたはページに対してWCAG 2.1 AAのアクセシビリティ監査を行う」です。"audit accessibility"、"check a11y"、"is this accessible?" といった言い方や、コントラスト・キーボード操作・タッチターゲットの大きさ・スクリーンリーダーの挙動を見たいときに発動する、と書かれています。

引数の書式は <Figma URL, URL, or description> です。FigmaのURL、公開ページのURL、言葉での説明のどれでも渡せます。

所属するdesignプラグインは、デザインレビュー、デザインシステム管理、UXライティング、アクセシビリティ、リサーチ整理、開発ハンドオフをまとめたものです。README冒頭には、主な対象はCoworkで、Claude Codeでも動くと書かれています。プラグインのマニフェストにあるバージョンは1.2.0です。

スキルの本文は約130行と短く、中身は次の4部品でできています。

  • WCAG 2.1 AAのクイックリファレンス(12の達成基準)
  • よくある問題8項目とテストの進め方5段階
  • Markdownの出力テンプレート
  • Figmaやチケット管理ツールが接続されているときの追加動作

導入と呼び出し方

導入はシェルから2行です。1行目でマーケットプレイスを登録し、2行目でdesignプラグインを入れます。

claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install design@knowledge-work-plugins

入れたあとは2通りで使えます。

  1. 文中で頼む。"このページのa11yをチェックして" のように書くと、説明文の発動条件に合えばClaudeがスキルを読み込みます
  2. スラッシュで明示する。Claude Codeのプラグインのスキルは /プラグイン名:スキル名 の形で呼ぶ仕様なので、designプラグインなら /design:accessibility-review です

定義ファイル内の見出しは /accessibility-review $ARGUMENTS と素の名前で書かれています。実際の入力は名前空間付きの形になる点だけ押さえてください。同じREADMEのコマンド表には /accessibility という行もあります。スキル側の名前とは別なので、どちらが手元で補完に出るかは / を打って確かめるのが確実です。

呼び出しの例を示します。

/design:accessibility-review http://localhost:3000/checkout

URLの代わりに、コンポーネントのファイルパスや「ログインフォームの設計案」のような説明文でも渡せます。

見る基準は12個:Perceivable・Operable・Understandable・Robust

クイックリファレンスの12基準を、W3CのUnderstanding文書にある各基準の適合レベルと並べると次のとおりです。

原則基準内容適合レベル
知覚可能基準1.1.1内容非テキストコンテンツに代替テキスト適合レベルA
知覚可能基準1.3.1内容情報と構造をセマンティクスで伝える適合レベルA
知覚可能基準1.4.3内容コントラスト比4.5:1(大きい文字は3:1)適合レベルAA
知覚可能基準1.4.11内容UI部品・図形の非テキストコントラスト3:1適合レベルAA
操作可能基準2.1.1内容全機能をキーボードで操作できる適合レベルA
操作可能基準2.4.3内容フォーカス順序が論理的適合レベルA
操作可能基準2.4.7内容フォーカスの見える表示適合レベルAA
操作可能基準2.5.5内容タッチターゲット44×44 CSSピクセル以上適合レベルAAA
理解可能基準3.2.1内容フォーカスで予期しない変化が起きない適合レベルA
理解可能基準3.3.1内容エラーの特定(何が誤りか示す)適合レベルA
理解可能基準3.3.2内容入力欄のラベルや説明適合レベルA
堅牢基準4.1.2内容名前・役割・値をすべてのUI部品に適合レベルA

「AA」の監査と言いながら、AレベルとAAレベルが混在しています。AAに適合するにはAとAAの両方を満たす必要があるので、これは自然です。引っかかるのは表の中ほどにある2.5.5の行です。

2.5.5のタッチターゲットは実はAAAである

スキルは2.5.5を「WCAG 2.1 AA Quick Reference」の下に置いています。ところがW3Cの文書では、2.5.5 Target SizeはLevel AAAです。AAの監査に入れる基準ではありません。

この食い違いは、実務で次の形で効いてきます。

  • 44×44未満のボタンが見つかっても、WCAG 2.1 AAの不適合とは言えません
  • スキルの出力表に「2.5.5 / Major」と出ていても、AA適合の可否はそこでは決まりません
  • 外部に出す監査報告や調達要件では、AA不適合と書くと誤りになります

AAの範囲でタッチターゲットを見たいときの基準は、WCAG 2.2で加わった2.5.8 Target Size (Minimum)です。こちらはLevel AAで、ターゲットは24×24 CSSピクセル以上が条件です(例外あり)。44ピクセルは「推奨水準」、24ピクセルは「AAの最低線」と考えると整理できます。

そこで、依頼の側で基準を固定しておく手が使えます。

/design:accessibility-review src/components/Checkout.tsx
タッチターゲットは、AA必須の最低線(WCAG 2.2の2.5.8、24px)と、
推奨水準(2.5.5、44px、AAA)を分けて指摘して。

こう書くと、指摘が「AA不適合」と「推奨からの不足」に分かれて返ってきます。分け方まで保証されるわけではないので、返ってきた表の「WCAG Criterion」列と重要度を自分の目で見直してください。

プロジェクトで毎回同じ前提にしたいなら、CLAUDE.mdに規約として書いておけます。

## アクセシビリティ監査の前提
- 適合目標はWCAG 2.1 AA。タッチターゲットはWCAG 2.2の2.5.8(24px)をAA扱いにする
- 44px(2.5.5)は推奨として別枠で報告する
- 指摘には必ず達成基準の番号を付ける

出力フォーマットの読み方

スキルの出力テンプレートは、次の順で並びます。

  1. ヘッダー: 対象名、基準(WCAG 2.1 AA)、日付
  2. サマリー: 指摘総数と、Critical・Major・Minorの内訳
  3. 指摘表: 知覚可能・操作可能・理解可能・堅牢の4原則ごとに、課題・基準・重要度・推奨修正
  4. コントラスト確認表: 要素ごとの前景色、背景色、比率、必要比率、合否
  5. キーボード操作表: Tab順、Enter/Space、Escape、矢印キーの挙動
  6. スクリーンリーダー表: 読み上げられ方と問題点
  7. 優先修正: 影響を受ける人と、何がブロックされるかを添えた順位付き

重要度は🔴Critical、🟡Major、🟢Minorの3段階です。サマリーの件数が表の行数と合っているか、4原則の表がどれも空でないか、の2点は読むときの最初の確認になります。

数値が絡むのはコントラスト確認表です。比率は色コードから計算できる値なので、Claudeが出した数字の1つか2つを、ブラウザの開発者ツールで実測した値と突き合わせておくと信頼度の見当が付きます。

自動走査で拾えるのは約3割:手動確認とセットにする

スキルは「テストの進め方」として5段階を挙げています。

  1. 自動スキャン(問題の約30%を拾う)
  2. キーボードだけでの操作
  3. スクリーンリーダーでの確認(VoiceOver、NVDA)
  4. コントラストの検証
  5. 200%ズームでレイアウトが崩れないか

末尾のTipsにも、監査は出発点としては有用だが、VoiceOverやNVDAでの手動テストでしか分からないことがある、と明記されています。スキルは実機の支援技術を動かすわけではない、という前提です。

任せ方の目安として、依頼側の切り分けを表にすると次のようになります。これはスキルの記載ではなく、記事としての整理です。

確認accessibility-reviewに任せる人が手元で行う
ラベルのない入力欄、代替テキスト欠落accessibility-reviewに任せるソースを読んで洗い出す人が手元で行う修正後に再確認
コントラスト比accessibility-reviewに任せる色の組から計算して一覧にする人が手元で行う実画面の背景と重なる箇所を測る
キーボード操作accessibility-reviewに任せる実装(tabindex、onKeyDown)から推定する人が手元で行うTabだけで一周する
読み上げaccessibility-reviewに任せる要素の役割・名前から推定する人が手元で行うVoiceOverやNVDAで聞く
フォーカストラップaccessibility-reviewに任せるモーダルの実装から疑う人が手元で行う開閉して抜けられるか試す

操作・読み上げの行は、いずれも「推定」と「実機」の差が残ります。表の右列まで終えて初めて、監査が一周したことになります。

FigmaとチケットツールをつなぐとAIが何を足すか

スキルには、コネクタが接続されているときの追加動作が書かれています。

  • デザインツール(Figma)が接続されている場合: 色の値、フォントサイズ、タッチターゲットをFigmaから直接読み、デザイン仕様上のコンポーネントのARIAロールやキーボード動作も確認する
  • プロジェクト管理ツールが接続されている場合: 指摘ごとに、重要度とWCAG基準を付けたチケットを作り、既存のアクセシビリティ是正のエピックに紐付ける

designプラグインの .mcp.json には、Slack、Figma、Linear、Asana、Atlassian、Notion、Intercom、Googleカレンダー、Gmailの定義が入っています。このうちFigmaとLinear、Asana、Atlassianが上の2つの動作に対応する候補です。Figmaとの往復そのものはCowork Figma連携の記事に手順があります。

何も接続しなくても、説明文やスクリーンショットを渡す「スタンドアロン」で動くのはREADMEにも書かれています。まず接続なしで1画面試し、出力の形に納得してからFigma連携を足す順が負担の少ない進め方です。

隣接プラグインとの使い分け

アクセシビリティ周りでは、マーケットプレイスにDequeの「Axe Accessibility」プラグインも載っています。説明によると、AxeのMCPサーバーを使った「スキャン→修正→検証」の流れ(キーボードを使うガイド付きテストを含む)を担います。

観点accessibility-reviewAxe Accessibility
提供元accessibility-reviewAnthropic(knowledge-work-plugins)Axe AccessibilityDeque
中身accessibility-reviewWCAG 2.1 AAの監査観点と出力テンプレートを持つスキルAxe AccessibilityAxeのMCPサーバーによるスキャン・修正・検証
入力accessibility-reviewFigma、URL、説明文Axe Accessibility実行中のUI(ツールがスキャンする)
向く場面accessibility-reviewデザインのハンドオフ前、観点の洗い出しAxe Accessibilityコードに対する検証ループ

前者でレビュー観点と優先順位を作り、後者で実コードのスキャンを回す、という分担が考えられます。

UIの見た目の方針づくりはfrontend-designプラグインの守備範囲で、accessibility-reviewは作ったあとの検査にあたります。

まとめ

accessibility-reviewは、重い設定なしにWCAG 2.1 AAの観点を一式出させる軽いスキルです。使う前に決めておくとよいのは次の2点でした。

  1. 2.5.5のAAA扱いを前提に、タッチターゲットの基準(24pxか44pxか)を依頼文かCLAUDE.mdで固定する
  2. 出力を最終結論にせず、キーボード1周とスクリーンリーダーの実機確認を手順に残す

この2点を押さえれば、指摘の表がそのまま修正チケットの下書きになります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →