Webデザインの基礎点検｜症状から直す領域を逆引きする

Webデザインの基礎は、読んで覚えた時点ではまだ使えるようになっていません。作り終えた画面に当てはめて「守れているかどうか」を1つずつ確かめたときに、はじめて手元の仕事に効く知識になります。ところが完成後の点検は、見る順番と合否の基準が決まっていないと、「なんとなく素人っぽい」「もう少し垢抜けさせたい」といった印象の言い合いで終わってしまいます。

Webデザインの基礎点検とは、完成した画面に出ている症状から疑うべき領域を逆引きし、その領域ごとに決まった合否ライン（数値）で合格・不合格を出す作業です。領域は「読める」「触れる・たどれる」「崩れない」「速い」の4つに整理でき、合否ラインの大半はW3CのWCAG 2.2とCore Web Vitalsという公開された基準から取れます。基準が外にあるので、判定が人によってぶれません。

この記事はその地図です。役割をはっきりさせておくと、何を・どの順で測るかだけを決め、どう測るか（開発者ツールの操作やコンソールで走らせるコード）は書きません。測り方は領域ごとの記事が持っているので、測る段になったらそちらへ渡します。合否ラインの根拠にはW3C勧告のWCAG 2.2（2024年12月12日勧告）、web.dev、Google検索セントラルを使い、いずれも2026年8月2日に原文を確認しています。

基礎が守れているかは、作ったあとに測って決まる

Webデザインの制作は、大きく「参考を集めて当たりを付ける」「数値を決める」「作る」「点検する」の順に進みます。このうち点検だけが、ほかの工程と決定的に違う性質を持っています。ほかの工程は自分の判断で正解を作りますが、点検は外にある基準に自分の画面を当てて、合否が向こうから返ってくる工程だからです。だから点検は最後に置くしかなく、そして最後に置くからこそ、前の工程で決めた数値がそのまま守られているかを確認できます。

前工程にあたる「数値を決める」側は別記事が担当しています。ウィンドウ幅・コンテンツ幅・カラム設計といった土台の数字は、デザインカンプ前に決めるWebデザインのルールで先に固めてください。この記事はその数字を決める側ではなく、決まった数字が守られているかを測る側です。逆に言えば、基準値を決めないまま点検に入ると「何と比べて不合格なのか」が言えなくなります。

点検にはもう1つ、数値では出せない側面があります。「情報の優先順位が、装飾ではなく構造に載っているか」です。こちらは色を剥ぐ・ぼかす・強弱を剥ぐという主観テストで確かめる領域で、UIデザインの構造・視覚・文字を剥ぎ取りテストで検品するが担当しています。同じ「完成後の点検」でも、あちらは順位が読み取れるかという主観判定、この記事は数値の合否ラインという分担です。両方を通してはじめて点検が一巡します。

なお、構図・配色・作業効率化までを含めたデザイン全体の入口は デザインガイド にまとめてあります。この記事はその下にある「基礎の点検」だけを担当する枝です。

症状から、疑う領域を引く

点検を「全部を上から見る」で始めると、たいてい途中で力尽きます。実務で先に手元にあるのは、レビューで言われた一言や自分が感じた違和感、つまり症状です。症状は領域と対応しているので、そこから逆に引けば、見る場所を最初から絞れます。

領域が決まったら、次は2つに分かれます。合否を出すだけなら、この記事の次章以降の合否ラインで足ります。不合格だった領域を作り直す、あるいは値の取り方そのものを知りたい場合は、領域ごとの記事へ進んでください。この記事から先の深掘り先は次のとおりです。

• 文字組み（行間・字送り・見出しと本文の比）を数値で決め直す — タイポグラフィの基本とデザイン活用術
• 配色そのものを組み直す・パレットを作る — 色彩設計の基本｜配色理論とカラーパレット実装例
• 余白が足りているか、詰まりの原因はどこかを見る — Webデザインにおけるホワイトスペースの重要性と活用方法
• 並びが崩れているときにグリッドを組み直す — グリッドレイアウトの基本と組み方
• 画面幅ごとの切り替えを作り直す — レスポンシブデザイン入門｜スマホ対応の基本原則
• タップ領域・コントラスト・320px幅を実際に測る手順を知る — UIの合否を数値で出す｜タップ領域・コントラスト・320px幅の実測手順
• 到達できるか・今どこにいるかが分かるかを測る — ナビゲーションの作り方と最適化
• WCAG 2.2の全体像と、自動チェックで拾えない範囲を押さえる — Webアクセシビリティの基本｜WCAG 2.2と法改正への対応
• 指標そのものの定義と目標値、下げ方を知る — Core Web Vitalsの改善ガイド
• 転送圧縮・キャッシュ・HTTP/2・画像フォーマットの配信設定が現行水準かを1回のリクエストで判定する — サイト高速化の配信設定点検

