レスポンシブ×アクセシビリティの基本をおさらい：コンテナクエリ・フルードタイポ・WCAG 2.2

2026年8月10日

AIサイトビルダーやコーディングエージェントが一瞬でページを組み上げてくれる時代でも、そのアウトプットが「本当に使えるか」を判断する物差しは変わらない。今回は、2026年時点で押さえておきたいレスポンシブデザインとアクセシビリティの基礎を、コンテナクエリ・フルードタイポグラフィ・WCAG 2.2・モーション設計の4本柱でおさらいする。

ブレークポイントとモバイルファースト、まずは基本の確認

レスポンシブデザインの土台は今も変わらず「ビューポート幅に応じてレイアウトを切り替える」ことにある。一般的なブレークポイントの目安は、480px前後（スマートフォン）、768px前後（タブレット）、1024px前後（小型デスクトップ以上）の3段階。ここに、狭い画面から先に設計して段階的に拡張していく「モバイルファースト」の考え方を組み合わせるのが定石で、AIサイトビルダーが生成するテンプレートも大半がこの発想をベースにしている。

まず<meta name="viewport" content="width=device-width, initial-scale=1">が入っているかを確認する
固定pxではなく相対単位（%、rem、vw/vh）でレイアウトを組む
画像にはmax-width: 100%を当てて親要素からはみ出さないようにする

ここまではAI生成コードでもほぼ自動的に満たされるようになったが、次に紹介する「コンポーネント単位の適応」まで意識しているツールはまだ少ない。

ビューポートからコンテナへ——Container Queriesで部品ごとに最適化する

従来のメディアクエリは画面全体の幅にしか反応できないため、同じカードコンポーネントでも「3カラムグリッドの中」と「サイドバーの中」で見た目を変えることができなかった。Container Queriesは、親要素にcontainer-type: inline-sizeを指定するだけで、その要素の実際の幅を基準にスタイルを切り替えられる仕組みで、Chrome 105+・Firefox 110+・Safari 16+と主要ブラウザで実装が揃っている。

.card-wrapper { container-type: inline-size; }

@container (min-width: 400px) {
  .card { grid-template-columns: 120px 1fr; }
}

同じ画面幅であっても、広いメインカラムに置かれたカードと、狭いサイドバーに置かれたカードがそれぞれ独立して最適なレイアウトを取れるようになる。Subgridと組み合わせれば、コンポーネント内部の柔軟性を保ちながら兄弟要素とのグリッド整列も崩れない。デザインシステムを前提にコンポーネント単位でAI生成・再利用する今のワークフローとは特に相性がいい考え方だ。

フルードタイポグラフィ——`clamp()`でブレークポイントの「カクつき」をなくす

見出しや本文の文字サイズを画面幅ごとに固定値で切り替えると、ブレークポイントの境目で急に文字サイズがジャンプして見える。CSSのclamp(最小値, 可変値, 最大値)を使えば、最小サイズから最大サイズまでを滑らかに連続的にスケールさせられる。

h1 {
  font-size: clamp(1.75rem, 4vw + 1rem, 3.5rem);
}

数値を毎回手計算するのは大変なので、Clamp Calculatorのようなツールで最小・最大のフォントサイズとビューポート幅を入力し、生成されたclamp()式をそのまま使うのが現実的だ。可変フォント（Variable Fonts）と組み合わせれば、太さや幅まで含めて画面サイズに応じた最適な可読性を確保できる。

手法	得意なこと	弱点
固定ブレークポイント（メディアクエリ）	デザインの意図通りに厳密な切り替えができる	境目でジャンプが目立つ、パターンが増えると管理が煩雑
コンテナクエリ	同じコンポーネントを異なる文脈で再利用できる	親要素にcontainer-typeの設定が必要
フルードタイポ（clamp）	文字サイズが画面幅に連続的に追従する	意図しない画面幅で読みにくくなる可能性、下限・上限の検証が必要

レスポンシブWebデザインのレイアウトを示す写真 — Photo: luc legay / CC BY-SA 2.0, Openverse経由・原典はこちら

モーションの原則——「動かせる」から「動かして良いか」へ

スクロール演出やマイクロインタラクションはAIツールで簡単に量産できるようになったが、動きが多すぎるページは前庭障害（乗り物酔いに似た症状）を持つユーザーにとって深刻な問題になりうる。CSSのprefers-reduced-motionメディアクエリで、OS側の「動きを減らす」設定を尊重するのが最低限のマナーだ。

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

GitHubのデザインシステムPrimerも、「動きは本当に必要な場合にのみ使い、ユーザーがコントロールできる手段を用意する」ことを明確なガイドラインとして掲げている。演出を追加する前に、それが情報伝達に必須なのか、単なる装飾なのかを一度切り分ける習慣をつけたい。

アクセシビリティの新常識——WCAG 2.2で追加された基準

WCAG 2.2はWCAG 2.1に9つの達成基準を追加した版で、特に低視力・運動機能に制約のあるユーザーの操作性を補強する内容が多い。AIが生成したUIをそのまま公開する前に、最低限次の3点は確認しておきたい。

達成基準	レベル	要点
2.5.8 Target Size (Minimum)	AA	タップ・クリック対象は24×24 CSSピクセル以上、または周囲に十分な余白を確保する
2.4.11 Focus Not Obscured (Minimum)	AA	キーボードフォーカスが固定ヘッダーなどに隠れないようにする
2.5.7 Dragging Movements	AA	ドラッグ操作には、クリックやタップだけで完結する代替手段を用意する

いずれも「後から足す」のではなく、コンポーネントを設計する最初の段階で満たしておいた方が手戻りが少ない。生成AIにUIコードを書かせる際も、プロンプトの中に「タップ領域は24px以上」「フォーカスリングを隠さない」といった条件を明記しておくと、後工程での修正が減る。

配色とダークモードも「原則」から

ダークモード対応も、今や特別な機能ではなく前提のひとつになっている。prefers-color-schemeでユーザー環境の設定を検知し、color-schemeでブラウザ標準UI（スクロールバーやフォームコントロール）の配色も合わせ、light-dark()関数で2テーマ分の色指定を1行にまとめる、という3点セットが2026年時点でのベースラインになりつつある。コントラスト比の基準（通常テキストで4.5:1以上）は明暗どちらのテーマでも独立して満たす必要がある点も忘れずに確認したい。