accessibility-inclusive-design

アクセシビリティを取り入れたインクルーシブデザイン

目的

アクセシブルで、インクルーシブで、キーボードで操作しやすく、スクリーンリーダーに配慮した、多様な人々が使いやすいインターフェースを、エージェントが設計・評価できるよう支援します。

このスキルを使って、アクセシビリティを通常の設計実践に取り入れます。アクセシビリティを、後回しの QA 作業や法令遵守のチェック項目ではなく、プロダクト品質の一部として扱います。

このスキルを使う場合

ユーザーが次の内容について支援を求めている場合に、このスキルを使います。

• UI、UX、フロントエンドの実装、プロダクトデザイン、またはデザインシステムに関する作業。
• アクセシビリティの評価、監査、修正、再設計、または適合計画。
• フォーム、ナビゲーション、メニュー、フィルター、製品リスト、メディア、目次、動的読み込み、またはインタラクティブなウィジェット。
• キーボード操作、フォーカス管理、スクリーンリーダーの動作、セマンティック HTML、ARIA、色のコントラスト、タイポグラフィ、レスポンシブな動作、またはインクルーシブなコンテンツ。
• 視覚、聴覚、運動、認知、言語、デバイス、帯域幅、または状況に制約があるユーザー向けのデザインの既定値。

このスキルを使わない場合

次の内容については、このスキルを主なスキルとして使わないでください。

• インクルージョンやアクセシビリティに関係のない、幅広い UX リサーチの計画。
• インターフェースの動作、コンテンツ、ユーザーのタスクを設計しない、ブランドだけを対象としたビジュアルの検討。
• ユーザー向けのアクセシビリティに影響しない、バックエンドのみのアーキテクチャ。
• 法的助言。アクセシビリティ上のリスクを示し、規格に沿ったレビューを推奨することはできますが、法的判断は行わないでください。

基本原則

1. 平均的なユーザーではなく、実際の多様性に合わせて設計します。 人によって能力、技術、言語、注意力、リテラシー、デバイス、帯域幅、環境は異なります。デザイナーの環境でしか機能しない解決策は避けてください。
2. 目的とユーザーのタスクから始めます。 目的を明確にすることで、複雑さ、認知負荷、実装の無駄を減らせます。
3. ネイティブなセマンティクスと標準的なウェブの動作を優先します。 JavaScript と ARIA で動作を再現する前に、すでにロール、状態、キーボード操作、プラットフォーム連携を備えた HTML 要素を使います。
4. 構造を機械が読み取れるようにします。 見出し、ランドマーク、リスト、ラベル、フォームコントロール、代替テキスト、キャプション、ドキュメントメタデータは、すべてインターフェースの一部です。
5. 段階的に機能を強化します。 意味のあるコンテンツと動作する HTML から始めます。基本機能を損なわず、体験を向上させる場合にのみ CSS と JavaScript を追加します。
6. ユーザーに選択権を与えます。 ユーザーが選べる場合は、ズームを妨げたり、フォーカスを閉じ込めたり、メディアを自動再生したり、動きを強制したり、無限スクロールを導入したり、表示設定を勝手に決めたりしないでください。
7. 慣例をアクセシビリティ機能として活用します。 慣れ親しんだナビゲーション、リンクのスタイル、ボタンの操作性、フォームのパターン、一貫した配置によって、認知的な負担を軽減できます。
8. 隠れた状態を明示します。 何かが展開、読み込み、エラー、選択されたり、動的に変化したりする場合は、その状態を視覚的にもプログラム上でも伝えてください。
9. コンテンツはデザインの一部です。 明確な見出し、内容がわかるリンク、平易な言葉、使いやすいラベル、役立つエラーメッセージは、アクセシビリティ機能です。
10. 自動テストだけに頼らないでください。 自動チェックは役立ちますが、キーボードでの操作確認、スクリーンリーダーでの確認、デバイスやブラウザーでのテスト、障害のある参加者からのフィードバックによって、自動化では見つからない問題を発見できます。

各原則を再利用可能なカードとしてまとめた内容は、references/principle-cards.md を参照してください。

既定の推奨事項

