agentsclimarketplace

Accessibility

Skill tdyzzsp47/claude-skills/skills/accessibility

システム開発・個人開発の全工程(企画〜設計〜実装〜運用〜マネタイズ)をカバーするClaude Code用スキル集

Install
npx -y skills add tdyzzsp47/claude-skills --skill accessibility

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Webアプリ・UIのアクセシビリティ(a11y)対応を設計・実装・テストの全フェーズで組み込むスキル。WCAG準拠チェック、セマンティックHTML修正、キーボード・スクリーンリーダー対応が必要なときに使う。

SKILL.md

10.6 KB, as published. Nobody here has run it

アクセシビリティ(a11y)対応

目的

アクセシビリティは「障害者のための特別対応」ではなく、すべてのユーザーのUX向上策である。片手操作・屋外の眩しさ・騒音下・加齢といった状況的制約でも恩恵を受ける。SEO改善、障害者差別解消法の合理的配慮義務化など法的・ビジネス的要請も高まっている。まずWCAG 2.x レベルAAを目標に据え、設計段階から組み込む。

使うタイミング

  • [[screen-design]] でUIコンポーネントを定義するとき(コントラスト・フォーカス順序の事前確認)
  • [[implementation]] でHTMLマークアップを書くとき
  • [[testing]] のE2Eシナリオにa11yチェックを追加するとき
  • 既存プロダクトのa11y監査を行うとき
  • [[legal-compliance]] でバリアフリー法・障害者差別解消法の要件を確認するとき

実装の基本

セマンティックHTML

正しいタグを使うだけで問題の大半が解決する。

悪い例良い例理由
<div onclick="...">送信</div><button>送信</button>スクリーンリーダーの読み上げ・キーボード操作が自動で動作
<div class="header"><header> / <nav> / <main>ランドマーク構造でスキップナビが機能する
見出しを<div class="h2">で再現<h1>〜<h6>を序列通りに使う文書構造として認識され、見出しジャンプが動作

画像のalt属性

  • 意味のある画像: 内容を説明するaltテキストを付ける(「グラフの画像」ではなく「2024年売上推移: Q1〜Q4で30%増加」)
  • 装飾画像: alt=""を必ず明示する(altを省略するとURLを読み上げる場合がある)
  • アイコンボタン: aria-labelで操作の目的を記述する

フォームとエラー

  • <label for="id">と<input id="id">を対応させる
  • エラーは色だけでなくテキストで明示する(aria-describedbyでエラーメッセージと紐付け)
  • 必須項目はrequired属性とテキストで両方示す

コントラスト

  • 本文テキスト: 4.5:1以上
  • 大きな文字(18pt以上 or 14pt太字): 3:1以上
  • 色だけで情報を伝えない(グラフの凡例はパターンや形状を併用)
  • 確認ツール: WebAIM Contrast Checker

キーボード操作

  • すべての操作がキーボードのみで完結できること(マウスホバー専用の機能を作らない)
  • タブ順序が視覚的な読み順と一致していること(tabindexの正の値は原則使用しない)
  • フォーカスの視覚表示を消さない(outline: noneはアンチパターン。必要なら代替スタイルを定義)
  • モーダル開放時: フォーカスをモーダル内に閉じ込め(フォーカストラップ)、閉じたら元の要素に戻す

タッチターゲット

  • インタラクティブ要素は最低44×44px(WCAG 2.5.5)
  • 隣接するターゲット間に8px以上の余白を確保

ARIA

第一規則: セマンティックHTMLで書けるならARIAは使わない。

  • role="button"より<button>が優先
  • 動的コンテンツの更新通知: aria-live="polite"(緊急でなければassertiveを避ける)
  • ARIAの過剰使用はスクリーンリーダーを混乱させる(壊れたARIAは無いより悪い)

進め方

  1. 設計フェーズで組み込む — [[screen-design]] の時点でコントラスト比・フォーカス順序・代替テキスト方針を定義する
  2. セマンティックHTMLのレビュー — 実装前に構造を確認し、div/spanで再現されているUIパターンを洗い出す
  3. 自動チェックの実行 — axe-core / Lighthouse を使って機械的に検出できる違反を修正する(検出率は全問題の3〜4割)
  4. キーボードのみで主要フローを操作 — ログイン・主要CRUD・モーダル開閉をマウスなしで完結できるか確認する
  5. スクリーンリーダーで主要フローを確認 — macOS VoiceOver(Cmd+F5)またはNVDA(Windows)で同じフローを通す
  6. 修正と再チェック — 違反箇所を修正後、自動チェックを再実行して回帰がないか確認する
  7. [[testing]] のE2Eに統合 — axe-playwright / jest-axe を使い、a11yチェックを自動テストに組み込む

成果物テンプレート

a11y対応チェックリスト(設計・実装・テストの3段階):

## 設計段階

