accessibility

Web のページのアクセシビリティを点検して直したいときに使います。説明文の引き金は「アクセシビリティを改善して」「a11y の監査」「WCAG への準拠」「スクリーンリーダーへの対応」「キーボードの操作」「アクセシブルにして」です。

基準は WCAG 2.2 と Lighthouse のアクセシビリティの監査で、障害のある人を含めて誰でも使えるようにすることが目標だ、と書かれています。同じ公開元の README は、この集まりがフレームワークを選ばず、React でも Vue でも素の HTML でも使える、としています。

証拠から入る点検の流れ

4 段

本文で「2.2 で新しい」と印を付けた基準

6 つ

同梱ファイル（2026-10-23 時点）

2 件

SKILL.md（2026-10-23 時点）

14,358 バイト

証拠から入る 4 段

描画されたページがあるときの流れが、本文の最初に置かれています。

1. 監査を流すLighthouse のアクセシビリティの監査。Chrome DevTools MCP なら lighthouse_audit
2. 落ちた箇所から絞る落ちた要素から部品やテンプレートを特定する。リポジトリ全体を型で探さない
3. 木と操作で確かめるアクセシビリティの木で名前・役割・状態・目印・見出しを見て、キーボードで辿る
4. 直して流し直す元のコードを直し、同じ監査と手での操作をやり直す

一般に公開しているページはモバイルの読み込みの型で、読み込み直すとログインや入力の状態が消えるページはスナップショットの型で監査せよ、と書き分けています。ライブの道具が無いときは、Lighthouse CLI か axe で自動の点検をし、同じ手での確認をします。

4 つの原則と 3 つの段階

• 知覚できる文字の代わりの説明、字幕、色の対比
• 操作できるキーボード、焦点、時間の制限、動き
• 理解できるページの言語、一貫した案内、入力欄のラベル、エラー
• 堅牢である支援技術で動く。ARIA の役割と状態、ライブリージョン

適合の段階は、A が最低限で必ず通す、AA が標準で通すべき（多くの法域で法的な要件）、AAA があればよい、という位置づけです。

2.2 で足された基準

本文が「2.2 で新しい」と印を付けているのは次の 6 つです。

同梱の references/WCAG.md には、2.1 から 2.2 で足された 9 件と、外された 1 件（4.1.1 構文解析）の表があります。

色の対比の基準

焦点の枠も背景に対して 3:1 が要る、色だけで誤りを伝えずアイコンと文字を添える、と例つきで示されています。

直す順は影響の大きさで

本文は、よくある問題を 3 段に分けています。すぐ直すものは、入力欄のラベルの欠け、画像の代わりの文字の欠け、足りない対比、キーボードの罠、焦点の表示の欠けの 5 つです。

公開前に直すものは、ページの言語の欠け、見出しの構造の欠け、意味の分からないリンクの文字、自動で再生される音や動画、飛ばしのリンクの欠けの 5 つです。そのあとに、アイコンのラベル・一貫しない案内・エラーの特定・制御の無い時間の制限・目印の領域の欠けが続きます。

手で確かめる 7 つ

Tab でページ全体を辿り Enter や Space で操作する、VoiceOver・NVDA・TalkBack で読み上げる、200% に拡大する、Windows のハイコントラストで見る、動きを減らす設定で見る、焦点の順が見た目の順に沿う、的が 24 × 24 ピクセル以上ある、の 7 つです。

同梱の 2 件

references/WCAG.md は、A・AA・AAA の段階ごとの基準の一覧、ARIA のよくある型、2.1 から 2.2 の差分、点検の道具の表です。references/A11Y-PATTERNS.md は、モーダルでの焦点の閉じ込め、飛ばしのリンク、エラーの扱い、入力欄のラベル、ドラッグの代わり、ARIA のタブ、ライブリージョン、読み上げの操作の早見表、の 8 つの型をそのまま使える形で載せています。