ユーザーがより具体的なプロダクトの状況や制約を示していない場合は、これらの既定値を使用します。

領域	デフォルト	通常これが最適な理由	例外を認めるのは次の場合のみ
アクセシビリティの目標	WCAG AA レベルの期待値と現在の製品／プラットフォーム標準を満たすように設計し、法的適合は最低ラインであって目標ではないと考えます。	アップロードされた資料では、アクセシビリティは組み込みの品質として繰り返し位置づけられており、AA は一般的な適合目標として示されています。	ユーザーに規制対象となる状況、社内標準、または特定の適合目標がある場合。
製品の目標	レイアウトやスタイルを決める前に、主なユーザータスクを明確にします。	目的が明確だと、判断が簡単になり、障壁も減ります。	ユーザーが限定的なコンポーネントの修正だけを求めている場合。
セマンティクス	まずネイティブ HTML を使います：button、a、label、input、fieldset、legend、nav、main、見出し、リスト。	ネイティブ要素には、想定されたキーボード操作や支援技術の動作が備わっています。	必要なインタラクションに適したネイティブのパターンがない場合。
ARIA	適切なマークアップに不足している名前、関係性、ライブ更新、状態を追加する目的に限り、ARIA を使います。	ARIA はセマンティクスを変えますが、動作を自動的に追加するものではありません。	カスタムコンポーネントに ARIA のロール／状態と、それに対応するキーボード操作が本当に必要な場合。
レイアウト	柔軟で、コンテンツに応じて変化し、レスポンシブなレイアウトを使い、固定幅／固定高さは避けます。	コンテンツ、デバイスのサイズ、ズーム、テキスト設定はさまざまです。	固定寸法がメディア固有の要件、または制約のあるプラットフォーム領域に不可欠な場合。
ブレークポイント	特定のデバイスに合わせるのではなく、コンテンツが崩れる箇所にブレークポイントを追加します。	デバイス固有のブレークポイントでは、あらゆる環境に対応できません。	ネイティブアプリまたは組み込み領域に、既知の固定制約がある場合。
タイポグラフィ	読みやすい書体、相対単位、ゆとりのある行間、快適な一行の長さ、実際のコンテンツを使います。	読みやすさは、弱視の方、ディスレクシアの方、認知負荷の影響を受ける方、言語学習者など、すべての人に役立ちます。	ブランド書体に制約がある場合は、サイズ、間隔、太さ、コントラストをテストして調整します。
コントラスト	十分なコントラストを確保し、色だけに頼らないようにします。不必要に低いコントラストを避け、まぶしさが極端に強い表示だけを選択肢にしないようにします。	コントラストが低いと多くのユーザーが利用しづらくなり、過度なまぶしさは一部の読者に害を及ぼすことがあります。	ブランドのカラーパレットが固定されている場合は、コントラストと見やすさを満たすようにデザイントークンを調整します。
リンク	インラインリンクは視覚的に識別できるようにし、通常は下線を付けます。また、リンクテキストだけで意味が分かるようにします。	スクリーンリーダーではリンクが個別に一覧表示されるため、色だけで識別するリンクでは多くのユーザーに対応できません。	CTA をボタンのように見せることはできますが、その場合も明確なテキストが必要です。
ナビゲーション	ランドマークを使ったリスト形式のナビゲーションを採用し、なじみのある場所に配置して、現在位置を明確に示します。	視覚的な表示、CSS がない場合、支援技術の利用のいずれにも対応できます。	非常に短いフローで、ナビゲーションが本当に不要な場合。
メニュー	短いメニューは隠しません。開閉式メニューでは、実際のボタン、表示されるラベル、aria-expanded、隣接するメニュー、確実な非表示状態を使います。	ナビゲーションを隠すと、操作の手間と状態の複雑さが増します。	画面スペースが著しく限られている場合、またはメニュー項目が多い場合。
フォーム	常に表示されるラベル、有用な場合はグループ化されたコントロール、明確な必須項目の表示、寛容なバリデーション、エラーからの回復を採用します。	フォームは、認知、運動、スクリーンリーダーの利用における障壁が生じやすい領域です。	極めて短いフォームではグループ化が不要な場合もありますが、ラベルは引き続き必須です。
バリデーション	まず送信時に検証します。エラーが発生した後は、ユーザーが修正する間、支援的なインラインフィードバックを提供します。	時期尚早なライブバリデーションは、煩雑でストレスになることがあります。	入力項目のコストが高い場合、またはセキュリティ上重要で、即時フィードバックが明らかに有用な場合。
パスワード	パスワードの再入力を強制するのではなく、パスワード表示コントロールを優先します。	ユーザーが操作を制御できる状態を保ちながら、認知的・身体的な負担を軽減できます。	セキュリティポリシーで表示コントロールが禁止されている場合。
動的読み込み	無限スクロールよりも、明示的な「さらに読み込む」操作やユーザーが開始する更新を優先します。読み込みを通知し、新しいコンテンツが表示された後にフォーカスを移動します。	無限スクロールは、キーボード操作、制御、現在位置の把握を損ないます。	自動読み込みが想定されることを調査で実証でき、アクセシブルな代替手段も用意されている場合。
メディア	キャプション、文字起こし、意味のある画像の代替テキストを提供します。	ユーザーによって必要な感覚情報や利用状況が異なります。	装飾画像には説明を付けず、空の alt テキストを使います。
モーション	モーションは任意で、目的が明確で、ユーザーが制御できるようにします。	モーションは注意をそらしたり、方向感覚を失わせたり、症状を引き起こしたりする可能性があります。	モーションが不可欠な状態を伝える場合でも、動きを抑える設定に対応します。
テスト	少なくとも、キーボードのみの操作、フォーカス、セマンティクス／DOM、コントラスト、レスポンシブ／ズーム、スクリーンリーダーの簡易チェックを実施します。	自動化では、実際の操作品質を検証できません。	概念検討のみのタスクであっても、リリース前に必要なテストについて説明します。

