a11y

障害のあるユーザー、一時的な機能障害のあるユーザー、支援技術を使うユーザーがインターフェースを利用できるよう、アクセシビリティを体系的に改善します。

このスキルでは、評価だけでなく、問題の修正と実装に重点を置きます。複数の観点から評価する audit と、幅広いエッジケースに対応する harden を補完します。アクセシビリティを最優先の目標とする場合に使用してください。

必須の準備

ユーザーは /a11y でこのワークフローを開始します。このスキルが有効になったら、$frontend-design を読み込んでください。デザイン原則、アンチパターン、コンテキスト収集プロトコルが記載されています。作業を進める前にこのプロトコルに従ってください。デザインのコンテキストがまだ存在しない場合は、必ず最初に $setup を読み込んでください。

自動化ツールの連携（axe、WAVE、Pa11y）と CI ワークフローのガイダンスについては、アクセシビリティテストのリファレンスを参照してください。 色が状態、グラフ、または検証で意味を伝えている場合は、色覚特性に配慮した UX のリファレンスを参照してください。 キーボード操作、フォーカス処理、スキップリンク、非表示コンテンツのパターンについては、コンポーネントのアクセシビリティに関するリファレンスを参照してください。 フォーカス、読み込み、遷移、フィードバックの状態については、インタラクションデザインのリファレンスを参照してください。 色が状態を伝えているのか、単なる装飾なのかを確認する場合は、セマンティックカラーのリファレンスを参照してください。 小さな画面、タッチ操作、ズーム倍率に応じてアクセシビリティを調整する必要がある場合は、レスポンシブデザインのリファレンスを参照してください。

アクセシビリティを評価する

何が機能していないのか、誰に影響するのかを特定します。

1. まず自動チェックを実行します：

   • axe-core、WAVE、または Pa11y を使って重要なページをチェックします
   • 基準として WCAG 2.1 AA を目指します
   • 違反を重大度別に記録します：重大（タスクを妨げる）、深刻（回避が困難）、中程度（煩わしい）、軽微（仕上げ）
   • 自動チェックの結果は素早く問題を検知する手段として扱い、完全な監査とはみなしません

2. キーボード操作を手動でテストします：

   • マウスを外します。すべてのインタラクティブ要素に移動できますか？
   • Tab キーの移動順序は論理的で予測可能ですか？
   • フォーカスインジケーターは明瞭に表示されていますか？
   • キーボードトラップ（Tab キーで抜け出せない場所）はありますか？
   • カスタムコンポーネントは Enter、Space、Escape、矢印キーに応答しますか？

3. スクリーンリーダーでテストします：

   • NVDA（Windows）、VoiceOver（macOS/iOS）、または TalkBack（Android）を使用します
   • 見出し、ランドマーク、フォームフィールドから移動します
   • 動的なコンテンツの変更が通知されることを確認します
   • 装飾要素が支援技術から隠されていることを確認します
   • エラーメッセージやステータスの更新が読み上げられることを確認します

4. 視覚的なアクセシビリティを確認します：

   • コントラスト比を確認します：通常のテキストは 4.5:1、大きなテキストは 3:1、UI コンポーネントは 3:1
   • 水平方向のスクロールやコンテンツの欠落なしで、200％および 400％のズームをテストします
   • 色覚特性（第二色覚、第一色覚、第三色覚）のシミュレーションを行います
   • 状態や意味を示す手段が色だけにならないようにします
   • ハイコントラストモードを有効にしてもテキストが読みやすいことを確認します

5. 動きとアニメーションを確認します：

   • prefers-reduced-motion を有効にし、インターフェースが引き続き利用できることを確認します
   • 動きによる表示だけに重要な情報が隠されていないことを確認します
   • 自動再生コンテンツを一時停止または停止できることを確認します

領域ごとに問題を修正する

セマンティック HTML

目的に合った要素を使用します。ネイティブ HTML 要素には、アクセシビリティ機能が組み込まれています。

修正項目：

