カラーアクセシビリティをAI開発ルールで守る方法
この記事で学べること
- ライト・ダーク・ホバー・選択・フォーカスを状態の組み合わせとして確認する理由
- 色の判断基準、用途名のある色、AIへの指示を共有ルールへ落とす方法
- 差分レビューで毎回確認する表示状態と対象箇所の固定方法
カラーアクセシビリティは状態ごとのルールで守る
デフォルト表示で読める色を選べば十分だと考えていましたが、実際にはダークモード、ライトモード、ホバー、選択、フォーカスのどこかでコントラストや状態表現が繰り返し崩れました。このサイトでVibe Coding（自然言語でAIに指示しながら実装する進め方）を続けた結果、色を単体で確認するのではなく、テーマと操作状態の組み合わせを実装前のルールへ戻す必要があると分かりました。その確認をハーネス（AIに渡すルール、作業手順、検証方法をまとめた仕組み）へ固定し、自動検査と画面上の確認を分けています。
この記事では、「テーマと操作状態をまたぐ色の不具合を、次の実装前にどう防ぐか」という問いに焦点を当て、期待と結果の差、確認できた条件、再発を防ぐ判断を扱います。
最後まで読むと、「テーマと操作状態をまたぐ色の不具合を、次の実装前にどう防ぐか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。
問題は単色ではなく状態の組み合わせだった
最初は「このボタンの色が薄い」「このカードの選択状態が見えにくい」と、個別の色を直していました。しかし実際に問題が起きていたのは、単色ではなく状態の組み合わせでした。
たとえば、ライトモードのデフォルト状態だけを見ると問題がないように見えても、ダークモードでホバーしたときに文字色と背景色が近づくことがあります。選択済みのカードでは読めるのに、フォーカスリングが背景や影に埋もれることもあります。Vibe CodingではAIが見た目の整った初稿を短時間で出してくれる一方で、すべての状態を横断して確認したとは限りません。
WCAG 2.2のコントラスト最小要件では、通常テキストは少なくとも4.5:1、大きなテキストは少なくとも3:1のコントラスト比が求められます。[1] そのため、色の確認は「通常状態のスクリーンショットを見る」だけでは足りません。状態、テーマ、背景、文字サイズを組み合わせて確認する必要があります。
手動レビューだけでは色の状態ごとの確認漏れが残る
この問題を手作業だけで潰そうとすると、毎回チェックリストを思い出す必要があります。記事カード、クイズ、サイドバー、ページネーション、タグリンクなど、似たようなUIが増えるほど、確認すべき状態も増えます。
自動検査ツールは有効ですが、W3Cはアクセシビリティ評価ツールについて、すべてのアクセシビリティ観点を自動では確認できず、人の判断が必要だと説明しています。[2] つまり、私が作るべきなのは「ツールを1つ入れて終わり」の仕組みではありません。AIへの指示、共有ルール、用途名で管理した色、差分レビュー、ブラウザ確認をつなぐ作業手順です。
共有ルールに色の判断基準を置く
最初に固定したのは、コンポーネント実装時の入口です。このサイトでは shared/rules/component-accessibility.md に、src/components/ 配下のコンポーネントを追加・変更するときのアクセシビリティ確認項目を置いています。
ここで重要なのは、色を「AIの都度判断」にしないことです。新しいコンポーネントでは、デフォルト、ホバー、フォーカス、選択状態の色を既存の用途別CSS変数（色や余白などを用途名で管理する値）から選ぶ方針にしています。リンクやボタン型UIは --btn-ghost-*、選択肢や番号バッジ型UIは --btn-choice-*、丸いアイコンや番号コンテナは --topic-btn-icon-* を優先します。
このルールにより、AIが毎回 --sl-color-accent や任意の color-mix() を直接使って新しい状態色を作る流れを避けやすくなります。既存CSS変数で表現できない場合は、コンポーネント内で色を閉じ込めるのではなく、用途名を持つCSS変数を先に追加する、という判断に戻します。
用途名のある色で試行錯誤を再利用する
src/styles/custom.css には、ライトモードとダークモードの両方で使うボタン、選択肢、トピックアイコン、ページネーション用のCSS変数を置いています。ここに集めると、個別コンポーネントの修正で得た学びを次の実装に再利用できます。
私が特に意識しているのは、状態を次のように分けて見ることです。
| 観点 | 見る状態 | ハーネス側の工夫 |
|---|---|---|
| テーマ | ライト / ダーク | 同じ用途名のCSS変数を両テーマで定義する |
| 操作 | デフォルト / ホバー / フォーカス | focus-visible とホバー色を同じ場所で確認する |
| 選択 | 未選択 / 選択済み | --btn-choice-* のように選択用CSS変数を分ける |
| 背景 | カード / サイドバー / 本文 | 近い用途の既存コンポーネントを参照する |
| 修正 | その場の色指定 / CSS変数追加 | 使い回す色は用途名を付けて共有する |
この表は、AIに渡すためだけではなく、私自身がレビューするときの観点でもあります。人の確認をなくすためではなく、確認すべき場所を毎回同じ形にするためのハーネスです。
AIへの指示を状態単位に変える
以前は「アクセシビリティに配慮して」「ダークモードでも見やすくして」と依頼しがちでした。しかし、この書き方ではAIがどの状態を確認すべきか判断しにくくなります。
今は、次のように状態を明示して依頼します。
新しい選択カードコンポーネントを実装してください。
色と状態の条件:
- ライトモードとダークモードの両方で確認する
- デフォルト、ホバー、フォーカス、選択済み状態を定義する
- 既存の --btn-choice-* CSS変数を優先する
- 新しい color-mix() を直接追加しない
- 通常テキストは WCAG AA のコントラストを満たす前提で調整する
- focus-visible のアウトラインが背景や影に埋もれないようにする
実装後に、各状態で使ったCSS変数と未確認の状態を短く報告してください。最後の「未確認の状態を報告」は、Vibe Codingでは重要です。AIが完成したと言っても、確認していない状態は残ります。未確認のまま完了扱いにしないために、完了報告の形式もハーネスに含めます。
差分レビューでテーマ・操作・選択状態の色を確認する
実装後は、ブラウザで見た目を確認する前に差分を見ます。色アクセシビリティでは、次の点を重点的に見ます。
- 既存CSS変数ではなく、コンポーネント内に新しい状態色が直接書かれていないか
- ライトモードだけ、またはダークモードだけの指定になっていないか
:hoverはあるが:focus-visibleがない状態になっていないか- 選択状態が背景色だけで伝えられていないか
- フォーカスリングが影、枠線、背景色に埋もれていないか
disabled、aria-selected、aria-currentなどの状態と見た目がずれていないか
この確認は、現在の私のハーネスでは完全な自動化ではありません。npm run harness:check はブログ品質、リポジトリ上の主張、重複、共有ハーネスの不整合を検出しますが、すべての色の組み合わせを視覚的に判断するものではありません。だからこそ、共有ルールと差分レビューを組み合わせ、機械チェックで拾える範囲と人が見る範囲を分けています。
まとめ：色アクセシビリティは状態別の確認を次の実装前へ戻す
一方で、この記事で扱っているのは、その中でも私が実際に繰り返し確認漏れを起こしやすかった「色と状態」の問題です。ドキュメントは基本概念、ブログはこのサイトで発生した具体的な問題とハーネス化の試行錯誤、という役割に分けています。
Vibe Codingで作ったUIのアクセシビリティを安定させるには、AIに「良い色にして」と頼むだけでは足りません。ライトモード、ダークモード、デフォルト、ホバー、フォーカス、選択状態を組み合わせて確認する必要があります。
私が構築しているハーネスは、次の考え方です。
- 色の判断基準を
shared/rules/component-accessibility.mdに置く - 実装では
src/styles/custom.cssの用途別CSS変数を優先する - AIへの依頼では状態を列挙し、未確認の状態を報告させる
- 差分レビューでは直接色指定、片方のテーマだけの指定、フォーカス漏れを見る
- 自動検査と手動確認を分け、機械チェックだけで完了扱いにしない
Vibe Codingの速度を活かすには、毎回同じ問題を人が思い出して直すのではなく、失敗した観点を次の実装前に参照できる形へ戻す必要があります。色アクセシビリティのハーネスは、そのための実務的な仕組みです。
最初の行動は、利用頻度の高いUI部品を1つ選び、ライト、ダーク、ホバー、選択、フォーカスで確認する組み合わせを書き出すことです。自動検査で色の意味や見え方をすべて判断することはできないため、実画面での確認は人のレビューとして残します。
参考文献
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2, 2024年12月12日
- W3C Web Accessibility Initiative, Selecting Web Accessibility Evaluation Tools, 2024年5月13日更新
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。