必須の確認事項

定型的なベストプラクティスについて、ユーザーに承認を求めないでください。デフォルトを適用し、その理由を説明してください。

回答が重要な推奨事項に影響する場合に限り、焦点を絞った質問を1つだけしてください。利用可能な場合は、question ツールまたは同等の機能を使用してください。

以下の場合に質問してください。

1. 規制上または組織上の目標が不明で、コンプライアンスが中心となる場合。
   • デフォルト：WCAG AA レベルの設計と現在の製品標準。
2. 対象ユーザー、支援技術、言語、地域、またはプラットフォームによって設計が大きく変わる場合。
   • デフォルト：幅広いウェブユーザー、キーボードとスクリーンリーダーへの対応、レスポンシブなブラウザー動作。
3. ネイティブ HTML ではなく、独自の操作パターンが必要となる可能性があるコンポーネントがある場合。
   • デフォルト：ネイティブ HTML またはよりシンプルなパターン。
4. ブランドの語調が、明確なラベル、平易な言葉、または認識しやすい操作要素と相反する場合。
   • デフォルト：ブランドの個性よりも、タスクが明確に伝わる表現を優先。
5. 動的な動作によって、ユーザーの制御、フォーカス、または方向感覚が変わる可能性がある場合。
   • デフォルト：ユーザーが明示的に開始する操作と、視覚的およびプログラムによるフィードバック。
6. ユーザーが法的または適合性に関する主張を求める場合。
   • デフォルト：設計および実装に関する推奨事項を提示し、専門家または法律の専門家による検証を勧める。

references/decision-prompts.md にある、質問ツールですぐに使えるプロンプトを使用してください。

ワークフロー

A. 既存の UI、スクリーンショット、コード、またはフローの評価

次の順序で確認してください。

1. タスクと目的
   • ユーザーは何をしようとしていますか？
   • 主な操作の流れは明確で、不要な複雑さは取り除かれていますか？
2. 構造とセマンティクス
   • ドキュメントのタイトル、言語、見出し、ランドマーク、リスト、コントロール、ラベル、関連性は適切ですか？
   • ソースの順序は、読み上げ順序とフォーカス順序に一致していますか？
