「文字を大きくしたら、ボタンの文字が枠からはみ出して読めなくなった」——コーポレートサイトをリニューアルした企業の担当者から、公開後にこういう報告を受けることがあります。デザイン段階では誰も気づきません。なぜなら、作る側は標準の文字サイズで画面を見ているからです。ところが利用者の側には、ブラウザの設定で文字を大きくしている人、画面全体を200%に拡大して読んでいる人が一定数います。とくに高齢の経営者や取引先、弱視の方にとって、拡大は「特別な操作」ではなく、毎日の閲覧そのものです。
この拡大耐性は、いまや配慮の問題にとどまりません。2024年4月に施行された改正障害者差別解消法により、民間事業者にも障害のある人への合理的配慮の提供が義務化されました。自社サイトが拡大すると崩れて読めない状態は、「配慮を尽くしていない」状態に直結します。Smashing Magazine の Testing Font Scaling For Accessibility With Figma Variables も、文字の拡大への耐性をデザイン段階から検証する重要性を指摘しています。受託でサイトを預かる立場としては、これは「公開後に偶然見つかる不具合」ではなく、最初から品質として作り込むべき項目だと考えています。
「拡大すると崩れる」の正体は px 固定にある
崩れるサイトには、共通の原因があります。文字サイズや余白、ボタンの高さをピクセル（px）で固定していることです。
px は「絶対的な点の数」を指定する単位です。font-size: 16px と書けば、利用者がブラウザの文字サイズ設定をどう変えても、そのテキストは16pxのまま動きません。利用者が「文字を大きく」を選んでも反応しない。これでは設定を用意した意味がありません。一方、ボタンの高さも height: 40px のように固定していると、何かの拍子に中の文字だけが大きくなったとき、文字が枠を突き破ってはみ出します。固定された箱に、伸びるテキストを詰め込んでいる構造そのものが原因です。
ここを相対単位に置き換えるだけで、挙動は大きく変わります。
/* 崩れやすい書き方：px で固定 */
.button {
font-size: 16px;
height: 40px;
padding: 0 24px;
}
/* 拡大に耐える書き方：rem と相対的な余白 */
.button {
font-size: 1rem; /* ルートの文字サイズに連動 */
min-height: 2.75rem; /* 固定 height ではなく最低値 */
padding: 0.625rem 1.5rem;
}rem はルート要素（html）の文字サイズを基準にする単位で、利用者がブラウザ側で文字を大きくすると、それに連動して全体が大きくなります。ボタンの高さも height で固定するのではなく min-height で「最低これだけ」と決めておけば、文字が増えたぶん箱が下に伸びるので、はみ出しません。このあたりの土台は、Webアクセシビリティ ガイド（GH Media） で扱っている考え方の延長線上にあります。
守るべき三つの達成基準
拡大耐性を語るとき、目安になるのが WCAG（Webコンテンツアクセシビリティガイドライン）の達成基準です。とくに関係が深いのは次の三つで、それぞれ「何が起きてはいけないか」を具体的に定めています。
| 達成基準 | 要点 | 失敗例 |
|---|---|---|
| 1.4.4 テキストのサイズ変更 | 文字を200%まで拡大しても、内容と機能が失われない | 拡大するとボタンの文字が切れて押せなくなる |
| 1.4.10 リフロー | 画面幅320px相当まで縮めても、横スクロールなしで読める | 拡大すると横スクロールが出て、文章が画面外へ消える |
| 1.4.12 テキストの間隔 | 行間・文字間・段落間隔を広げてもテキストが重ならない | 行間を広げたらカードの中で文字が重なって読めない |
実務でとくに見落とされがちなのが、二つめのリフローです。利用者が画面を200%に拡大すると、表示できる横幅は実質的に半分になります。レイアウトが固定幅前提で組まれていると、このとき横スクロールが発生し、利用者は一行読むたびに左右へスクロールを強いられます。これは「読める」とは言えません。横方向のはみ出しを許さず、内容が縦に流れ直す（リフローする）ように組むことが、ここでの肝です。
三つめのテキスト間隔は、行間や文字間を利用者側で広げるユーザースタイルへの耐性を問うものです。固定の高さに文字を押し込んでいると、間隔を広げた瞬間に文字どうしが重なります。原因は px 固定と同じ「箱が伸びない」構造で、解決の方向も同じです。
メディアクエリだけに頼らず、流体で考える
レスポンシブというと、@media で「画面幅が768px以下になったら」と区切り、その境目でレイアウトを切り替える発想が一般的です。これ自体は有効ですが、文字サイズの拡大にはうまく対応しません。利用者が文字を大きくしても、ウィンドウの幅そのものは変わらないため、メディアクエリの境界をまたがず、レイアウトは切り替わらないからです。
そこで効くのが、流体的なタイポグラフィの考え方です。clamp() を使って文字サイズに最小値・推奨値・最大値を持たせると、画面や基準サイズの変化に応じて文字がなめらかに伸縮します。
.heading {
/* 最小1.25rem、画面幅に応じて変化、最大2rem */
font-size: clamp(1.25rem, 1rem + 2vw, 2rem);
}断面で「768px以下なら一律に切り替える」のではなく、連続的に変化させることで、拡大や中間的な画面幅でも破綻しにくくなります。境目でガクッと崩れる現象も減ります。あわせて、余白やコンテナ幅も % や rem、コンテナクエリで相対的に持たせておくと、文字が大きくなったときにレイアウト全体が無理なく追従します。表示速度との兼ね合いも生じるため、Core Web Vitals（GH Media） の観点と並行して見ておくと安全です。
デザイン段階で「拡大した状態」を検証する
崩れを公開後に見つけるのは、最悪のタイミングです。修正にはコードの手戻りが発生し、すでに利用者を取りこぼした後でもあります。だからこそ、デザイン段階で拡大した状態を検証することに価値があります。
冒頭で挙げた Smashing Magazine の記事は、Figma の変数（Variables）を使ってこの検証をデザイン工程に組み込む方法を紹介しています。基準となる文字サイズを変数として定義し、その値を125%・150%・200%と切り替えたモードを用意しておけば、デザイナーが「文字を大きくしたら、このボタンは枠からはみ出すか」をデザインデータの上で即座に確認できます。実装してブラウザで触る前に、崩れの芽を摘めるわけです。
受託の現場では、ここをレビューの正式な工程として組み込んでいます。具体例として、ある士業事務所のサイト制作では、申込ボタンと料金表のカードを「文字200%」のモードで全画面ぶん点検しました。結果、料金表の数字が拡大時にセルからあふれる箇所と、固定高さのCTAボタンで文言が二行になると下が切れる箇所が、実装前に二つ見つかりました。どちらも min-height 化と余白の相対化で解消し、公開後の手戻りはゼロでした。フォームや導線まわりで似た配慮が要る点は、認知特性に配慮したインクルーシブUX設計の受託（GH Media） とも地続きです。
よくある崩れと、その直し方
最後に、実際に拡大時へ起きやすい崩れを、原因と対処の形で整理しておきます。いずれも根は共通していて、「箱を固定して中身を入れている」ことに行き着きます。
- ボタンの文字がはみ出す／切れる：
height固定をやめ、min-heightと相対余白に。文字が二行になっても箱が下へ伸びるようにする。 - 拡大で横スクロールが出る：固定幅 px を
max-widthと%／remに置き換え、画像や表にmax-width: 100%を効かせる。 - ナビゲーションが画面外へ消える：横並び固定をやめ、狭い幅では縦積みやメニュー収納へリフローさせる。
- 行間を広げると文字が重なる：
line-heightを数値（単位なし）で指定し、コンテナの高さを固定しない。
こうした項目は、一度チェックリスト化して制作工程に組み込めば、案件ごとに品質を再現できます。タイムアウトや配色など、ほかのアクセシビリティ観点も同様に工程化できます。たとえば自動ログアウトの扱いは セッションタイムアウトのアクセシビリティ（GH Media）、配色のコントラストは CSS contrast-color によるアクセシブル配色（GH Media） で扱っています。
受託だからこそ、拡大耐性を品質として担保する
文字の拡大やズームへの対応は、特別な機能を足す話ではありません。px 固定をやめて相対単位で組み、固定の高さに中身を押し込まない。そして拡大した状態を、デザイン段階と実装後の両方で必ず確認する。この当たり前を工程として持っているかどうかが、公開後に崩れるサイトと、誰が拡大しても読めるサイトを分けます。
「自社サイトが拡大したときに崩れないか不安」「リニューアルにあわせてアクセシビリティの品質も担保したい」という場合は、既存サイトの拡大耐性チェックから個別にお引き受けできます。まずは現状の点検からでも構いません。お問い合わせよりお気軽にご相談ください。
Sources
- Smashing Magazine「Testing Font Scaling For Accessibility With Figma Variables」 https://www.smashingmagazine.com/2026/03/testing-font-scaling-accessibility-figma-variables/
- Webアクセシビリティ ガイド（GH Media）
- 認知特性に配慮したインクルーシブUX設計の受託（GH Media）
- セッションタイムアウトのアクセシビリティ（GH Media）
- CSS contrast-color によるアクセシブル配色（GH Media）
- Core Web Vitals（GH Media）
