The Universal Web

3.3 フルイドタイポグラフィとレスポンシブタイポグラフィ

フルイドな文字サイズのスケール、コンテナクエリ、そして最新のCSSテキスト制御が、読者自身の設定を上書きすることなく、あらゆる画面に対応する方法。

11 min read

このページはAIの支援を受けて翻訳されました。正文は英語の原文です。

このガイドラインの初版は、画面というものを前提にしていました。単一で、机の上にあり、サイズが予測できる画面です。その前提はもう存在しません。同じ段落が、腕を伸ばした距離で持つスマートフォンでも、タブレットでも、ノートパソコンでも、壁一面のディスプレイでも読みやすくなければなりません。そしてより重要なのは、システムフォントを拡大した人、ページを400パーセントにズームした人、あるいはその両方を行った人にとっても読みやすくなければならないということです。フルイドタイポグラフィは、この範囲全体で文字をスケールさせる技術です。アクセシブルなフルイドタイポグラフィとは、それを読者の設定を黙って覆すことなく行うことです。

フルイドスケールと clamp() 関数

現代の定石は、CSSの clamp() 関数でフォントサイズを設定することです。最小値、ビューポートとともに増加する推奨値、そして最大値を指定します。ブレークポイントで固定サイズの間を飛び移るのではなく、文字は滑らかに変化します。デスクトップで堂々とした見出しはスマートフォンでは優雅に縮小し、ブレークポイントでは決してうまく扱えなかった中途半端な幅も自動的に処理されます。

うまく使えば、これは可読性にとって本物の前進です。不注意に使えば、新しい種類のアクセシビリティの失敗を生み出します。しかもその失敗は、ざっとしたテストでは見逃されるほど微妙なものです。

アクセシビリティ上の注意点

本書のすべては、ひとつの契約の上に成り立っています。読者のサイズ設定が優先される、という契約です。ブラウザーはユーザーにデフォルトのフォントサイズの設定を許し、オペレーティングシステムはテキストのスケーリングを提供し、WCAG 1.4.4(テキストのサイズ変更)は、コンテンツや機能を失うことなくテキストを200パーセントまで拡大できることを要求しています。フルイドな計算式は、この契約を2つの方法でひそかに破ることがあります。

第一に、純粋にビューポート単位だけで構築された計算式 — たとえば vw のみから導かれたサイズ — は、ユーザーのフォントサイズ設定にまったく応答しません。ページはフルイドでモダンに見えますが、ブラウザーでより大きなデフォルトを設定した読者には何の効果もありません。対策は、計算式を rem の上に構築することです。最小値と最大値を rem で保ち、推奨値にはビューポート項と並んで rem ベースの成分を持たせます。そうすればスケール全体が、あるべき姿のとおり、ユーザーの設定の上に乗ります。

第二に、clamp 自体がズームと衝突することがあります。読者がズームすると、CSS上ではビューポート単位が縮小するため、vw に偏った計算式はズームを部分的に打ち消してしまいます。読者がページを拡大しても、テキストはズーム倍率より小さくしか拡大されず、極端な場合には WCAG 1.4.4 が要求する200パーセントに到達できません。フルイドスケールは必ず高倍率のズームでテストされなければなりません — 大丈夫だと決めつけてはいけません。

リフローと400パーセントズーム

WCAG 1.4.10(リフロー)は、幅320 CSSピクセル — 1280ピクセルのウィンドウを400パーセントにズームしたのと同等 — で、読むために水平スクロールを必要とせずにコンテンツが機能することを要求しています。多くのロービジョンの読者は、この倍率の世界で暮らしています。フルイドな文字サイズは、誠実に作られていればここで役立ちます。その実効幅ではスケールは最小値に収まり、行長は短くなり、何もビューポートからはみ出さないはずです。固定幅のコンテナ、テキストの絶対配置、折りたたまれることを拒む多段組みレイアウトが、いつもの違反者です。すべての読書ページを400パーセントでテストしてください。1分で済みますし、こうした失敗はまさにそこに隠れています。

