a11y

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

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

必須の準備

frontend-design を読み、その Context Gathering Protocol に従ってください。利用可能なコンテキストを再利用し、重要な情報が不足している場合に限り質問してください。

自動テストツールの統合（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% のズームをテストします
   • 色覚特性の違い（第2色覚異常、第1色覚異常、第3色覚異常）をシミュレートします
   • 状態や意味を伝える手段が色だけにならないようにします
   • ハイコントラストモードを有効にしても、テキストが読みやすいことを確認します

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 要素を使用している
• HTML では不十分な場合にのみ ARIA を使用している
• カスタムコンポーネントに適切なキーボードハンドラーがある
• 色のコントラストが WCAG AA（テキストは 4.5:1）を満たしている
• 状態や意味を伝える手段が色だけではない
• 画像に説明的な代替テキストがあり、装飾画像にはその旨が指定されている
• フォーム入力にラベルが関連付けられている
• フォームのエラーがフィールドに関連付けられ、通知される
• 動的なコンテンツの変更に aria-live 領域を使用している
• 粗いポインター向けのターゲットが少なくとも 44 × 44 ピクセルである
• 200% のズームでもインターフェースを使える
• 動きが prefers-reduced-motion を尊重している
• 自動テストが WCAG AA 違反なしで合格する
• 手動のキーボードテストとスクリーンリーダーテストに合格する

絶対にしてはいけないこと：

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

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