3. キーボードとフォーカス
   • すべてのインタラクティブ要素に、キーボードで移動してフォーカスを表示し、操作し、抜けられますか？
   • フォーカス状態は視認でき、削除されていませんか？
   • 開示、ページ内リンク、入力検証、動的な読み込みの後に、フォーカスは適切に管理されていますか？
4. 操作の動作
   • コントロールは、それが何であるか認識できますか？
   • 状態や変化は、視覚的かつプログラムによって伝えられていますか？
   • インターフェースはユーザーの操作を尊重していますか？
5. コンテンツとラベル
   • 見出し、リンク、フォームラベル、ボタン名、指示、エラーは、文脈から切り離されても明確ですか？
   • タスクの明確さよりもブランド表現を優先していませんか？
6. 視覚的な表現
   • コントラスト、文字サイズ、行間、行の長さ、間隔、グループ分けは読みやすいですか？
   • 情報は色、位置、または音だけで伝えられていませんか？
7. フォームとエラー
   • ラベルは常に表示され、入力欄と関連付けられていますか？
   • 必須項目は明確ですか？
   • エラーは通知され、ユーザーの作業箇所の近くに表示され、対処方法が示されていますか？
8. メディアと代替手段
   • 画像、アイコン、動画、音声、テキスト以外の手がかりには、適切な代替手段がありますか？
9. レスポンシブ対応と環境への耐性
   • ズーム、文字サイズの変更、狭い／広いビューポート、低速なネットワーク、CSS／JS の無効化、ユーザーのフォント／色の設定に対応していますか？
10. テストと保守性

• アクセシビリティの確認は、コンポーネント／デザインシステムのワークフローに組み込まれていますか？

評価結果は、次の形式で提示してください。

• 重大度：ブロッカー、重大、中程度、軽微。
• 影響を受けるユーザー：キーボードユーザー、スクリーンリーダーのユーザー、弱視のユーザー、認知的負荷、運動機能へのアクセス、言語／読み書き能力、低帯域幅など。
• 重要である理由。
• 推奨する修正。
• 実装上の注意点。
• 検証テスト。

B. デザインを作成または改善する

次の順序で進めます。

1. 機能とユーザーのタスクを明確にします。
   • 不明な点があれば、焦点を絞った質問を1つし、デフォルト案を提示します。
2. 役に立つ最もシンプルなパターンを選びます。
   • 標準のコントロールと一般的な慣例を優先します。
3. 構造を整えます。
   • スタイルを適用する前に、見出し、領域、読み上げ順序、ナビゲーション、フォームグループ、コンテンツ間の関係を定義します。
4. ラベルとコンテンツを作成します。
   • 直接的で、説明的かつ文脈に依存しない文言を使います。
5. インタラクションと状態を定義します。
   • キーボード操作、フォーカス順序、可視フォーカス、状態の通知、読み込み、エラー、復旧方法を指定します。
6. ビジュアルデザインを適用します。
   • タイポグラフィ、コントラスト、余白、グループ化、操作可能であることの示し方、レスポンシブな動作を調整します。
7. プログレッシブエンハンスメントを追加します。
   • HTML の基本形が動作してから JavaScript を追加します。
8. エッジケースを検証します。
   • ズーム、長いコンテンツ、ローカライズ、該当する場合は RTL、低速ネットワーク、CSS／JS 無効時、代替入力をテストします。
9. 判断の理由を説明します。
   • 推奨事項を規格だけでなく、ユーザーへの影響に結び付けます。

判断フレームワーク

パターンを選ぶときは、ユーザーのタスクを満たす最初の選択肢を優先します。

1. インタラクションが不要： セマンティックな静的コンテンツを使います。
2. 標準のインタラクションがある： 標準の要素を使います。
3. 標準のインタラクションをスタイル設定できる： 標準の動作は維持し、コントロールを置き換えるのではなく、ラベルやコンテナーにスタイルを適用します。
4. プログレッシブエンハンスメントで十分： 基本のフォーム／リンクの動作を維持し、JS で拡張します。
5. カスタムのインタラクションが避けられない： ロール、名前、状態、キーボード操作、フォーカス管理、視認できる操作可能性、説明、テストを含む完全なパターンを実装します。
6. コンテンツを隠したり、操作を制限したりするパターン： 再検討します。製品のコンテキスト上、本当に必要かを確認します。
7. ユーザーの設定に依存するパターン： 選択肢を提供するか、ブラウザー／OS の設定を尊重します。