200パーセントズームでは、remベースのフルイドサイズはWCAG 1.4.4の要求どおり32ピクセルに倍増するが、vwのみの計算式は22ピクセルにしか達せず不合格となる。

コンテナクエリ

メディアクエリはウィンドウの大きさを尋ねますが、コンテナクエリはコンポーネント自身のボックスの大きさを尋ねます。タイポグラフィが実際に答えを必要としているのは、たいてい後者の問いです。カードはサイドバーにあってもページ全体に広がっていてもカードであり、その文字はいまや自身の幅に応答できます。コンポーネント内のフルイドなサイズ指定には、コンテナクエリ単位を使います。先ほどの注意点はそのまま引き継がれます。コンテナ相対の単位は読者のフォントサイズ設定について何も知らないため、これも rem ベースの項と組み合わせ、ズーム下でテストしなければなりません。

小さな道具、確かな成果

最近のいくつかのCSSプロパティは、古くからのタイポグラフィの問題に直接取り組んでいます。

  • text-wrap: balance は、短いブロック — なにより見出し — の行長を均等にし、長い1行目の下に2語だけが取り残される孤立行をなくします。数行のためのものであり、本文用ではありません。
  • text-wrap: pretty は、段落の行分割にブラウザーがより多くの労力を費やすことを許し、最終行に単語がひとつだけ残るのを避け、ラグ(行末の凹凸)を改善します。エンジン間のサポートはまだ不揃いなので、プログレッシブエンハンスメントとして扱ってください。
  • font-size-adjust は、フォールバックフォントのエックスハイトを、それが代役を務めるウェブフォントに一致させます。ウェブフォントの読み込み中 — あるいは永遠に届かない場合 — フォールバックは同等の見かけのサイズでレンダリングされ、レイアウトシフトが減り、フォールバックのテキストは本来の書体と同じくらい判読しやすく保たれます。フォントが読み込まれるまでの数秒間にどれだけの読書が行われるかを考えれば、この控えめなプロパティは十分にその場所に値します。

この章が新しく設けられた理由

2005年にはフルイドタイポグラフィは存在しませんでした。フルイドであるべき対象がなかったからです。モバイルウェブはほとんど存在せず、レスポンシブデザインが言語化されるのは2010年のことで、clamp()、コンテナクエリ、text-wrap の制御、広くサポートされた font-size-adjust は、いずれもここ数年の発展です。リフロー要件そのものも、2018年のバージョン2.1でようやくWCAGに加わりました。画面の多様化が問題を生み、CSSはつい最近になって道具を提供し、その道具をめぐるアクセシビリティの規律はさらに若いのです。

CSSでは

h1 {
  /* fluid between bounds; the rem term preserves zoom and settings */
  font-size: clamp(2.25rem, 1.4rem + 3.5vw, 4.5rem);
  text-wrap: balance;
}
p { font-size: 1rem; text-wrap: pretty; }

/* Test at 200% and 400% zoom — WCAG 1.4.4 and 1.4.10 */

推奨事項

  • フルイドスケールは rem の上に構築すること。最小値、最大値、そして推奨値の中の rem 成分によって、ユーザーのフォントサイズ設定が伝播します。
  • テキストのサイズをビューポート単位だけで指定しないこと。
  • すべてのテンプレートを、200パーセントズーム、400パーセントズーム、そしてブラウザーのデフォルトフォントサイズを上げた状態でテストすること — 3つの異なるテストであり、すべて必須です。
  • WCAG 1.4.10 を検証すること。幅320 CSSピクセルで、読むのに水平スクロールが不要であること。
  • コンポーネントレベルの文字サイズの判断にはコンテナクエリを使い、同じ rem の規律を守ること。
  • 見出しには text-wrap: balance を適用し、本文には text-wrap: pretty をプログレッシブエンハンスメントとして有効にすること。
  • font-size-adjust(およびサイズを揃えたフォールバック)を定義し、ウェブフォントの読み込み前でも、それなしでも、テキストが判読できるようにすること。

参考文献