• <div> または <span> で作成したボタンを <button> 要素に置き換えます
• ナビゲーションには <a> のみを使用し、操作には <button> を使用します
• ランドマークには <nav>、<main>、<aside>、<header>、<footer> を使用します
• リストには、スタイルを設定した div ではなく <ul> / <ol> を使用します
• 表形式のデータには、CSS グリッドレイアウトではなく <table> を使用します
• for 属性を使って入力欄と明示的に関連付けた <label> を使用します
• 関連するフォーム項目のグループには <fieldset> と <legend> を使用します

削除すべきアンチパターン：

• role、tabindex、キーボードイベントハンドラーがない、クリック可能な div
• サイズ調整だけを目的に使われている見出し（<h1> から <h6> は文書構造を反映する必要があります）
• ラベルとして使われているプレースホルダーテキスト
• アクセシブルな名前がなく、アイコンだけがある空のリンクやボタン

キーボード操作

すべてのインタラクティブ要素は、マウスを使わずにフォーカスを移動して操作できる必要があります。

修正項目：

• すべてのインタラクティブ要素に tabindex="0" を設定するか、標準でフォーカス可能な状態にします
• フォーカス可能であるべき要素から tabindex="-1" を削除します
• 正の値を持つ tabindex を削除します（順序が予測できなくなります）
• カスタムコンポーネントにキーボードイベントハンドラーを実装します：
  • ボタン：Enter キーと Space キーで操作します
  • トグル：Enter キーまたは Space キーで切り替えます
  • メニュー：Enter キーで開き、Escape キーで閉じ、矢印キーで項目間を移動します
  • モーダル：Tab キーで内部を巡回し、Escape キーで閉じ、フォーカスを起動元に戻します
  • アコーディオン：Enter キーまたは Space キーで切り替え、矢印キーで項目間を移動します
• フォーカスが見えるようにします。outline: none でフォーカスリングを無効にする場合は、代わりに明確なフォーカスリングを用意します

フォーカス管理

フォーカスの移動は、意図的で、見やすく、予測可能である必要があります。

修正項目：

• SPA でルートが変わったとき、新しいページの見出しまたはメインコンテンツにフォーカスを移します
• モーダルが開いたときは、内部にフォーカスを閉じ込め、閉じたときに起動元へフォーカスを戻します
• ドロップダウンが開いたときは、最初の項目にフォーカスを移します
• エラーが発生したときは、エラー概要または最初の無効なフィールドにフォーカスを移します
• コンテンツが削除されたときは、論理的に適切な残りの要素にフォーカスを移します（document.body には移しません）
• ユーザーが明示的に操作を開始した場合を除き、ページの読み込み時にフィールドへ自動でフォーカスを設定しません

ARIA

ネイティブ HTML では不十分な場合に限り、ARIA を使用します。ARIA は動作を変えず、意味付けだけを行います。

ARIA を使用する場面：

• ネイティブ HTML に相当する要素がないカスタムコンポーネント（タブ、ツリービュー、複雑なメニュー）
• 明示的なロールが必要なランドマーク領域
• 動的なコンテンツの通知に使うライブリージョン
• 表示テキストでは提供できないアクセシブルな名前や説明

よくある ARIA の修正項目：

• モーダルに role="dialog" と aria-modal="true" を追加します
• 開閉ボタンやアコーディオンのトリガーに aria-expanded を追加します
• アクティブなナビゲーション項目に aria-current="page" を追加します
• ステータスコンテナに aria-live="polite" または aria-live="assertive" を追加します
• アイコンやアイコンのみのボタンに aria-label または aria-labelledby を追加します
• 補足テキストやエラーメッセージがある入力欄に aria-describedby を追加します
• 無効なフォームフィールドに aria-invalid="true" を追加します

ARIA のアンチパターン：

• 実際の <button> 要素に role="button" を追加しないでください
• フォーカス可能な要素に aria-hidden="true" を使用しないでください
• 競合するロールを使用しないでください（例：リンクに role="button" を指定する）
• インタラクティブ要素を別のインタラクティブ要素の中に入れないでください
• 対応するキーボード操作を実装せず、ARIA だけに頼らないでください

色とコントラスト

視覚能力にかかわらず、情報を認識できるようにします。

修正項目：