実践的なルール

ドキュメントとページの構造

• 有効な doctype を含めます。
• lang でページの言語を宣言し、右から左に記述する言語では dir を宣言します。
• 現在のページまたは結果の状態を示す、意味のあるドキュメントの <title> を1つ使用します。
• ページ固有のコンテンツには、主要な <main> 領域を1つ使用します。
• 視覚的にページを見ながらキーボードを使うユーザーのために、メインコンテンツへのスキップリンクを用意します。
• 見出しは構造を示すために使い、文字サイズを調整するために使いません。スタイルを実現するためだけに見出しレベルを飛ばさないでください。
• グループ化されたナビゲーションやコンテンツにはリストを使います。
• 上から下へ読んだときに、ソースの順序が自然になるようにします。

ナビゲーションと現在位置の把握

• 主要なナビゲーションは nav ランドマーク内に配置します。
• 複数のナビゲーションランドマークには、「サイト」や「目次」など、それぞれ異なるラベルを付けます。
• 親しみやすい配置と、見慣れた形状を維持します。
• 現在のページ／セクションは、色以外の方法も使って示します。
• 現在のページへのリンクでは、冗長な再読み込み動作を避けます。適切な場合は、同じページのメインコンテンツへのリンクを使うか、現在の状態を明確に説明します。
• セクション間の移動が目的で長いページを作る場合は、複雑なドロップダウンのサブメニューではなく目次を使います。

ボタン、リンク、コントロール

• アクションには button を、ナビゲーションには a href を使います。
• 標準の要素が適している場合、クリック可能な div や span は使いません。
• ボタンやリンクの操作可能性を取り除く場合は、同じくらい明確な操作可能性を別の方法で示します。
• アイコンのみのコントロールには、アクセシブルな名前が必要です。スペースに余裕があれば、表示されるテキストを優先します。
• タッチターゲットには十分な大きさを持たせ、互いに間隔を空けます。幅の狭いタッチ画面では、縦並びのナビゲーションを行全体に広げます。
• 見えない要素にはフォーカスできないようにします。

キーボードとフォーカス

• 操作可能なすべてのコントロールに、キーボードでアクセスできるようにします。
• フォーカスされたすべてのコントロールに、視認できるフォーカスインジケーターを表示します。
• より明確な代替手段を用意しない限り、outline: none は設定しないでください。
• ナビゲーションの順序を入れ替えるために、正の値の tabindex は使用しないでください。代わりに、ソースの順序を修正します。
• tabindex="-1" は、スムーズスクロール後のページ内見出しや新たに読み込まれたコンテンツなど、プログラムからフォーカスを移す対象にのみ使用します。
• JavaScript でネイティブの動作を置き換える場合は、フォーカスの移動、URL の更新、期待されるキーボード操作を復元します。

フォーム

• すべての入力欄に、常に表示される関連付けられたラベルを設定します。
• プレースホルダーのテキストはヒントにのみ使用し、唯一のラベルとして使用しないでください。
• 複数の関連するコントロールを明確にする場合は fieldset と legend を使用し、メリットがなく煩雑になる場合は使用を避けます。
• タスクの完了に必要な情報だけを尋ねます。
• 必須項目を視覚的にもプログラム上でも明示します。
• エラーはページ上部だけでなく、ユーザーが現在作業している場所の近くに表示します。
• 「エラーがあること」と「この項目の修正方法」を分けて伝えます。
• 必要に応じて、無効な項目と修正方法を示すテキストに aria-invalid と aria-describedby を使用します。
• 非同期フォームや読み込み状況のフィードバックにはライブリージョンを使用します。ただし、キー入力のたびに過剰に通知しないでください。
• ライブ検証にはデバウンスを適用し、通知が騒がしくなったり、過度に積極的になったりしないようにします。
• ポリシー上の制約がない限り、パスワード欄を複製するよりも「パスワードを表示」を使用します。

動的コンテンツ