「読める」の合否ライン

最初に見るのは「読めるか」です。読めない画面は、ほかの領域が全部合格でも使えません。ここでの合否ラインは、W3CのWeb Content Accessibility Guidelines (WCAG) 2.2（W3C勧告、2024年12月12日／2026年8月2日に原文確認）のレベルAAから取ります。

1.4.3の原文は「The visual presentation of text and images of text has a contrast ratio of at least 4.5:1」で、例外は大きな文字・付随的なテキスト・ロゴタイプの3つです。大きな文字の定義は「18ポイント以上、または14ポイントの太字、あるいは日本語・中国語・韓国語のフォントで同等の大きさになるサイズ」と明記されています。ポイント指定で書かれている点に注意してください。CSSのpxとポイントは同じ単位ではないため、境界に近いサイズでは「大きな文字扱いにできるか」を確かめてから3:1を当てる必要があります。迷ったら4.5:1で判定するほうが安全です。

1.4.12は誤解されやすい基準です。「行間を1.5倍にしなさい」という要求ではありません。原文は「No loss of content or functionality occurs by setting line height to 1.5 times the font size…」で、読者側がその値を上書きしたときに壊れないことを求めています。つまり判定対象はデザインの好みではなく、高さを固定した箱に文字を詰めていないかです。落ちる場合はほぼ確実に、固定高さのボタンやカードが原因になります。

コントラストで落ちたときの直し方は2通りあります。その色だけを濃くする対症療法か、配色の設計に戻るかです。淡色の注釈や薄いグレーのプレースホルダーが複数箇所で落ちているなら、個別に濃くしても再発します。パレットの段階から組み直す話は 色彩設計の基本 に、行間や見出しと本文の比を数値で決め直す話は タイポグラフィの基本とデザイン活用術 にあります。

本文の最小フォントサイズは合否ラインに入れない

「本文は16px以上」という決まりを見かけますが、WCAG 2.2に本文の最小フォントサイズを定めた達成基準はありません。2026年8月2日にWCAG 2.2の原文を確認した範囲でも、文字サイズに関する要求は1.4.4 Resize Text（200%まで拡大できること）であり、絶対値の下限ではありませんでした。16pxという数字自体は実務上の妥当な習慣ですが、根拠はアクセシビリティ標準ではなく別のところにあります。ここでは公的な基準に紐づく項目だけを合否ラインとして扱い、実務上の推奨値は前工程（カンプ前に決める数値）の側に置きます。この線を引いておかないと、「基準違反」と「好みの相違」が混ざり、レビューで話が通らなくなります。

「触れる・たどれる」の合否ライン

読めることを確認したら、次は操作と移動です。ここは見た目のスクリーンショットでは合否が出ない領域で、実際に指で押す、キーボードで送る、別のページから戻ってくるといった動きを伴います。合否ラインは同じくWCAG 2.2のレベルAAです。

2.5.8には5つの例外が明記されています。間隔（24 CSSピクセル径の円を各ターゲットの中心に置いても他のターゲットと重ならない）、等価（同じ機能を果たす別のコントロールが基準を満たしている）、インライン（文中にあり、行の高さに制約される）、ユーザーエージェント制御（作者が変更していない）、必須（その表示が本質的、または法的に要求される）の5つです。小さなアイコンボタンを並べた行が落ちたとき、サイズを上げる以外に「間隔を空ける」「同機能のテキストリンクを近くに置く」という選択肢がある、と読める点が実務では効きます。

2.4.11は見落としやすい基準です。フォーカス枠を用意していても、画面上部に固定したヘッダーの裏にフォーカス中の要素が潜り込むと落ちます。キーボードでタブを送りながらページの上端・下端を往復するだけで見つかるので、点検の順番に必ず入れてください。到達手段（2.4.5）と繰り返しナビの順序（3.2.3）は1ページだけでは判定できず、サイト単位で見る必要があります。

ここで落ちた領域を作り直すなら、到達性と現在地の設計は ナビゲーションの作り方と最適化 が担当しています。そして「実際にどうやって24×24やコントラスト比を取るのか」という測り方は、この記事では扱いません。その手順は UIの合否を数値で出す（タップ領域・コントラスト・320px幅の実測手順） にまとめてあるので、合否を出す段になったらそちらへ移ってください。