• 画面を作りながら決まりを守らせたい部品の作り方の中に WCAG 2.1 AA を置く側
• 見た目や使い勝手を含めて規約で点検したい規約の一覧で照らす側
• 表示の速さを測りたい性能を DevTools で測る側
• 法的な適合を証明したい自動の監査は一部しか見ない。専門の監査と組み合わせる

画面を作る段階で守らせたいなら

このスキルは、できたページを点検して直すところに重きがあります。部品を作る最中に、状態の置き場所や見た目の癖と一緒にアクセシビリティを決まりとして守らせたいなら、同じ作者の別のリポジトリにある frontend-ui-engineering が合います。

そちらは WCAG 2.1 AA を基準にし、例は React と Tailwind CSS で書かれています。こちらは 2.2 を基準にし、例は素の HTML・CSS・JavaScript です。

見た目や使い勝手も含めて点検したいなら

アクセシビリティだけでなく、画面の作りの規約全体で照らしたいなら web-design-guidelines があります。そちらは基準を毎回取りに行く仕組みで、こちらは基準と型を手元のファイルに持っています。

速さを見たいなら

同じリポジトリには性能や Core Web Vitals のスキルもありますが、当サイトにはまだ解説がありません。ページの遅さを Chrome DevTools で測るなら web-perf があります。

Web ではない画面

本文の例はすべて HTML・CSS・ブラウザの JavaScript で、点検の道具も Lighthouse と axe です。スマートフォンの専用のアプリや、デスクトップのアプリの画面にはそのまま当てられません。

SKILL.md は、点検の道具を動かす前提で書かれています。Chrome DevTools MCP の lighthouse_audit と take_snapshot を使い、無ければ npx lighthouse <URL> --only-categories=accessibility や axe の CLI を動かします。どちらも対象のページを開いて読み込むので、外のサイトに向ければそのサイトへの通信になります。

axe の CLI はグローバルに入れる例になっている

点検の例は npm install @axe-core/cli -g で、プロジェクトの外の場所にパッケージを入れます。手元の環境を汚したくないなら、入れる前に止まって聞くよう指示するか、npx で動かすよう伝えてください。

直すときはページのコードが書き換わる

流れの 4 段目は元のコードを直すことで、作業ではファイルが変わります。本文の例のページの言語は lang="en" なので、日本語のページなら ja に読み替えます。

名指しの先は同じリポジトリの別スキル

参考の欄は、同じリポジトリの web-quality-audit を案内しています。このスキルを 1 件だけ入れると、案内先は手元に無いことがあります。同梱の 2 件はスキルのフォルダの中にあるので、そちらは一緒に入ります。

ライセンスと版

SKILL.md の frontmatter に、ライセンスは MIT、版は 2.0 と書かれています。

Chrome DevTools MCP が無いと使えませんか

使えます。本文は、ライブの道具が無いときは Lighthouse CLI か axe で自動の点検をし、手での確認は同じように行え、と書いています。公開元の README も、DevTools との連携は任意で、無ければ CLI や手での確認や静的な点検に切り替えて止まらない、としています（2026-10-23 確認）。

frontend-ui-engineering とはどちらを使えばいいですか

frontend-ui-engineering は部品を作るときの決まりの一部としてアクセシビリティを扱い、基準は WCAG 2.1 AA です。このスキルはできたページを WCAG 2.2 で点検し、監査の結果を証拠に直すことに絞っています。作る段ではあちら、仕上げの点検ではこちら、と分けると重なりが少なくなります。

自動で呼ばれますか

手で呼び出す指定は付いていません。説明文に「アクセシビリティを改善して」「WCAG への準拠」「キーボードの操作」などの呼びどころが並び、README も、頼んだ内容が説明に合えば自動で働く、としています。

対応しているエージェントはどれですか

公開元の README が、Claude Code のプラグインと Codex のプラグインのそれぞれに入れ方を案内しています（2026-10-23 確認）。README はほかに Gemini CLI と claude.ai での使い方も載せていますが、当サイトが表示しているのは Claude Code と Codex の 2 つです。