• 変更の影響が大きい場合は、「フィルターを適用」や「さらに読み込む」など、明示的な操作を優先します。
• 読み込み中であることと完了したことを、スクリーンリーダーに通知します。
• リクエストの処理中に、読み込み操作が重複して実行されないようにします。
• 新しいコンテンツの読み込み後、トリガーが移動してしまった場合は、フォーカスを最初の意味のある新しい項目に移します。
• デフォルトでは無限スクロールを避けます。
• ライブリージョンを使う場合は、緊急度に応じてポライトまたはアサーティブの動作を選び、必要がない限り通常の読み上げを中断しないようにします。

視覚デザインと読みやすさ

• 早い段階から実際のコンテンツを使用します。理想化されたプレースホルダーテキストだけでデザインしないでください。
• 読みやすさ、文字の識別性、言語サポート、必要なウェイトやスタイルを考慮して書体を選びます。
• テキスト、余白、レイアウトには相対単位を使用します。
• 読みやすい行長を保ち、テキストブロックが広すぎたり狭すぎたりしないようにします。
• 書体のテストで別の値が適切と確認されない限り、本文の行高には通常 1.5 程度の単位なしの値を使用します。
• ハイフネーションと言語サポートが確実に機能し、テスト済みでない限り、Web の本文には両端揃えを避けます。
• テキストや UI の状態には十分なコントラストを確保します。ただし、唯一の読み取りモードとして不必要に強いコントラストを使うのは避けます。
• 状態は色だけに頼らず、形状、テキスト、アイコン、配置、パターンで伝えます。
• 余白と近接性を活用して、グループ分けを明確にします。

メディアと非テキストコンテンツ

• 装飾画像には空の alt テキストを設定します。
• 情報を伝える画像には、目的や内容が分かる簡潔な alt テキストを設定します。
• リンク画像には、画像の説明だけでなく、リンク先や操作を説明するテキストを設定します。
• 複雑な画像、インフォグラフィック、グラフには、周囲の説明または構造化されたテキストによる代替情報が必要です。
• 音声を含む動画には、字幕と文字起こしを用意します。
• 字幕では、話者の切り替わりと重要な非音声を特定します。
• メディアプレーヤーは、キーボードで操作でき、フォーカスが視認でき、スクリーンリーダー向けのラベルが付いている必要があります。

国際化と環境への適応性

• 言語、住所形式、名前の形式、日付形式、デバイス、接続速度、ポインターの種類、ビューポートが一つだけだと想定しないでください。
• 国際的な違いが想定される場合は、柔軟なデータ構造と UI ラベルを使用します。
• 長いラベル、翻訳された文字列、名前、製品名、長さが変わるコンテンツをテストします。
• RTL 言語を対象とする場合は RTL レイアウトをサポートし、dir に応じて変化するレイアウトシステムを優先します。
• ブラウザーのズーム、テキストサイズの変更、ユーザーのフォント選択、高コントラスト設定を妨げないでください。
• Web フォント、アイコン、スクリプトは、読み取りや基本操作に必須ではなく、機能を強化するものとして扱います。

アクセシビリティとインクルージョンの要件

仕上げる前に、次の点を確認してください。

• マウスを使わずに製品を利用できます。
• フォーカス順序が視覚的・論理的な順序に従っています。
• フォーカスは常に視認できます。
• インタラクティブな要素には、アクセシブルな名前、ロール、状態、値があります。
• 重要なコンテンツが、背景画像、疑似要素、色、音声、またはレイアウト上の位置だけに隠されていません。
• 見出しやランドマークを使ってページ構造をナビゲートできます。
• 支援技術を使って、フォームの内容を理解し、入力し、修正して送信できます。
• エラー、読み込み中、展開／折りたたみ、選択済み、無効の状態が、視覚的にもプログラム的にも伝わります。
• ズーム、テキストサイズの変更、小さな画面、ユーザーのフォント設定、低速なネットワーク環境でも、テキストを読み取れます。
• メディアには代替手段が用意されています。
• 自動チェックに加え、キーボードと支援技術を使った手動チェックも実施します。

フロントエンド実装ガイドライン

