wcag-audit-patterns

wcag-audit-patterns スキルの概要

wcag-audit-patterns スキルでできること

wcag-audit-patterns スキルは、WCAG 2.2 のアクセシビリティ監査を進め、見つかった課題を具体的な改善ガイダンスに落とし込むための構造化プロンプトフレームワークです。単なる「アクセシビリティをチェックして」という汎用プロンプトでは物足りず、UX監査、QA、デザインレビュー、エンジニアへの引き継ぎ、コンプライアンス準備まで見据えて使いたい人に向いています。

どんな人に向いているか

次のような目的があるなら、wcag-audit-patterns は有力な選択肢です。

• ページ、フロー、コンポーネントを WCAG 2.2 に照らしてレビューしたい
• 自動検出の結果と手動検証を組み合わせたい
• 影響度や適合レベルごとに課題を優先順位付けしたい
• 開発者やデザイナーがそのまま動ける修正指針を出したい

特に、アクセシビリティ担当者、UX監査担当、プロダクトデザイナー、フロントエンドエンジニア、そして ADA・Section 508・VPAT 関連対応の準備を進めるチームと相性が良いです。

実際に解決したい仕事は何か

多くのユーザーが必要としているのは、WCAG の理論講義ではありません。知りたいのは、再現性のある形で次の問いに答える方法です。

• どこが壊れていそうか
• 何を手動で確認すべきか
• どの深刻度を付けるべきか
• 曖昧な助言ではなく、どう直すべきか

その点で wcag-audit-patterns skill は実務向きです。WCAG の適合レベル、POUR 原則、よくある違反パターン、そして remediation を前提にした整理軸で、監査中心の出力に導いてくれます。

普通のプロンプトと何が違うのか

一般的なアクセシビリティ用プロンプトは、どうしても広く浅い助言になりがちです。wcag-audit-patterns は、次のような出力を求めるときに特に役立ちます。

• 既知の監査観点でページや機能を点検したい
• ブロッカー級の問題と軽度の問題を分けたい
• 指摘を、認識しやすい WCAG の問題カテゴリに対応付けたい
• 「アクセシビリティを改善する」ではなく、具体的な remediation パターンを出したい

できること・できないことの境界

このスキルの強みは、監査の考え方と問題パターンの網羅性にあります。一方で、すぐに一式そろったツールチェーンとして使えるわけではありません。リポジトリには SKILL.md しかなく、補助スクリプト、ルール定義、参照ファイルは含まれていません。

つまり、wcag-audit-patterns for UX Audit は、ガイド付きの監査フレームワークとして使うのが最適です。完全自動のスキャナーや、法的認証ワークフローそのものとして期待するのは適切ではありません。

wcag-audit-patterns スキルの使い方

wcag-audit-patterns の導入時に知っておくこと

上流のスキルは SKILL.md 内に独自の install コマンドを載せていないため、wshobson/agents リポジトリに対する普段のスキル読み込み方法を使ってください。環境が Skills CLI に対応しているなら、よくある追加方法は次のとおりです。

npx skills add https://github.com/wshobson/agents --skill wcag-audit-patterns

ローカル clone からスキルを読み込む構成なら、参照先は次です。

plugins/accessibility-compliance/skills/wcag-audit-patterns

最初に読むべきファイル

まず確認したいのは次のファイルです。

• plugins/accessibility-compliance/skills/wcag-audit-patterns/SKILL.md

このスキル配下には補助フォルダや参照ドキュメントがないため、実用的なガイダンスのほぼすべてがこの 1 ファイルに集約されています。導入判断をすばやく行える反面、別の場所に実装寄りの詳しい説明が隠れていることは期待しないほうがよいです。

うまく機能させるために必要な入力

wcag-audit-patterns usage の質は、入力の質に大きく左右されます。少なくとも次の情報は渡したいところです。

• 監査対象の URL、画面、またはコンポーネント
• そのページの目的と主要なユーザータスク
• 目標とする適合レベル。通常は WCAG 2.2 AA
• デバイスや viewport の前提
• 必要に応じた技術スタック情報。たとえば React、custom widgets、modal system、design system components など
• スクリーンショット、HTML snippets、audit logs、axe output、user flow steps といった根拠資料

これらがないと、モデルは一般的なパターンに寄って推測しやすくなり、文脈依存の不具合を見落とす可能性があります。

実監査で使いやすいプロンプトの形

強い呼び出し方は “audit this site for accessibility.” ではありません。たとえば次のように依頼すると、はるかに実務向きになります。