「崩れない・速い」の合否ライン

3つ目は、環境を変えたときに壊れないかどうかです。ここも基準は外にあります。幅と拡大はWCAG 2.2、表示性能はCore Web Vitalsです。

1.4.10には「320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom.」という注記が付いています。320という数字は特定の端末の実寸ではなく、拡大の限界を幅に換算した値だということです。だから「うちの想定端末はもっと広いので関係ない」とは言えません。二次元スクロールが必要になる部分（大きなデータ表や地図など、レイアウトそのものに意味がある要素）は例外として認められているので、表が横に伸びること自体を不合格にする必要はありません。

数値の出典は web.dev「Web Vitals」（2026年8月2日確認）です。判定の作法まで含めて押さえておくべき点が2つあります。1つは75パーセンタイルで見ること。原文は「a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices」で、平均でも自分の端末の1回でもありません。もう1つはモバイルとデスクトップを分けて見ることです。1回の計測で「速い」と判断するのは、この基準の使い方から外れています。

指標名にも注意が必要です。応答性の指標は2024年3月12日にFID（First Input Delay）からINPへ置き換わっています。web.dev「Interaction to Next Paint (INP) becomes a Core Web Vital」（2024年3月12日／2026年8月2日確認）は「Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).」と明記しています。古い解説記事にはFIDのまま残っているものがあるので、点検シートに写すときは指標名を確認してください。

検索順位との関係は、言い方を正確にしておく必要があります。Google検索セントラルの「Understanding page experience in Google Search results」（最終更新2025年12月10日／2026年8月2日に英語版を確認）は、「There is no single signal.（単一のシグナルは存在しない）」と述べたうえで、「Core Web Vitals are used by our ranking systems.（Core Web Vitalsはランキングシステムで使われている）」としています。「速くすればSEOに効く」という粗い因果ではなく、「Core Web Vitalsはランキングシステムが見ている複数のシグナルの1つである」までが公式の記述です。点検の目的は順位ではなく、待たされる・飛ぶ・反応しないという体験上の不具合をなくすことに置いてください。

ここで落ちたときの進み先は2つに分かれます。指標そのものの定義と下げ方を追うなら Core Web Vitalsの改善ガイド、転送圧縮・キャッシュ・HTTPのバージョン・画像フォーマットといった配信側の設定が現行水準かを1回のリクエストで判定するなら サイト高速化の配信設定点検 です。幅320 CSSピクセル相当での確認手順そのものは UIの合否を数値で出す にあります。

15分で1ページを通す点検の回し方

合否ラインが揃ったら、あとは順番です。順番には理由があります。前の領域の修正が後の領域を壊すことはあっても、その逆は起きにくいからです。たとえばコントラストを上げるために背景を濃くすると、その上に載っているボタンの輪郭が3:1を割ることがあります。読める→たどれる→崩れない→速い、の順に進めると、この巻き添えを後段で拾えます。

1. 点検する幅と倍率を先に固定する（例: 幅1280・ズーム100%を基準、幅320相当と200%拡大を別条件として用意）
2. 読める — 本文・見出し・注釈・プレースホルダーのコントラスト比を確認し、外から行間と字間を当てても崩れないかを見る
3. たどれる — キーボードだけで上端から下端までタブを送り、フォーカスが見えるか、固定要素に隠れないかを見る
4. 触れる — 主要な操作対象のサイズと間隔、UI部品の輪郭のコントラストを確認する
5. 崩れない — 幅320 CSSピクセル相当と200%拡大の2条件で、2方向スクロールと機能欠落が出ないかを見る
6. 速い — LCP・INP・CLSの3つを、モバイルとデスクトップを分けて確認する
7. 落ちた領域だけを記録し、その場では直さない

最後の1行が肝心です。見つけたその場で直し始めると、点検が中断して残りの領域が見られなくなります。1ページを通すのに15分と決めておくと、直す作業と測る作業が混ざりません。1周目は「どこが落ちているか」の地図を作るだけに徹してください。

記録は3列でとる

記録が長くなると次の周で使えません。列は3つに固定します。次の周で同じ形に書き直し、並べて見比べられるようにするためです。

判定は「合格／不合格／未測定」の3つだけにします。「たぶん大丈夫」を書けるようにすると、次の周で比較できなくなるからです。実測できていない項目は空欄にせず「未測定」と書いてください。空欄は合格と読み違えられます。

