はじめに 🌟
Fluent UI 2 のアクセシビリティというと、まずはキーボード操作やスクリーンリーダー対応を思い浮かべる方が多いかもしれません。ですが、実際の画面レビューで何度も問題になりやすいのは、色の使い方です。エラーを赤だけで伝えていないか、選択状態が色だけに依存していないか、アイコンや枠線が背景に埋もれていないか、といった論点です 🎨
以前、Fluent UI 2 のアクセシビリティ全体像については、Qiita にまとめました。今回はそのスピンオフとして、色に絞って掘り下げます。全体像から入りたい方は、こちらもあわせてご覧ください。
この記事は、次のような方を想定しています。
- Fluent UI 2 を使って業務アプリや社内システムを作っている方
- デザイナーから渡された色設計が WCAG の観点で問題ないか確認したい方
- 「Fluent を使えばアクセシブルになるのでは？」という疑問を整理したい方
今回は Fluent UI 2 のカラーガイダンスと WCAG 2.1 の色関連達成基準を対比しながら、Fluent が助けてくれる範囲と、プロダクト側で判断すべき範囲を整理していきます。ここを分けて理解すると、設計レビューがかなりしやすくなります 👍
今回のゴール ✅
- ✅ Fluent UI 2 が「アクセシブルな土台」として何を提供しているか理解する
- ✅ WCAG 2.1 の色関連達成基準との対応関係を把握する
- ✅ 色だけに依存しない UI の考え方を整理する
- ✅ デザインレビューや実装引き継ぎで使えるチェックリストを持ち帰る
背景: Fluent は土台を整えてくれるが、完成までは保証しない 🧱
Fluent 2 のアクセシビリティページには、次のように書かれています。
Fluent’s components meet or surpass WCAG 2.1 AA standards to ensure an accessible foundation.
— Fluent 2 Accessibility
ここで重要なのは、accessible foundation という言い方です。つまり、Fluent UI 2 のコンポーネントは WCAG 2.1 AA を満たしやすい土台として作られている一方で、プロダクトの文脈まで自動で正しくしてくれるわけではありません。
たとえば、Fluent の入力コンポーネントや Button を使っていても、次のような設計をするとアクセシビリティ上の問題になります。
- エラーを赤色だけで示す
- 選択状態を背景色の差だけで示す
- 境界線やアイコンのコントラストが不足する
- 注意・成功・危険といった semantic color を装飾目的で使う
つまり、コンポーネントの品質と情報設計の品質は別です。ここを混同しないことが、Fluent UI 2 を正しく使う第一歩です 👀
Fluent UI 2 の色に関する基本ガイダンス 🎯
まず、今回の比較で土台になる Fluent 2 の記述を整理します。
アクセシビリティページにあるコントラスト要件
Fluent 2 のアクセシビリティページでは、色に関して次の数値が示されています。
- 標準テキストは背景に対して 4.5:1 以上
- 大きい文字は 3:1 以上
- 目安: 14pt 太字 / 18pt 通常字（約 18.5px / 24px）以上
- インタラクティブコンポーネントや非テキスト要素（例: アイコン）は、隣接色に対して 3:1 以上
これは WCAG 2.1 の数値と対応しています。このあと各達成基準ごとに見ていきます。
Color ページにある設計上の考え方
Fluent 2 の color ページでは、単なる比率の話だけでなく、運用面の指針も書かれています。
- ダークモードの shared colors は、目の負担軽減や視認性のために彩度・明度が調整される
- semantic colors は、フィードバック・状態・緊急度を伝えるために使う
- semantic colors は 重要な情報を伝えるために使う
- semantic colors を 装飾目的で使ってはいけない
- semantic colors は 一貫して使い、さらに 他の手がかりと組み合わせる
- フォーカス時はコントロール自体の色ではなく、コンテナーの太いストロークでマウス操作とキーボード操作の違いを明確にする
- ベストプラクティスとして、十分なコントラスト、可能なら色のパーソナライズ、色だけで伝えないことが挙げられている
出典: Fluent 2 Color
このあたりは、WCAG の「基準を満たす」だけでなく、認知負荷を下げる設計にもつながっています。次の章では、これを WCAG 2.1 と対比します。
WCAG 2.1 との対応を先に表で見る 🗂️
まずは全体像を一枚で見られるように、対応表を置いておきます。
| WCAG 2.1 達成基準 | Fluent UI 2 の対応する考え方 | 実装責任 |
|---|---|---|
| 🎨 1.4.1 Use of Color | semantic colors は重要な情報を伝えるために使い、他の指標と組み合わせる。色だけで伝えない | 主にプロダクト側。Fluent は土台を提供するが、情報設計は人が決める |
| 🔤 1.4.3 Contrast (Minimum) | 標準テキスト 4.5:1、大きい文字 3:1 を確保する | 共同責任。Fluent の既定トークンは助けになるが、配色変更時は確認が必要 |
| 🔲 1.4.11 Non-text Contrast | 操作や状態の識別に必要な非テキスト要素は 3:1 を確保する。フォーカスは太いストロークで視認性を確保する | 共同責任。既定状態は有利だが、カスタムの境界線 / アイコン / フォーカス表示は要確認 |
この表だけでもかなり実務的ですが、判断を誤りやすいポイントは細かく見た方が安全です。ここから 3 つの達成基準を順に見ていきます。
1.4.1 Use of Color と Fluent UI 2 🌈
WCAG 2.1 の 1.4.1 は、次の考え方です。
Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
— Understanding Success Criterion 1.4.1: Use of Color
要するに、色相だけを唯一の視覚的手がかりにしてはいけないということです。必要に応じて、テキスト・形・アイコン・3:1 以上の明度差などを併用します。
Fluent が助けてくれること
Fluent 2 は、semantic colors を「状態やフィードバックを伝えるための色」として位置づけています。また、semantic colors は装飾のためではなく、重要な情報を伝えるために使うこと、そして他の指標と組み合わせることを勧めています。
これは 1.4.1 ととても相性がよい考え方です。単に「赤は危険、緑は成功」と色名で終わらせず、ラベル・文言・アイコン・枠線・位置・パターンなどを併用する方向に自然と寄せてくれます。
それでも人が確認すべきこと
ただし、Fluent のコンポーネントを使っていても、次のような設計は NG です。
アンチパターン: エラー状態を赤だけで伝える
- 入力欄の下に説明文がない
- 枠線が赤くなるだけ
- エラーアイコンも出ない
- 何が悪いのか文言がない
これでは、色覚特性のある利用者だけでなく、低コントラスト環境や疲労時にも意味が伝わりにくくなります。
よりよいパターン
- 赤系の semantic color を使う
- ただし 「必須項目です」「メールアドレスの形式が正しくありません」 などのテキストを添える
- 可能ならエラーアイコンも併用する
- 入力欄とメッセージの関連が視覚的にも論理的にも分かるようにする
アンチパターン: 選択状態を色だけで伝える
- 選択済みのタブやカードが「少し青い」だけ
- チェックマークや下線、太字、位置変化がない
- 未選択との差が背景色だけ
よりよいパターン
- 背景色の変更に加え、太字・下線・チェックアイコン・境界線・ラベルなどを組み合わせる
- 「選択済み」「現在の項目」など、状態が明確に分かる視覚表現を足す
Fluent の semantic color は便利ですが、意味を色に埋め込むだけでは不十分です。意味は、色以外の手がかりや、必要に応じて 3:1 以上の明度差でも取り出せるようにしておくのが実務では重要です。
1.4.3 Contrast (Minimum) と Fluent UI 2 🔤
WCAG 2.1 の 1.4.3 は、テキストのコントラスト要件です。
Text and images of text have a contrast ratio of at least 4.5:1, except for large-scale text, which has a contrast ratio of at least 3:1.
— Understanding Success Criterion 1.4.3: Contrast (Minimum)
Fluent 2 側でも、次のように整理されています。
- 標準テキスト: 4.5:1 以上
- 大きい文字: 3:1 以上
- 大きい文字の目安: 14pt 太字 / 18pt 通常字（約 18.5px / 24px）以上
この点は、Fluent UI 2 のガイダンスが WCAG 2.1 をそのまま踏まえていると見てよい部分です。
Fluent が助けてくれること
Fluent の既定のトークンやテーマは、通常利用ではコントラスト要件を満たしやすい設計になっています。特に shared colors がダークモードで彩度・明度を調整する考え方は、単純に同じ色を反転流用しないという意味で、とても実践的です。
つまり、ライトモードで見た目がきれいだった色を、そのままダークモードに持ち込む危険を減らしてくれます。
それでも人が確認すべきこと
一方で、次のようなケースでは必ず再確認が必要です。
- ブランドカラーを強く反映している
- カスタムテーマを作っている
- 薄いグレーの補助テキストを多用している
- 色付き背景の上にテキストを載せている
- ダークモードだけ別配色にしている
特に業務アプリでは、「弱い情報だから薄くしたい」という判断が入りやすいのですが、弱く見せたいことと読めなくしてよいことは違います。ここは UI レビューで頻出する論点です。
実務で見落としやすい例
| 例 | 問題 | 見直しポイント |
|---|---|---|
| 🩶 プレースホルダーに近い薄い補助テキスト | 背景との差が不足しやすい | 本当に本文情報か、補助情報かを切り分ける |
| 🟦 ブランド色の上の白文字 | 一見きれいでも 4.5:1 を下回る場合がある | トークン任せにせず組み合わせで測る |
| 🌙 ダークモードの青リンク | 彩度は高くても明度差が足りないことがある | ダークテーマ側の実測を行う |
この達成基準は「Fluent を使っているから大丈夫」と言い切りにくい領域です。テキストが読めることは、最後は実際の配色で確認するしかありません。
1.4.11 Non-text Contrast と Fluent UI 2 🔲
WCAG 2.1 の 1.4.11 は、非テキスト要素のコントラストについての基準です。
The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s): components required to identify user interface components and states, and graphical objects required to understand the content.
— Understanding Success Criterion 1.4.11: Non-text Contrast
Fluent 2 のアクセシビリティページでも、interactive components と non-textual components は 3:1 と明記されています。ここで重要なのは、対象がテキストに限られないことです。
代表例 1: アイコンのコントラスト
検索、削除、展開、閉じる、といった操作アイコンが背景に溶け込んでいるケースは珍しくありません。アイコンが意味理解や操作に必要なら、隣接色に対して 3:1 を確保する必要があります。
アンチパターン
- 薄いグレーのアイコンを白背景に置く
- 無効状態と通常状態の差が分からない
- ステータスアイコンの色だけで意味を伝える
よりよいパターン
- アイコン単体でも見分けられるコントラストを確保する
- 状態差を色だけでなく形やラベルでも補う
- 「警告」「成功」などは semantic color と文言をセットにする
代表例 2: 境界線と選択状態のコントラスト
カード、ピル、トグル、選択セルなどは、境界線や背景色の差で状態を示すことが多いです。ところが、境界線が薄すぎると、状態そのものが認識できません。
アンチパターン
- 選択状態が薄い背景色だけ
- 選択中の境界線が背景との差 3:1 を満たさない
- ホバーと選択状態の差が曖昧
よりよいパターン
- 選択中は境界線、チェックマーク、太字など複数の手がかりを使う
- 状態同士の差が視覚的に明確になるようにする
- 「選ばれている」ことが一覧画面でも分かるようにする
代表例 3: フォーカスインジケーター
Fluent 2 のカラーガイダンスでは、フォーカス時にコントロール自体の色は変えず、コンテナーに太いストロークを付けると説明されています。これはとてもよい指針です。
キーボード利用者にとっては、「今どこにフォーカスがあるか」が分かることが重要です。ここが背景に埋もれると、操作可能性が大きく下がります。
独自テーマでフォーカスリングの色や太さを弱めると、Fluent が持っていた利点を自分で壊してしまうことがあります。ブランドを優先して細く薄くしすぎないよう注意が必要です。
semantic colors は「意味を持つ色」であって飾りではない 🎯
この章は 1.4.1 と重なる論点ですが、Fluent 独自の運用ルールとして切り出しておくとレビューしやすいので、あえて分けて整理します。Fluent 2 の color ガイダンスで、私が特に大事だと感じたのは次の部分です。
- semantic colors は feedback / status / urgency のために使う
- semantic colors は 常に重要な情報を伝える
- 装飾のために使わない
- 一貫して使い、さらに 他の指標と組み合わせる
これは、デザインシステムの運用でも非常に有効です。
たとえば、赤を「注意」でも「ブランドのアクセント」でも「重要ボタン」でも自由に使い始めると、利用者は色の意味を学習できません。逆に、semantic colors の用途を絞ると、見た瞬間に意味が推測しやすくなります。
よくある誤用
- 危険操作ではないのに赤いボタンを多用する
- 成功色の緑を単なる見た目のアクセントに使う
- warning と error の見た目が似すぎている
- semantic color の意味が画面ごとに変わる
守りたい考え方
- semantic color には 意味を固定する
- 色が持つ意味を、アイコン・文言・レイアウトでも補強する
- 装飾目的なら semantic color ではなく neutral / brand の考え方を使う
- 「きれいだから」ではなく「伝わるから」で選ぶ
この一貫性は、アクセシビリティだけでなく、学習コストや認知負荷の低減にも効いてきます。
Fluent UI 2 が助ける範囲 / 人が見るべき範囲 👥
ここまでの話を、実務向けにもう一段はっきり分けます。
Fluent UI 2 が助けてくれること
- WCAG 2.1 AA を意識したコンポーネントの土台を持っている
- テキスト / 非テキストのコントラスト指針が明示されている
- semantic colors の使い方に原則がある
- フォーカス表示の考え方が整理されている
- ダークモードで shared colors を調整する発想がある
デザイナー / 開発者が確認すべきこと
- 実際の画面で、意味を色だけに依存させていないか
- ブランドカラーやカスタムテーマで比率を壊していないか
- アイコン / 境界線 / 選択状態 / フォーカス表示が背景に埋もれていないか
- semantic colors を装飾に流用していないか
- 状態差が一覧画面や密度の高い UI でも分かるか
Fluent は強い味方ですが、最終的なアクセシビリティは「トークンの選択」と「状態表現の設計」次第です。ここはどうしても人の判断が必要です。
デザインレビュー / 実装引き継ぎで使えるチェックリスト ✅
ここまでの 3 つの達成基準を、実務のレビュー観点に落とすと次のチェックリストになります。デザインレビュー、実装前のハンドオフ、QA 観点の整理にそのまま使える形です。
デザインレビュー観点
- エラー、警告、成功、選択状態が色だけで表現されていない
- semantic colors の意味が画面間で一貫している
- semantic colors を装飾目的で使っていない
- ダークモードでも shared colors の見え方が破綻していない
- 状態差が一覧や密集 UI でも視認できる
コントラスト観点
- 標準テキストが背景に対して 4.5:1 以上
- 大きい文字が 3:1 以上
- 操作や状態の識別に必要なアイコン、境界線、選択表示、フォーカス表示が 3:1 以上
- ブランド色や独自テーマ適用後も再確認している
- ライト / ダークの両方で確認している
実装・ハンドオフ観点
- エラー文言や補助文言が仕様に含まれている
- selected / active / disabled / focus の状態定義が明文化されている
- 境界線とアイコンの色トークンが実装時に省略されていない
- キーボード操作時のフォーカス表示をデザインが前提にしている
- 「見た目が近いから同じ色でよい」という判断をしていない
まとめ 📝
Fluent UI 2 は、WCAG 2.1 AA を意識したアクセシブルな土台として非常に優秀です。特に色に関しては、テキスト 4.5:1、大きい文字 3:1、非テキスト 3:1 という基準が明示されており、semantic colors やフォーカス表示の考え方もよく整理されています。
ただし、それはあくまで土台です。エラーを赤だけで伝えない、選択状態を色だけにしない、操作や状態の識別に必要なアイコン / 境界線 / フォーカス表示のコントラストを守る、semantic colors を装飾に使わない、といった判断は、最終的にプロダクトチームが担う必要があります。
言い換えると、Fluent UI 2 はよい出発点ですが、判断そのものを代行してくれるわけではありません。だからこそ、WCAG 2.1 と対比しながら「どこまでがコンポーネントの責任で、どこからが設計の責任か」を押さえておくのが大切です 👍
実務では、最後のチェックリストをデザインレビューやハンドオフの共通言語として使うと、抜け漏れを減らしやすくなります。