mcpField
W
web-accessibility

web-accessibility

github.com/magnus919デザイン・UI162156 回インストール今日更新
リポジトリ

web-accessibility について

デザインや開発チーム向けのWebアクセシビリティスキルです。観察可能な要件を定め、ネイティブHTMLを優先し、自動スキャンだけでWCAG適合を判断しない検証を支援します。

主な機能

  1. 01タスクと受け入れ基準の定義
  2. 02ネイティブHTMLのセマンティクス優先
  3. 03操作状態とキーボード動作の明確化
  4. 04必要に応じた参考資料の読み込み
  5. 05ブラウザーと支援技術の証拠記録
  6. 06自動判定によるWCAG適合主張の回避

活用シーン

  1. 01新しい画面のアクセシブルな操作設計
  2. 02フォームのエラーと回復手順の確認
  3. 03キーボードフォーカスと複合ウィジェットの検証
  4. 04リリース前の検証証拠の整理

インストール

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

$npx skills add https://github.com/magnus919/agent-skills --skill web-accessibility

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

同梱ファイル

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

README.md
assets/
acceptance-criteria-template.md
review-checklist-design.md
review-checklist-implementation.md
review-checklist-release.md
evals/
evals.json
references/
composite-widgets.md
dialogs-disclosures-navigation.md
forms-errors-authentication.md
keyboard-focus-and-routing.md
outcome-probes.md
routing.md
semantics-and-names.md
source-index.md
testing-and-evidence.md
visual-input-and-motion.md

詳細

Web アクセシビリティ

アクセシビリティとは、障害のある人がタスクを正常に完了し、失敗から回復できることであり、ツールのスコアではありません。実装前に観察可能な要件を定め、適合する場合はプラットフォーム標準の動作を優先し、サポート対象のブラウザーと支援技術(AT)環境で、範囲を限定した証拠を収集します。

ワークフロー

  1. タスク、ユーザー、サポート対象のブラウザー/AT、入力方法、失敗時の回復方法を定めます。まず assets/acceptance-criteria-template.md を使います。
  2. まずネイティブ HTML を選びます。構造、ネイティブコントロール、アクセシブルな名前、説明、動的な更新については、references/semantics-and-names.md を読み込みます。
  3. すべてのインタラクティブな状態を明記します。トリガー、ロール/名前/状態/値、キーボード操作、フォーカスの進入/退出/復帰、ポインター操作の代替手段、エラー、目に見えるフィードバックを記載します。該当するパターンのリファレンスを読み込みます。
  4. references/visual-input-and-motion.md を使って、視覚や入力方法の適応に対応する設計を行います。WCAG の要件と製品目標、例外を区別します。
  5. 契約を定義してから実装します。カスタムの複合ウィジェットでは、まず選択したスタックで実績のあるネイティブコンポーネントまたは保守されているコンポーネントを検討します。APG の例は参考ガイダンスであり、本番環境での有効性を証明するものではありません。
  6. references/testing-and-evidence.md と、設計、実装、リリース用のテンプレートを使って検証します。ツール、バージョン、範囲、手動タスク、実際に使用したブラウザー/AT の組み合わせ、失敗、およびブロックされた項目や該当しない項目を記録します。
  7. 自動スキャンの結果から、WCAG 適合性やアクセシビリティ全般について判定してはいけません。適合性を主張するには、このスキルの自動判定の対象外で、範囲を完全に定めた評価が必要です。

必要に応じて読み込む

必要な内容読み込むファイル
標準の状況、情報源の信頼性、正確なリンクreferences/source-index.md
ネイティブのセマンティクス、ラベル、アクセシブルな名前、ランドマーク、ライブ更新references/semantics-and-names.md
Tab の順序、フォーカスの可視性、フォーカストラップ、フォーカスの復元、ルートの変更references/keyboard-focus-and-routing.md
ラベル、検証、回復可能なエラー、認証references/forms-errors-authentication.md
モーダルダイアログ、開閉要素、レスポンシブナビゲーションreferences/dialogs-disclosures-navigation.md
タブ、コンボボックス、リストボックス、グリッド、メニュー、その他の複合ウィジェットreferences/composite-widgets.md
コントラスト、リフロー、ズーム、ターゲット、ドラッグ、動き、メディアreferences/visual-input-and-motion.md
自動チェック、手動テスト手順、AT マトリクス、証拠references/testing-and-evidence.md
フレームワークまたはスキルの適用範囲references/routing.md
適合性を主張せずに一般的な結果を検証する方法references/outcome-probes.md

判断ルール

  • WCAG 2.2 の達成基準、HTML/ARIA の仕様、参考用のチュートリアルやパターンは、それぞれ別のレイヤーとして扱います。references/source-index.md を参照してください。
  • ネイティブのホスト言語のセマンティクスで必要な動作を実現できない場合に限り、WAI-ARIA 1.2 を使います。ARIA はセマンティクスを変更しますが、キーボード操作や視覚的な表示を作り出すものではありません。
  • 特殊なケースでは、Accessible Name and Description Computation 1.2 のアルゴリズムを使います。優先順位を示す覚え方で代用してはいけません。計算後のアクセシビリティツリーと名前を確認します。
  • モーダルには、対象環境でサポートされる場合、<dialog>.showModal() を優先します。背景コンテンツは利用不可または inert にし、コンテンツとタスクに合わせて初期フォーカスを選択し、目に見える閉じる方法を用意して、論理的な位置にフォーカスを戻します。バックドロップを aria-hidden で隠したり、ダイアログの祖先要素を隠したりしてはいけません。
  • 通常のレスポンシブナビゲーションは、通常のリンクを表示する開閉要素として扱い、ARIA メニューとして扱ってはいけません。アプリケーションメニューのキーボード操作の契約がある場合に限り、メニューのセマンティクスを使います。
  • WCAG 2.2 AA における「ターゲットの最小サイズ」は、間隔、同等の手段、インライン、ユーザーエージェント、不可欠なコンテンツに関する例外に従い、CSS ピクセルで 24×24 です。より大きなターゲットは製品目標として設定できます。

完了

各受け入れ基準について直接的な証拠が得られたか、失敗、ブロック、または該当なしの結果が記録されるまで作業を続けてください。残存リスクと証拠の正確な範囲を報告し、テストが行われていないことを合格として扱わないでください。

使用しない場合

  • Hugo のテンプレートアーキテクチャ、テーマ全体のレイアウト、または CMS のレンダリングに関する懸念については、hugo-theme とそのデザイン/アクセシビリティのリファレンスを使用してください。
  • アクセシビリティ以外の証拠収集、スコープの決定、またはユーザー向けの動作については、product-discovery、product-methodology、または product-design-and-ux を使用してください。このスキルでは、アクセシビリティに関するインタラクションと適合性の深さを担当してください。
  • フレームワークまたはライブラリの API については、このスキルのセマンティクスとインタラクションの契約を定義した後、最新の公式ドキュメントを参照してください。React の実装詳細は react を、Vite の設定は vite を参照してください。

コメント