mcpField
A
accessibility-a11y

accessibility-a11y

github.com/mindrallyデザイン・UI2872.8k 回インストール3 週間前に更新
リポジトリ

accessibility-a11y について

Web開発者やデザイナー向けのアクセシビリティ指針です。セマンティックHTML、ARIA、キーボード操作、視覚面の配慮から、自動・手動テストまで扱います。

主な機能

  1. 01WCAGに沿った設計指針
  2. 02セマンティックHTMLとARIAのパターン
  3. 03キーボード操作とフォーカス管理
  4. 04視覚・メディアのアクセシビリティ
  5. 05自動テストと手動テスト

活用シーン

  1. 01Webインターフェース設計の評価
  2. 02アクセシブルなフォームや操作部品の実装
  3. 03キーボード・スクリーンリーダーテストの計画

インストール

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

$npx skills add https://github.com/mindrally/skills --skill accessibility-a11y

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

詳細

アクセシビリティ(a11y)のベストプラクティス

Web アクセシビリティとインクルーシブデザインの専門家として、すべてのユーザーが能力にかかわらず Web アプリケーションを利用し、操作できるよう、以下のガイドラインを適用してください。

アクセシビリティの基本原則

  • WCAG(Web コンテンツ・アクセシビリティ・ガイドライン)に準拠します
  • セマンティック HTML を使用して、アクセシビリティとスクリーンリーダーとの互換性を高めます
  • ARIA ロールと標準のアクセシビリティプロパティを使用して、高いアクセシビリティ基準を確保します
  • 視覚、聴覚、運動、認知に障害のあるユーザーを含む、すべてのユーザーを想定して設計します
  • さまざまな支援技術でテストします

セマンティック HTML

構造要素
  • <header>、<main>、<footer>、<nav>、<article>、<section>、<aside> などのセマンティック要素を使用します
  • インタラクティブな要素には <div> や <span> ではなく、<button> を使用します
  • レベルを飛ばさず、適切な見出し階層(h1〜h6)を使用します
  • スクリーンリーダーでのナビゲーションにはランドマーク(例:<nav>、<main>、<aside>)を使用します
  • 非推奨のマークアップは避けます
フォームのアクセシビリティ
  • for 属性と id 属性を使用して、ラベルをフォーム入力欄に関連付けます
  • 関連するフォーム要素は <fieldset> と <legend> でグループ化します
  • 明確なエラーメッセージと検証結果を提示します
  • 適切な入力タイプ(email、tel、number など)を使用します
  • プレースホルダーテキストは補助的なヒントとして使用し、ラベルの代わりにはしません

ARIA の実装

ARIA を使用する場面
  • セマンティック HTML だけでは不十分な場合に、ARIA ロールと属性を使用してアクセシビリティを高めます
  • 可能な場合は、ARIA よりも標準の HTML 要素を優先します
  • 可視テキストのラベルがない要素には aria-label を使用します
  • 追加の情報を示すには aria-describedby を実装します
  • 動的なコンテンツの更新には aria-live 領域を使用します
よく使われる ARIA のパターン
  • ボタン以外の要素をボタンとして動作させる必要がある場合に限り、role="button" を使用します
  • 折りたたみ可能なコンテンツには aria-expanded を実装します
  • 装飾的な要素には aria-hidden="true" を使用します
  • ナビゲーションの現在位置を示すには aria-current="page" を適用します
  • 可視ラベルを参照するには aria-labelledby を使用します

視覚的なアクセシビリティ

色とコントラスト
  • テキストに十分な色のコントラストを確保します(通常のテキストは最低 4.5:1、大きなテキストは 3:1)
  • 情報を伝える手段として色だけを使用することは避けます
  • 色と併せて、代替の指標(アイコン、パターン、テキスト)を提示します
  • 色覚異常シミュレーターを使ってデザインをテストします
フォーカス管理
  • フォーカス状態が明確にわかるフォーカススタイルを使用します
  • すべてのインタラクティブ要素に、視認できるフォーカスインジケーターを設けます
  • コンテンツが動的に変化する場合は、適切にフォーカスを管理します
  • 代替手段を用意せずにアウトラインスタイルを削除しないでください
  • 論理的なタブ順序を実装します

キーボード操作

ナビゲーション要件
  • すべてのインタラクティブ要素でキーボード操作を可能にします
  • すべての機能をキーボードだけで利用できるようにします
  • tabindex は適切に使用します(自然な順序には 0、プログラムによるフォーカスには -1)
  • 複雑な操作にはキーボードショートカットを実装します
  • キーボードトラップを避けます
インタラクティブ要素
  • タッチ操作に十分な大きさのインタラクティブ要素を設けます(最低 44x44 ピクセル)
  • クリックハンドラーと併せて、キーボードイベントハンドラー(onKeyDown、onKeyPress)を実装します
  • ボタンの起動に Enter キーと Space キーをサポートします
  • 複雑なウィジェットには矢印キーによるナビゲーションを実装します

コンテンツのアクセシビリティ

画像とメディア
  • すべての画像に内容を説明する代替テキストを設定します
  • 装飾画像には空の alt 属性(alt="")を使用します
  • 動画にキャプションを付けます
  • 音声コンテンツには文字起こしを用意します
  • 内容がわかるリンクテキストを使用します(「ここをクリック」は避けます)
テキストとタイポグラフィ
  • タイポグラフィには相対単位(rem、em)を使用します
  • 機能を損なうことなく、テキストを最大 200% まで拡大できるようにします
  • 十分な行の高さと文字間隔を保ちます
  • 間隔が不均一になることがあるため、両端揃えのテキストは避けます
  • 動きを減らすユーザー設定に対応します

レスポンシブデザインとアダプティブデザイン

モバイルファーストのアプローチ
  • モバイル向けに設計してから、画面サイズに合わせて拡張します
  • デバイスを問わず機能するレスポンシブレイアウトを実装します
  • タッチターゲットが適切なサイズであることを確認します
  • 縦向きと横向きの両方に対応します
ユーザー設定
  • アニメーションでは prefers-reduced-motion を尊重します
  • ダークモード/ライトモードでは prefers-color-scheme に対応します
  • 高コントラストのニーズを考慮して prefers-contrast を検討します
  • 該当する場合は prefers-reduced-transparency を実装します

テストと検証

自動テスト
  • アクセシビリティ監査には Lighthouse などのツールを使用します
  • 自動アクセシビリティテストに axe-core を組み込みます
  • CI/CD パイプラインでアクセシビリティチェックを実行します
  • 重大および深刻なアクセシビリティの問題をすべて解決します
手動テスト
  • スクリーンリーダー(NVDA、JAWS、VoiceOver)でテストします
  • キーボードだけで操作します
  • ブラウザーのズームを 200% にしてテストします
  • ブラウザーのアクセシビリティ検査ツールを使用します
  • 可能であれば、障害のある実際のユーザーとテストします

アクセシビリティのための CSS のベストプラクティス

  • 保守性を高めるため、外部スタイルシートを使用し、インラインスタイルは避けます
  • 堅牢なレイアウトには Flexbox と Grid を活用します
  • スタイリングにはクラスセレクターを使用します(BEM 命名規則を推奨)
  • メディアクエリーでレスポンシブデザインを実装します
  • ホバー状態に対応するフォーカス状態も用意します

コメント