WEBサイト公開前に確認したいカラー項目|配色・文字・状態色の最終チェック

TIPS

WEBサイトの配色を決め終えていても、公開直前にスマートフォンの申込み画面を確認すると、文字が薄い、選択中の項目が分からないといった問題が見つかることがあります。大切なのは、色見本をもう一度眺めることではなく、実際のページと操作状態で色の役割を点検することです。架空の地域イベント予約サイトを例に、公開前の最終チェックを進める手順を紹介します。

公開前に確認するページと表示状態を洗い出す

まず、利用者が見るページと、そのページで起こる状態を組み合わせて確認対象を決めます。UI(ユーザーインターフェース)とは、ボタンや入力欄など、画面で情報を見たり操作したりする部分のことです。イベント予約サイトなら、次の順に画面を開きます。

  • トップ・イベント一覧:ヘッダー、カード、開催日、申込みへの案内を確認します。カードの背景が変わる箇所では、見出しや補足文字が埋もれていないかを見ます。
  • イベント詳細:写真の上の文字、残席表示、申込みボタンを確認します。写真の明るい部分と暗い部分の両方で、重ねた文字が読めるか確かめます。
  • 申込みフォーム:入力前、入力中、必須項目の未入力、送信中を順に試します。Tabキーで移動したときのフォーカス表示(現在操作している場所を示す輪郭)も対象です。
  • 結果画面:実際に受付できた場合の完了表示と、通信失敗や受付終了の案内を別々に確認します。送信ボタンを押しただけで「受付完了」と表示していないかも確かめます。

確認表には「ページ/要素/状態/文字・図形の色/背景・隣接色/判定/修正内容」を1行ずつ記録します。パソコンでは通常時に加えてホバー(マウスを重ねた状態)とキーボード操作を、スマートフォンではメニューを開いた状態やタップ後の表示を確かめましょう。スマートフォンにホバー操作があることを前提にはしません。

文字・ボタン・状態色を実際の組み合わせで測る

色の数値を記録する際は、HEX(色を16進数で表すカラーコード)を文字や部品の色だけでなく、隣り合う背景とセットで残します。以下は確認手順を説明するための配色例で、サイト全体にそのまま使う必要はありません。

  • 本文と補足文字:ページ背景を■#F7F8F5、本文文字を■#24333Dにした場合、コントラスト比は約12.19:1です。小さい注記や入力欄内の案内も、実際に表示される背景で測ります。例えば白■#FFFFFFの入力欄と案内文字■#66717Aは約4.99:1です。
  • 申込みボタン:ボタン背景■#23556Fと白文字■#FFFFFFは約8.08:1、ボタン背景と周囲のページ背景■#F7F8F5は約7.58:1です。文字の読みやすさと、ボタンそのものを見つけられるかは分けて点検します。
  • 入力欄とフォーカス:白■#FFFFFFの入力欄の境界線を■#707A82にすると、線と白の差は約4.38:1、線とページ背景■#F7F8F5の差は約4.11:1です。操作中の輪郭を■#1A4A6Dにする例では、白に対して約9.36:1、ページ背景に対して約8.78:1です。輪郭が他の要素に隠れていないか、実際にTabキーで確認します。
  • エラーと受付完了:未入力エラーを淡い赤■#FBEAECの面と濃い赤■#8A2432の文字で示すと約7.60:1です。「開催日を選択してください」など修正内容も書きます。受付が実際に成功した場合は、淡い緑■#E6F3E9と濃い緑■#205D3Dで約6.81:1です。「受付完了」と次の案内を文章で示し、色だけで結果を伝えないようにします。

WCAG 2.2(WEBコンテンツのアクセシビリティ指針)のレベルAAでは、通常サイズの文字は原則4.5:1以上、規定の大きな文字は3:1以上です。操作の識別や状態表示に必要な非テキストの視覚情報は、隣接色と原則3:1以上が基準です。一方、操作できない部品や純粋な装飾などには例外があり、すべての線に一律3:1が必要なわけではありません。色の違いだけで選択中・エラー・成功を知らせず、文字や形も添えます。

HueRollで確認できるコントラストは、選択した色と白・黒の組み合わせです。任意の2色の比較やAA・AAAの自動判定はできないため、ここで示した背景色と文字色などの比率は別途計算しています。実装で半透明色や写真を重ねる場合は、実際に見える組み合わせを改めて検証してください。

修正後に再確認し、公開できる状態か判断する

  1. 問題を具体的に記録する:「フォームの未入力エラーが色だけで示される」「スマートフォンの開いたメニューで文字が背景に溶け込む」のように、ページ・状態・問題を一緒に残します。読めない文字、見つけにくい操作、結果が色だけで示される箇所は公開前の修正対象です。
  2. 修正した箇所と共通部品を再テストする:ボタンの共通スタイルを直したなら、トップ、詳細、フォームのすべてを確認します。通常時だけでなく、ホバー、フォーカス、選択中、エラー、無効状態も必要に応じて試し、パソコンとスマートフォンの両方で再確認します。
  3. 判定と確認条件を残す:確認表に修正後の色の組み合わせ、コントラスト比、確認端末、結果を記録します。残った問題があれば未確認・要修正と区別し、公開の判断を曖昧にしないようにします。ダークモードがあるサイトでは別の表示条件として点検します。

公開前のカラー確認は、新しい配色を作る作業ではなく、利用者が文字を読めて、操作を見つけられ、結果を理解できるかを確かめる作業です。画面と状態を指定して検証すれば、修正後の確認漏れも防ぎやすくなります。