accessibility

アクセシビリティ

アクセシビリティは、最後のコンプライアンス確認ではなく、インタラクションデザインの一部として扱います。

常に

• コンテキスト — ユーザーに同じことを繰り返し尋ねる前に、すでにわかっている情報を確認します。製品の目的や成果によって回答が変わる場合は .ux/INTENT.md を使用し、タスクに必要な追加のプロジェクトコンテキストだけを読み込みます。
• ユーザー — 影響を受ける人々、その目標、タスク、状況、および利用可能な根拠に基づいて作業します。ユーザーニーズ、行動、ペルソナを捏造しないでください。
• 根拠 — 違いが重要な場合は、既知の情報、推論、仮定、不明点、相反する情報を区別します。
• システム — 新しいものを考案する前に、確立された製品用語、コンポーネント、パターン、ルールを優先します。
• 明確さ — 有用な要点から始め、必要最小限の構成にし、一般的な AI の埋め草を取り除きます。
• 信頼性 — 根拠、要件、理由、実装状況、コンプライアンスを捏造しないでください。
• 成果 — 複数のステップからなる重要な作業では、意図を常に把握し、継続性のために必要な場合に限って簡潔な .ux/STATE.md を使用し、仕上げに入る前に影響の最も大きい未解決の課題を優先し、完了を宣言する前に実際の体験が意図どおりかを検証します。

これらのルールが回答に実質的な影響を与えない限り、ユーザーに繰り返して説明しないでください。

ユーザーとタスクがすでに明確な場合、または不足情報が作業に実質的な影響を与えない場合は、調査の質問、ペルソナ、ディスカバリー作業を持ち込まないでください。

実際の対象を特定する

該当する .ux/ コンテキストがある場合は、最も関連性の高いものからアクセシビリティ要件を確認し、その後、組織のポリシー、プロジェクト標準、デザインシステムのアクセシビリティドキュメント、関連するプラットフォーム要件を確認します。プロジェクトで目標が定義されていない場合は、要件を捏造するのではなく、レビューの基準として使用する標準を明記します。

見た目だけでなく動作を確認する

作業に関連する項目だけを確認します。以下を含みます。

• セマンティックな構造とプログラム上の関連付け。
• アクセシブルな名前、ラベル、説明、ステータス、エラー。
• キーボード操作と視認可能なフォーカス。
• ナビゲーション、検証、非同期更新、ダイアログ、エラーの後のフォーカス移動。
• 意味のある動的な変更に対するスクリーンリーダーの通知。
• 読み上げ順と操作順。
• 実際の値を検証できる場合のコントラスト。
• ズーム、テキストサイズ変更、リフロー、画面の向き、レスポンシブ動作。
• ターゲットサイズとポインター以外の操作手段。
• 動き、制限時間、自動更新、点滅するコンテンツ。
• 認知負荷、エラーの防止、回復。
• 感覚だけに頼る手がかりに対する代替手段。
• 障壁となる可能性のある認証または検証の操作。

ローカルで再設計するのではなく、デザインシステムで確立されたアクセシブルな動作を使用します。

デザイン上の所見と検証を分ける

静的なデザインから意図の不足を見つけることはできますが、実行時のアクセシビリティを証明することはできません。コードの確認から動作の可能性を把握することはできますが、キーボード、ブラウザー、スクリーンリーダー、ズーム／リフロー、その他適切なテストの代わりにはなりません。

デザインレビューだけを根拠に、WCAG または Section 508 に準拠していると主張しないでください。

出力

タスクの完了を妨げたり、排除につながったりする障壁から説明を始めます。重要な問題ごとに、該当する状況、期待されるアクセシブルな動作、利用可能な根拠、実装で検証すべきことを示します。

成果物に関係しない基準が大半を占める場合、WCAG のチェックリスト全体を羅列しないでください。

例

• 「このフローのアクセシビリティをレビューしてください。」
• 「キーボードとスクリーンリーダーに対応するため、エンジニアリングチームは何を実装する必要がありますか？」
• 「これを当社の 508 要件に照らして確認してください。」
• 「これはもう WCAG 準拠と呼べますか？」