• どのページや機能を対象にするか明示する
• どの標準・レベルを見るか指定する
• 自動チェック候補と手動確認項目を分けて求める
• 課題の優先順位付けを依頼する
• 各指摘に対して remediation 手順を求める

プロンプト構成の例:

“Use wcag-audit-patterns to audit our checkout page against WCAG 2.2 AA. Focus on keyboard access, form labels, error handling, focus order, and color contrast. I’ve attached screenshots plus the HTML for the payment section. Separate likely issues from items requiring manual verification. For each issue, provide severity, likely WCAG area, user impact, and a concrete fix.”

ざっくりした依頼を実用的なプロンプトにする

もし最初の依頼が「うちの modal をチェックして」程度なら、次の観点まで広げると精度が上がります。

• その modal が何のためのものか
• どう開き、どう閉じるのか
• focus が trap されるか
• forms、tables、custom controls を含むか
• mobile と desktop で挙動が違うか

深刻な WCAG 上の問題は、静的な markup だけでなく、操作フローに依存することが多いためです。

wcag-audit-patterns for UX Audit のおすすめ運用フロー

実務で回しやすい流れは次のとおりです。

1. ページ種別に応じた pre-audit checklist をまず作らせる
2. 利用可能なら automated scanner は別途実行する
3. その出力、screenshots、code snippets をスキルに渡す
4. automation では確定できない項目の manual verification steps を求める
5. blocker、serious、moderate ごとに grouped した remediation plan を作らせる
6. 修正後の code や更新済み screenshots で再実行する

この流れのほうが、1 回きりのプロンプトより wcag-audit-patterns を活かせます。

このスキルが特に得意なこと

元の内容から見て、このスキルが強く重視しているのは次の点です。

• WCAG の適合レベル
• POUR フレームワーク
• 影響度ベースの一般的な違反パターン
• remediation を前提にした監査出力

そのため、特に次の用途で効果を発揮します。

• 初回監査の構造化
• ありがちなアクセシビリティ欠陥の優先順位付け
• 開発者が動きやすい修正ガイダンスの生成
• forms や custom widgets など、インタラクティブな UI パターンのレビュー

自動ではやってくれないこと

このスキルには次の機能は含まれていません。

• browser automation
• code analyzers
• 別ファイルで再利用できる checklist
• legal sign-off logic
• product 固有の decision rules

そのため、wcag-audit-patterns install 自体は簡単でも、高い確度でコンプライアンス対応を進めたいなら、自前の scanner、testing process、または人による review は引き続き必要です。

価値の高い入力例

特に有用なのは、次のような資料です。

• axe、Lighthouse などの scan output
• 問題のある control 周辺の DOM snippets
• focus state が見える screenshots
• keyboard interaction steps
• form validation behavior
• menus、dialogs、carousels など動的 UI 状態の動画やメモ

こうした入力があると、単に違反らしい点を挙げるだけでなく、要検証の項目と高確度の問題を切り分けやすくなります。

出力を改善しやすい実践的なプロンプトパターン

次のような形式での出力を指定すると、使い勝手が上がります。

• “audit findings table with severity, impact, fix”
• “manual verification checklist by component”
• “top 10 blockers before release”
• “developer remediation tasks with acceptance criteria”
• “design review notes for WCAG 2.2 AA”

自由記述の要約より、こうした出力形式のほうが実際の対応につなげやすいです。

wcag-audit-patterns スキル FAQ

wcag-audit-patterns は初心者にも向いているか

はい。少なくとも、自分がどのページやプロダクトをレビューしているのか把握している初心者には有用です。このスキルは WCAG 2.2、適合レベル、代表的な問題カテゴリに沿った整理を与えてくれます。ただし、完全なアクセシビリティ講座ではないため、境界事例や正式な解釈については外部の参考資料が必要になることがあります。

普通のアクセシビリティ用プロンプトより良いか

監査用途なら、多くの場合は yes です。wcag-audit-patterns guide の価値は隠れたデータにあるのではなく、監査のフレーミングにあります。特に、severity、manual checks、remediation まで要求したときに、モデルの出力をより体系的にしやすいのが強みです。

自動スキャナーの代わりになるか

なりません。補完関係です。自動ツールでカバーできるのは WCAG の一部にすぎず、このスキルは、より広い観点でのレビューを整理したり、keyboard use、semantics、labels、focus management、interaction quality に関する手動確認を提案したりするのに向いています。

