まずユーザーの選択とトークンシステムから始める
初期値は prefers-color-scheme を使ってシステム設定を採用します。切替を提供する場合は、キーボード操作可能なコントロールでアクセシブルな名前を付け、現在の選択をプログラム的に公開してください。ブラウザ文脈内で手動選択を優先させ、別のデバイスやプライベートセッションにそれが引き継がれると約束しないでください。
色は見た目でなく役割で命名してください：canvas、surface、text、muted text、border、link、accent、error、success、focus、disabled など。両テーマで各役割をマッピングします。これにより、ライト専用の灰色がダークモードに漏れるのを防ぎ、修正を再利用できるようになります。ダークは本質的によりアクセシブルでも普遍的に好まれるわけでもなく、使いやすくするべき別の体験です。
保存された選択を最優先、システム設定を次にするなどの順序を文書化してチームが同じ結果をテストできるようにします。
デフォルトだけでなく hover、focus、selected、invalid、disabled、loading、empty、visited-link といった状態も含めます。
レンダリングされたテーマでコントラストを測る
WCAG 2.2 の Success Criterion 1.4.3 は通常のテキストとテキスト画像に対して 4.5:1 の最小値、また大きなテキストには 3:1 を定めています。切り上げは不可：4.499:1 は 4.5:1 を満たしません。細い書体は計算上の色より弱く見えることがあるので、よりしっかりした字形か余白を使ってください。
それぞれのレンダリングされた前景と隣接する背景を確認してください。写真、グラデーション、不透明度のあるパネル、ビデオ上のテキストは背景が変化するため、単一のトークン計算では読みやすさを証明できません。不透明な裏打ち、十分なオーバーレイ、あるいは別の配置を使い、現実的なビューポートで検査してください。
WCAG 2.1 の Success Criterion 1.4.11 に従い、アクティブなコントロール、必須状態、意味のあるグラフィックを識別する視覚情報は隣接する色に対して 3:1 を満たす必要があります。
エラーや選択状態にはテキスト、アイコン、パターン、位置など色以外の明確な手がかりを付けます。微妙な色合いだけに依存してはいけません。
キーボードフォーカス、フォーム、状態変化を保護する
両テーマで Tab 操作を通して確認してください。リンク、ボタン、入力、メニュー、ダイアログ、カスタムウィジェット、テーマ切替のフォーカスは可視でなければなりません。ブラウザのアウトラインを単に取り除かないでください。代替手段を用いるならすべての表面と状態でテスト済みであることが必要です。オフセットされたアウトラインはブレンドするグローより明瞭なことが多いです。
WCAG 2.2 の Focus Appearance は AAA の基準であり、AA 適合の証明ではありませんが有用な目標です：少なくとも 2 CSS-pixel 周囲に相当する指示領域と、フォーカスされたピクセルと非フォーカスのピクセル間で 3:1 のコントラストが推奨されます。エラー、必須、選択、利用不可の状態が意味を保持することも検証してください。
入力ヒント、入力済み値、ラベル、ヘルプテキスト、エラーテキスト、無効境界、チェックボックスのマーク、ラジオの選択、送信状態を個別にテストします。
チェックアウトや規制対象のフローではプロバイダのサンドボックスを使い、適切な場合は資格あるアクセシビリティとセキュリティのレビューを受けてください。これは教育的ガイダンスであり、適合やセキュリティ評価を意味するものではありません。
画像、埋め込み資産、ブラウザ提供 UI を扱う
ロゴ、イラスト、スクリーンショット、チャート、アイコン、画像に焼き込まれたテキストを両テーマで確認します。再利用されたライト用ロゴが見えなくなることや、チャート凡例が機能しなくなることがあります。用途に合ったアセットや安定した背景を提供してください。指示、状態、データを伝える画像は理解可能なままである必要があります。
ライトとダークの両スキームをサポートすることを宣言し、選択されたテーマに対してページのコンテンツをスタイル設定します。color-scheme プロパティはブラウザのキャンバス、スクロールバー、フォームコントロールなどを整合させます。対応するメタデータは文書の早い位置に置いてください。埋め込み SVG は親スキームに応答できます。サードパーティ iframe やウィジェットはエンドツーエンドでテストしてください。
セマンティックな HTML コントロールを優先してください。forced-color 振る舞いは ARIA を付与した汎用要素ではなくネイティブのセマンティクスを使います。
ダウンロード中、キャッシュ済み、読み込みが遅い、画像失敗状態を検査し、特にメディア上にテキストやアクション手がかりがある箇所を確認します。
forced-colors を尊重し、システムとしてリリースをテストする
forced-colors モードは Windows High Contrast のようなユーザー選択の制限されたパレットを適用します。ブラウザは色を置き換え、影を除去し、テキストにバックプレートを追加することがあります。上書きを阻止しないでください。シャドウが担っていた手がかりを失うような場合は、実際の境界線を追加するなどターゲットを絞った修正を行ってください。エミュレーションはすべてのデバイス、ブラウザ、拡張、ズームレベル、支援技術の組み合わせを再現できません。
リリース前にライト、ダーク、forced-colors 設定でルートとインタラクションマトリクスを実行してください。Chrome DevTools は両方の条件をエミュレートできます。レビューを加速するのに使い、その後優先フローを手動で操作してください。スキャナは候補を見つけますが単独でアクセシビリティを判定できません。SIU は重要なテーマ資産とインタラクションを事前検査し、リリースゲートを記録し、深刻な表示回帰に備えたテスト済みのロールバック経路を保持します；これはダウンタイム監視ではありません。
ランディング、ナビゲーション、検索、アカウントアクセス、フォーム、エラーページ、認証済み画面、マテリアル変換フローを含めます。
テスト済みの URL、ブラウザバージョン、設定、例外、オーナー、ロールバックトリガーを保存し、修正が事実に基づいて開始できるようにします。