「読める」が不合格で、原因が個別の色ではなく詰まりや並びの乱れにあるときは、余白と並びの側から直したほうが早いことがあります。余白の判断は ホワイトスペースの重要性と活用方法、並びの組み直しは グリッドレイアウトの基本と組み方 にあります。手を動かす段では CSS Gridジェネレーター と Flexboxジェネレーター で当たりを取ると、値を1つずつ書き換えるより早く候補を比べられます。

検証｜直したあと、同じ順でもう一度回す

点検が効いたかどうかは、直した本人の感触では分かりません。確かめ方は1つです。直す前に作った点検シートと同じ順序・同じ条件で、もう一度だけ全領域を回します。1周目と2周目のシートを並べ、次の2つが同時に成り立てば合格です。

• 2周目で「不合格」の領域が0になっている
• 直していない領域の判定が、1周目から1つも変わっていない

1つ目だけでは足りません。2つ目が「修正が別の領域を壊していないこと」を担保しています。コントラストのために色を濃くしたらUI部品の輪郭が3:1を割った、という巻き添えは、直した領域だけを見返しても見つかりません。外れたときは、外れ方によって次の一手が変わります。

検証は2周で止めます。「測り方そのものが妥当だったのか」を検証する3周目は、この記事では扱いません。そこから先は各領域の実測手順が持っている話であり、地図の役割を超えます。自動チェックツールの限界を含めた全体像は Webアクセシビリティの基本 にまとまっているので、判定そのものに疑いが残った場合はそちらを起点にしてください。

やりがちな失敗と、その直し方

点検が形だけになるパターンは限られています。多くは「基準を外に置く」という前提が崩れたときに起きます。

もう1つ、点検の結論として起こりうるのが「部分的な修正では届かない」という判定です。落ちた領域が3つ以上あり、しかも原因がばらけているなら、直すより作り直したほうが早い場合があります。そのときは着手前の工程に戻ることになるので、参考サイトの集め方と共通構造の抜き出し方を扱った Webデザインの参考サイトの探し方と使い方 から入り直してください。点検の役割は「直す」ことではなく、「直すのか作り直すのかを、数値で決められるようにする」ことです。

よくある質問（FAQ）

Q. Webデザインの基礎は、どこから点検すればいいですか？

読めるか（コントラストと文字組み）から始めます。読めない画面は、ほかの領域が合格でも使えないためです。読める→たどれる→崩れない→速いの順に進めると、前の領域の修正が後の領域を壊していても、同じ1周のうちに気づけます。

Q. 文字と背景のコントラストは、どのくらいあれば合格ですか？

WCAG 2.2の達成基準1.4.3（レベルAA）では、テキストと背景のコントラスト比は4.5:1以上、大きな文字は3:1以上と定められています。ここでいう大きな文字とは18ポイント以上、または太字で14ポイント以上（日本語・中国語・韓国語のフォントでは同等の大きさになるサイズ）のことです。

Q. ボタンやリンクの大きさに基準はありますか？

WCAG 2.2で新設された達成基準2.5.8（レベルAA）が、ポインタ操作の対象を24×24 CSSピクセル以上と定めています。ただし十分な間隔が空いている場合、同じ機能を果たす別のコントロールがある場合、文中のインラインリンクである場合など、5つの例外が認められています。

Q. スマートフォンで崩れていないかは、どの幅で確認すればいいですか？

幅320 CSSピクセル相当で確認します。WCAG 2.2の達成基準1.4.10（Reflow）は、この幅で縦横2方向のスクロールを要求しないことを求めており、320 CSSピクセルは1280 CSSピクセル幅の表示領域を400%に拡大した状態と等価だと注記されています。

Q. 表示速度はデザインの合否に入りますか？

入ります。Core Web Vitalsの目安はLCPが2.5秒以内、INPが200ミリ秒以内、CLSが0.1以下で、75パーセンタイルで判定します。検索順位との関係についてGoogleは「単一のシグナルは存在しない」としたうえで、Core Web Vitalsをランキングシステムで使っていると公表しています。

Q. 自動チェックツールの結果だけで合否を決めてよいですか？

決められません。自動チェックが判定できるのは機械的に読み取れる項目に限られ、フォーカスの見え方やナビゲーションの一貫性のように、実際に操作しないと分からない項目が残ります。自動チェックで落ちた分を直したうえで、キーボード操作の確認を必ず併用してください。

Q. 点検のためにデザインツールは必要ですか？

点検そのものはブラウザだけで完結します。作り直しが必要になった場合、Figmaには無料のStarterプランがあり、限定機能ながらドラフトを無制限に作れます（Figma料金ページ／2026年8月2日確認）。コーディング側はVS Codeで足ります。