• WCAG AA のコントラスト比を満たします：通常のテキストは 4.5:1、大きなテキストと UI コンポーネントは 3:1
• 状態、エラー、必須項目の表示を色だけに頼らないでください
• 意味を持つ色には、テキストラベル、アイコン、または形状の違いを組み合わせます
• 色覚シミュレーションを使って、意味を持つ色の段階を確認します
• フォーカスインジケーターが背景に対して十分なコントラストを持つようにします
• 色付きのステータス表示に、見えるテキストラベルまたはアイコンを添えます

スクリーンリーダーのサポート

支援技術を利用するユーザーにも、同等の情報が伝わるようにします。

修正項目：

• 情報を伝える画像には説明的な代替テキストを指定し、装飾画像には空の代替テキストを使用します
• 動的な更新（検索結果、フォーム送信、通知）には aria-live 領域を使用します
• aria-describedby を使って、フォームのエラーを該当するフィールドに関連付けます
• すべてのアイコン、ボタン、コントロールにアクセシブルな名前を指定します
• 見出しを階層的に使用します（レベルを飛ばさないでください）
• 装飾的な SVG には aria-hidden="true" を指定するか、タイトルを含む role="img" を指定します
• テーブルには適切な th 見出しと scope 属性を指定します

動きとアニメーション

動きに耐えられない、または動きを望まないユーザーに配慮します。

修正項目：

• アニメーションを @media (prefers-reduced-motion: no-preference) で囲むか、動きを抑えた代替手段を用意します
• prefers-reduced-motion: reduce の場合は、動きを即時の状態変化や控えめなフェードに置き換えます
• 一時停止／停止コントロールなしで、動画やアニメーションを自動再生しないでください
• 視差効果やスクロールに応じた効果によって、方向感覚が失われないようにします
• カルーセル、スライドショー、オンボーディングツアーでは、動きに関する設定を尊重します

改善の検証

修正後、改善が機能していることを検証します。

• 自動チェックを再実行：以前の違反が解消され、新たな違反が発生していないことを確認します
• キーボード操作の確認：すべてのインタラクティブ要素を、もう一度順に Tab キーで移動します
• スクリーンリーダーでの確認：見出し、ランドマーク、フォームフィールドを使って移動します
• ズームテスト：200％および400％でも使いやすいことを確認します
• 色覚シミュレーション：状態やグラフを引き続き見分けられることを確認します
• 動きの軽減：prefers-reduced-motion を有効にしても、インターフェースが引き続き使いやすいことを確認します
• 実機：可能な場合は、実際の支援技術を使ってテストします

実践チェックリスト

• すべてのインタラクティブ要素にキーボードでアクセスできる
• フォーカスの順序が論理的で予測可能である
• フォーカスインジケーターが見える
• 可能な場合はネイティブの HTML 要素を使用している
• ARIA は HTML だけでは不十分な場合に限って使用している
• カスタムコンポーネントに適切なキーボード操作のハンドラーがある
• 色のコントラストが WCAG AA に適合している（テキストは 4.5:1）
• 状態や意味を伝える手段が色だけに頼っていない
• 画像に説明的な代替テキストがある（装飾画像はそのように指定されている）
• フォーム入力に対応するラベルがある
• フォームのエラーがフィールドに関連付けられ、読み上げられる
• 動的なコンテンツの変更に aria-live 領域を使用している
• タッチターゲットが少なくとも 44×44 ピクセルある
• 200％のズームでもインターフェースを使える
• 動きが prefers-reduced-motion に配慮している
• WCAG AA 違反なしで自動テストに合格している
• キーボードとスクリーンリーダーによる手動テストに合格している

絶対にしないこと：

• 自動テストだけに頼る
• 対応するキーボード操作を実装せずに ARIA を使用する
• 重要な情報を色だけに頼って伝える
• 代替手段を用意せずにフォーカスインジケーターを削除する
• 重要な操作について、実際の支援技術を使った手動テストを省略する
• アクセシビリティを継続的な取り組みではなく、一度きりの修正として扱う

アクセシブルなデザインは、誰にとっても使いやすいデザインです。アクセシビリティの問題を修正すると、通常はすべての人にとって使いやすさが向上します。