| 項目 | 確認内容 | 担当 | 状態 |
|---|---|---|---|
| コントラスト | 文字色と背景色の比率が4.5:1以上か | デザイン | [ ] |
| フォーカス順序 | タブ移動の順序が視覚的読み順と一致するか | デザイン | [ ] |
| 代替テキスト方針 | 各画像・アイコンのalt/aria-label方針が決まっているか | デザイン | [ ] |
| 色依存の排除 | 色だけで情報を伝えている箇所がないか | デザイン | [ ] |
| タッチターゲット | インタラクティブ要素が44×44px以上か | デザイン | [ ] |

## 実装段階

| 項目 | 確認内容 | 担当 | 状態 |
|---|---|---|---|
| セマンティックHTML | button/nav/main/h1-h6が正しく使われているか | 実装 | [ ] |
| フォームラベル | labelとinputが正しく関連付けられているか | 実装 | [ ] |
| エラーメッセージ | aria-describedbyでエラーとフィールドが紐付いているか | 実装 | [ ] |
| フォーカス可視化 | outline:noneが使われていないか | 実装 | [ ] |
| フォーカストラップ | モーダル内でフォーカスが閉じ込められているか | 実装 | [ ] |
| ARIAの使用 | セマンティックHTMLで代替できないARIAのみ使用か | 実装 | [ ] |

## テスト段階

| 項目 | 確認内容 | 担当 | 状態 |
|---|---|---|---|
| 自動チェック | axe/Lighthouseでviolationが0件か | テスト | [ ] |
| キーボード操作 | 主要フローがキーボードのみで完結するか | テスト | [ ] |
| スクリーンリーダー | VoiceOver/NVDAで主要フローを通せるか | テスト | [ ] |
| E2E統合 | jest-axe/axe-playwrightがCIに組み込まれているか | テスト | [ ] |

チェックリスト

  • divやspanにonClickを付けてボタンを再現している箇所がない
  • <h1>〜<h6>が文書構造として序列通りに使われている
  • 意味のある画像すべてにaltテキストがある(「画像」とだけ書いていない)
  • 装飾画像にalt=""が明示されている
  • フォームの各フィールドに対応するlabelがある
  • エラーメッセージがテキストで表示され、色だけに頼っていない
  • テキストのコントラスト比が4.5:1以上である
  • フォーカスアウトラインが視覚的に確認できる
  • キーボードのTabキーで全インタラクション要素に到達できる
  • モーダルがフォーカストラップを実装している
  • axe/Lighthouseのviolationが0件である
  • CI/CDパイプラインにa11y自動チェックが含まれている

アンチパターン

アンチパターン何が問題か対処
リリース後にまとめてa11y対応セマンティック構造の作り直しになりコストが爆発する設計段階から[[screen-design]]に項目を組み込む
自動チェック100%で完了扱いaxe/Lighthouseで検出できるのは全問題の3〜4割のみキーボード・スクリーンリーダーによる手動確認を必ず実施
outline: noneをCSSに書くフォーカス位置が見えなくなりキーボードユーザーが操作不能になる代替フォーカススタイル(outline: 2px solid #0066cc等)を定義する
ARIAの過剰使用誤ったARIAはスクリーンリーダーを混乱させ、無いより悪い状態になるセマンティックHTMLで代替できる場合はARIAを使わない
altに「画像」とだけ書く内容が伝わらず、無意味なノイズになる画像が伝えるべき情報をテキストで記述する
カラーコントラストをデザイン後半で確認ブランドカラーの変更が必要になり影響範囲が広がるデザイントークン定義時にコントラスト比を確認する
tabindexに正の値を多用タブ順序の管理が複雑になりバグを招くDOMの順序を正しく組み、tabindex="0"のみ補助的に使う

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

モデル役割の目安
司令塔WCAG準拠レベルの決定(A/AA/AAA)・対応スコープの優先順位付け・法的要件の判断・設計レビューへの組み込み方針
Opus相当複雑なインタラクティブUI(データグリッド・ドラッグ&ドロップ・カスタムコンボボックス)のa11y設計・ARIAパターンの選定・フォーカス管理の設計
Sonnet相当自動チェックの実行と違反修正・alt/ラベルの付与・セマンティックHTMLへのリファクタリング・E2Eへのa11y統合実装
Haiku相当axe/Lighthouse違反箇所の機械的検出とリスト化・コントラスト比の計算・outline:noneやdiv onclickパターンの静的検索

関連スキル

  • [[screen-design]] — 設計段階でコントラスト・フォーカス順序・代替テキスト方針を定義する起点
  • [[implementation]] — セマンティックHTMLとARIAを正しく組み込む際の実装ガイド
  • [[testing]] — E2Eシナリオへのaxeチェックの統合・スクリーンリーダーテストの組み込み
  • [[legal-compliance]] — 障害者差別解消法・JIS X 8341・EN 301 549などの法的要件の確認
  • [[i18n-localization]] — 多言語対応時のスクリーンリーダー読み上げ順・lang属性の扱い
  • [[ux-research]] — 障害当事者ユーザーテストの計画・インクルーシブデザインリサーチ
  • [[non-functional-requirements]] — a11yをNFR(非機能要件)として定義・優先度付けする
  • [[orchestration]] — モデル委譲の共通原則

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.