法務や調達向けのコンプライアンス作業にも使えるか

準備作業の支援には使えます。特に ADA、Section 508、VPAT 関連レビューの下準備には有効です。ただし、法的認証そのものとして扱うべきではありません。コンプライアンス主張の唯一の根拠にするのではなく、証跡整理や remediation 計画づくりに使うのが適切です。

wcag-audit-patterns を使わないほうがよい場面

次のものが必要なら、別の選択肢を検討したほうがよいです。

• code-level linter や CI integration
• formal legal interpretation
• repo 内に完結した完全なアクセシビリティ知識ベース
• web 向け WCAG 監査パターン以外の、ネイティブアプリ特化ガイダンス

このスキルは、web 中心の監査 reasoning には強い一方、エンドツーエンドの compliance automation 向けではありません。

フルページだけでなくコンポーネントにも使えるか

使えます。むしろコンポーネント単位のほうが、markup、interaction sequence、screenshots、expected behavior といった証拠を絞って渡せるぶん、有効なことも多いです。相性の良い対象としては、modals、tabs、menus、forms、tables、custom controls などがあります。

wcag-audit-patterns スキルを改善する使い方

監査対象はできるだけ狭くする

改善効果が最も大きいのは、対象範囲の絞り込みです。「ダッシュボード全体を監査して」ではなく、次のように切り分けて依頼してください。

• 1 つの page template
• sign-up や checkout など 1 つの journey
• date pickers や dialogs など 1 つの component family

対象が狭いほど、wcag-audit-patterns の指摘と remediation は安定しやすくなります。

説明だけでなく根拠資料を渡す

wcag-audit-patterns は、説明文だけより証拠を添えたほうが明らかに良く働きます。特に有効なのは次の入力です。

• 影響範囲の HTML
• visible labels や focus states が見える screenshots
• ルール名付きの scanner output
• keyboard behavior に関するメモ
• 可能なら screen reader observations

証拠があると推測が減り、修正提案も具体的になります。

手動確認を明示的に求める

よくある失敗は、最初の出力をそのまま完成版と見なしてしまうことです。重要な WCAG 課題の多くは人の確認が必要です。スキルには、次を分けて出すよう依頼しましょう。

• likely detectable issues
• assumptions
• まだ必要な manual checks

こうしておくと、結果の信頼性が上がります。

受け入れ条件付きで remediation を要求する

「どう直すか」だけで止めないのが重要です。次の観点まで求めてください。

• 実装として何を変えるか
• それがなぜユーザーにとって重要か
• QA 向けの acceptance criteria
• 注意すべき regressions

ここまで含めると、デザイナー、エンジニア、QA の全員が使える出力になります。

優先順位付けの質を上げる

何もかも同じ重要度で返ってくる場合は、次の基準で再ランク付けするよう依頼すると改善しやすいです。

• user impact
• task blockage
• legal/compliance risk
• ease of remediation
• templates をまたいだ発生頻度

これは、wcag-audit-patterns skill を backlog 整理や release 前の triage で使うときに特に有効です。

修正後は before / after の文脈付きで再実行する

このスキルの価値がより高まるのは、2 回目以降の見直しです。次の情報を渡してください。

• 元の指摘内容
• 修正後の markup または screenshot
• 何を変えたか
• まだ不確かな点は何か

そのうえで、修正で問題が完全に解消したか、新たなアクセシビリティリスクが入っていないかを確認させると有効です。

自分たちの基準と組み合わせる

チーム独自の design system rules、coding standards、accessibility definitions of done があるなら、必ずプロンプトに含めるのがおすすめです。リポジトリ自体は軽量なので、ローカル標準を足すことが、wcag-audit-patterns usage を汎用的な出力ではなく、自社向けの監査支援に近づける最良の方法です。

自信過剰な出力には注意する

このスキルは有用ですが、code や interactive context が不足していると、確信度を実態以上に高く見せることがあります。指摘が runtime behavior に依存する場合は、confidence level を明記させ、browser 上や assistive tech で何を検証すべきかも併記させるのが安全です。

再利用できる監査テンプレート作成にも使う

実運用で wcag-audit-patterns を改善する最善策の一つは、うまくいったプロンプトを社内テンプレート化することです。

• page audit template
• component audit template
• remediation handoff template
• regression verification template

リポジトリ本体に補助ファイルがなくても、こうしたテンプレートを内製すれば、監査の一貫性を保ちやすくなります。