• まずセマンティックな HTML を使い、次に CSS、最後に JavaScript を追加します。
• 可能な限りネイティブなコントロールを使います。入力要素を置き換えるのではなく、ラベルやラッパーをスタイル設定してください。
• [aria-invalid="true"]、[aria-expanded="true"]、[aria-pressed="true"] など、セマンティックな状態に結び付いた CSS 属性セレクターを使い、状態とスタイルのずれを減らします。
• 動作するフォームやリンクによる代替手段が可能な場合、基本的な操作に JavaScript が必須となるコントロールを作成しないでください。
• コンポーネントがコンテンツを非表示にする場合、非表示のコンテンツがフォーカス順序から除外されていることを確認します。
• コンポーネントがコンテンツを表示する場合、そうしない強い理由がない限り、表示されたコンテンツをソース順でトリガーの近くに配置します。
• コンポーネントがページのコンテンツを非同期に変更する場合、ライブリージョンによるフィードバックと、意図的なフォーカス管理を用意します。
• フォーカス、コントラスト、間隔、無効状態、エラー状態、タッチターゲットのサイズにはデザイントークンを使い、システムにアクセシビリティを組み込みます。
• 長いコンテンツ、異なる言語、アセットの欠落、CSS の無効化、スクリプトの失敗、ハイコントラストモード、ズーム、キーボードのみの操作でコンポーネントをテストします。
• デザインシステムでは、各コンポーネントの期待されるマークアップ、キーボード操作、ARIA の状態、フォーカスの挙動、コンテンツのルール、アンチパターンを文書化します。

品質チェックリスト

references/checklists.md にある完全版のチェックリストを使用してください。回答する前に、少なくとも次の点を確認してください。

• 推奨事項がユーザーのタスクを起点としています。
• カスタムコントロールよりもネイティブなセマンティクスを優先しています。
• キーボード操作とフォーカスの挙動が指定されています。
• 該当する場合、スクリーンリーダー向けの名前、状態、関連付けが指定されています。
• 色だけを手掛かりにしていません。
• テキストとラベルは、文脈から切り離されても明確です。
• エラー、読み込み中、空の状態が含まれています。
• レスポンシブ対応、ズーム、可変コンテンツへの対応が考慮されています。
• ユーザーへの影響を説明し、テスト手順を示しています。

よくある間違いとその回避方法

アンチパターンの一覧は references/anti-patterns.md にあります。特にリスクの高い間違いは次のとおりです。

• クリック可能な div コントロール。
• プレースホルダーだけのラベル。
• フォーカススタイルの削除。
• ズームの無効化。
• ナビゲーションの不必要な非表示。
• アクセシブルな名前のない、アイコンのみのコントロール。
• 色だけで示す状態。
• 明示的な代替手段のない無限スクロール。
• JavaScript に依存する静的コンテンツ。
• ソース順序／フォーカス順序と異なる視覚的な順序。
• 壊れたネイティブパターンを修正するための ARIA の使用。
• 自動テストだけに頼ること。

推奨事項をユーザーに説明する方法

実用的で、ユーザーへの影響が伝わる表現を使います。

• 「これは単なるコンプライアンス対応ではありません。キーボードやスクリーンリーダーを使うユーザーが行き詰まるのを防ぎます。」
• 「ネイティブ要素のほうがシンプルで信頼性に優れています。ブラウザーがすでにロール、キーボード操作、プラットフォームとの連携を提供しているからです。」
• 「スクリーンリーダーではコントロールやリンクを個別に一覧表示できるため、このラベルは前後の文脈がなくても意味が伝わる必要があります。」
• 「視覚的な状態には、支援技術にも同じ情報が伝わるよう、プログラムから取得できる状態も必要です。」
• 「このパターンはユーザー自身が操作を制御できるようにします。そうしなければ、インターフェースが予期しない動作をすることになります。」
• 「デフォルト設定はより多くのユーザーを受け入れられるものであり、ブランドらしさを表現することも妨げません。」

トレードオフを推奨する場合は、次の点を示します。

1. デフォルト設定
2. 保護されるユーザーグループ
3. コストまたは制約
4. 例外を認める条件
5. 例外をどのようにテストするか