調査ノート / アクセシビリティ

文字はどこまで大きくすべきか — WCAG・iOS・Android・Flutterから考える文字拡大対応

文字拡大について調べると、WCAG、Apple、Android、Flutterは少しずつ違うことを言っています。対象も目的も違うため、どれか一つを正解として採用するのではなく、各所の要請を組み合わせた場合の着地点を整理します。

公開・最終確認：2026年7月22日・読了目安：12分

「文字を200%にすればよい」では整理しきれない

WCAGとAndroidには、どちらも200%という数字が登場します。ただし、WCAGが扱うのはWebコンテンツを利用者が拡大できること、Android 14が扱うのはOSのフォントサイズ設定です。同じ数字でも、前者はWebページが満たす達成基準、後者はプラットフォームが提供する最大設定で、出発点が異なります。

Webではブラウザのページズーム、文字サイズ変更、表示領域の縮小が組み合わさります。ネイティブアプリではOSが選択された文字サイズをアプリへ伝え、コンポーネントがその設定に応じます。表示全体を拡大する機能と、文字の描画サイズだけを変える機能も同じではありません。

iOSのDynamic Typeは段階的な文字サイズを提供し、FlutterはiOSとAndroidから渡される異なる変換方法を同じTextScaler APIで受け取ります。数字だけを横に並べる前に、誰が何を拡大する仕組みなのかを分けて考える必要があります。

この記事では、規格、OS、フレームワークの記述を同列のルールにはしません。それぞれが守ろうとしているものを確認し、最後に実装順序として重ね合わせます。したがって、ここで示す折衷案は認証や適合性を判定するためのものではなく、設計時の会話を始めるための整理です。

各所はどう定めているか

WCAG 2.2

達成基準1.4.4は、キャプションと文字画像を除く文字について、支援技術を使わずに200%までサイズを変更しても、情報や機能が失われないことを求めます。ここで中心にあるのは「200%という見た目を作ること」ではなく、利用者が変更でき、その後も内容を読み、操作を完了できることです。

達成基準1.4.10のリフローは、縦スクロールのコンテンツを320 CSS px相当の幅で表示したとき、原則として二方向のスクロールを必要とせず、情報や機能を保つことを扱います。地図やデータ表など、二次元配置が意味や利用に必要な部分は例外として明記されています。文字だけを大きくして横へはみ出させるより、折り返しや一列化で読み進められる状態が焦点です。

G179は、文字コンテナの幅を変えない条件で文字サイズを200%に増やし、すべての内容と機能を利用できるかを確認する手法です。説明では、折り返し、ブロックの高さ拡張、必要な場合のスクロールバーを、内容を利用可能に保つ方法として挙げています。達成基準とTechniqueは役割が異なるため、手法の一つを唯一の実装方法とみなさず、実際のページで結果を確認します。

公式資料：WCAG 2.2、Technique G179

JIS・デジタル庁

JIS X 8341-3:2016は、日本のWebコンテンツにおけるアクセシビリティの規格です。デジタル庁のWebアクセシビリティ導入ガイドブックは、JIS X 8341-3:2016を「WCAG 2.0と一致規格」と説明しています（デジタル庁 Webアクセシビリティ導入ガイドブック）。この記事ではJISの適合判定方法へ踏み込まず、日本のWeb実務でWCAG由来の達成基準を参照する位置づけとして扱います。WCAG 2.2の新しい達成基準まで自動的に同じ範囲になる、という意味ではありません。

デジタル庁デザインシステムは、ロービジョンの利用者が画面全体またはフォントサイズを200%以上に拡大する場合を挙げています。そのうえで、文字サイズが変わっても読みやすさと提供機能を保ち、レスポンシブデザインを画面幅の違いだけでなく、単一デバイス上の拡縮にも役立てる考え方を示しています（デジタル庁デザインシステム「タイポグラフィ（アクセシビリティ）」）。

これは「モバイル用の見た目があれば十分」という説明ではありません。同じ端末でも、拡大によって一行に入る文字数や横並びにできる要素数が変わります。ブレークポイント、折り返し、コンテナの可変高を、画面幅と文字の占有幅の両方に耐えるよう設計する必要があります。

Apple

Appleは、システムのテキストスタイルを使ってDynamic Typeへ対応し、利用者が自分に合う文字サイズを選べるようにすることを重視しています。標準サイズの先にはアクセシビリティ向けの大きな段階があり、単一のパーセント値をアプリ側で指定する考え方とは異なります。

Human Interface Guidelinesは、すべての文字サイズにレイアウトを適応させ、最大アクセシビリティサイズでも最大標準サイズと同程度の有用な情報を示すことを目標にしています。ラベルを一行へ固定して早い段階で省略するのではなく、必要な行数を許可して有用な量を表示することも勧めています。

実装へ置き換えると、大きい文字でナビゲーションと本文が競合したとき、すべてを同じ比率のまま維持するとは限りません。主要な内容と操作を先に残し、横並びを縦積みに変え、詳細画面など同じ情報へ到達できる経路を用意する方が、情報階層を保ちやすくなります。Dynamic Typeはフォント指定だけで終わらず、レイアウトの適応まで含む設計課題です。

公式資料：Apple Human Interface Guidelines: Typography

Android

Android 14以降は最大200%の非線形フォントスケーリングを採用しています。小さい文字を大きくする一方、すでに大きい見出しは同じ割合で巨大化させず、文字サイズ間の階層を保ちながら、文字切れや過度に大きい表示を軽減します。

ここでの非線形とは、設定値が一つの掛け算としてすべてのフォントサイズへ適用されないということです。同じOS設定でも、本文と大見出しでは実際の拡大率が異なり得ます。そのため、従来のfontScaleやscaledDensityから独自の式を作ると、プラットフォームの変換と結果がずれる可能性があります。

Android公式は文字サイズへspを使い、最大設定を有効にしてUIを検証するよう案内しています。一方で、paddingやビューの高さへspを流用しないことも明記しています。文字と非文字の寸法を同じ値で動かすと、非線形になったときに合計寸法の前提が崩れるためです。

公式資料：Android 14: Non-linear font scaling to 200%

Flutter

FlutterのTextScalerは、単一の倍率ではなく文字サイズの変換戦略を表します。textScaleFactorが表せた線形の掛け算だけではAndroid 14の非線形変換を保持できないため、Flutterはフォントサイズを受け取って結果を返すAPIへ移行しました。互換用のtextScaleFactor値は推定値であり、新しい寸法計算の基準にはできません。

FlutterはiOSとAndroidの違いを消す独自基準ではなく、各OS由来の設定をウィジェットへ伝える翻訳層として捉えると分かりやすくなります。通常のTextへ設定が届く状態を保ち、小さい画面と大きな文字設定で、読めることだけでなく操作できることまで確認します。

フォント以外の寸法を文字倍率で計算していた箇所には、一律に置き換えられる式がありません。実フォントサイズをTextScalerへ渡すか、ウィジェット自身の内容から寸法を決める設計へ戻ります。固定高が必要だと思っていたコンポーネントも、可変高やスクロールへ変えることで制限を置かずに済む場合があります。

公式資料：Flutter: UI design & styling、TextScalerへの移行

並べると、少しずつ論点が違う

規格、プラットフォーム、フレームワークは異なる層の資料です。互いを置き換えるものではないため、対象、倍率、守ろうとしているもの、レイアウトへの期待を分けて比較します。

WCAGはWebコンテンツの結果を検査できる達成基準を置きます。AppleとAndroidは利用者設定とプラットフォームUIの振る舞いを示し、Flutterはその差をアプリへ運ぶAPIを提供します。JISとデジタル庁の資料は、日本のWeb実務でそれらをどう位置づけ、設計へ落とすかを理解する手がかりです。

したがって、数字の大小だけで厳しさを比較するのは適切ではありません。iOSのアクセシビリティサイズを一つの倍率へ換算したり、WCAGの数値をネイティブアプリの共通最大値へ読み替えたりせず、それぞれの仕組みで利用者が選べる範囲を起点にします。

WCAG 2.2: 対象：Webコンテンツ; 拡大：文字は200%、リフローは320 CSS px相当; 主眼：情報や機能を失わず、利用者による拡大を妨げない; レイアウト：折り返しとリフローを重視

JIS・デジタル庁: 対象：日本のWeb実務; 拡大：JIS X 8341-3:2016はWCAG 2.0と整合; 主眼：200%以上の拡大を想定し、読みやすさと機能を保つ; レイアウト：レスポンシブ設計を拡縮にも活用

Apple: 対象：iOSなどAppleプラットフォーム; 拡大：Dynamic Typeの段階的なサイズ; 主眼：利用者が選んだサイズを尊重し、有用な情報を保つ; レイアウト：大きいサイズでも読める適応型レイアウト

Android 14以降: 対象：AndroidネイティブUI; 拡大：最大200%の非線形スケーリング; 主眼：小さい文字を大きくしつつ、大見出しの過拡大を抑える; レイアウト：spを使い、最大設定で実際に検証

Flutter: 対象：iOS・Androidなど複数プラットフォーム; 拡大：OS由来の戦略をTextScalerで受け取る; 主眼：単一倍率を前提にせず、実フォントサイズをscaleする; レイアウト：固定寸法計算より内容駆動の再設計を優先

資料	対象	拡大	主眼	レイアウト
WCAG 2.2	Webコンテンツ	文字は200%、リフローは320 CSS px相当	情報や機能を失わず、利用者による拡大を妨げない	折り返しとリフローを重視
JIS・デジタル庁	日本のWeb実務	JIS X 8341-3:2016はWCAG 2.0と整合	200%以上の拡大を想定し、読みやすさと機能を保つ	レスポンシブ設計を拡縮にも活用
Apple	iOSなどAppleプラットフォーム	Dynamic Typeの段階的なサイズ	利用者が選んだサイズを尊重し、有用な情報を保つ	大きいサイズでも読める適応型レイアウト
Android 14以降	AndroidネイティブUI	最大200%の非線形スケーリング	小さい文字を大きくしつつ、大見出しの過拡大を抑える	spを使い、最大設定で実際に検証
Flutter	iOS・Androidなど複数プラットフォーム	OS由来の戦略をTextScalerで受け取る	単一倍率を前提にせず、実フォントサイズをscaleする	固定寸法計算より内容駆動の再設計を優先

全部入りの折衷案

各所の考え方を組み合わせるなら、次の順で考える進め方が扱いやすそうです。これは各資料を実装判断へ並べ直したもので、新しい適合基準ではありません。

順番が重要です。最初から倍率を制限すると、レイアウトを変えれば残せた情報まで小さくしてしまいます。まず利用者設定を受け取り、次に配置を変え、その後に情報の優先順位を確認します。局所調整は、そこまで試しても表示契約を守れない箇所のために残し、最後に各対象の大きな文字設定で確認します。

1
OSまたはユーザーエージェントの文字サイズ設定を基本的に尊重する
2
固定高を増やす前に、改行、可変高、縦積み、列数変更、スクロールで吸収する
3
主要な情報と操作を残し、補足情報や装飾との優先順位を付ける
4
アイコン、余白、コンテナ寸法を文字と同じ倍率で機械的に拡大しない
5
それでも成立しない限定的なコンポーネントだけ、表示契約に基づいて個別調整する
6
アプリ全体へ一律の倍率上限を設定することは避ける
7
各対象プラットフォーム・端末の大きな文字または最大文字設定で確認する

たとえば、横並びのカードで見出しが収まらない場合、最初の選択肢は見出しだけを小さくすることではありません。カードを一列へ切り替える、説明を次の行へ送る、高さを内容に合わせる、一覧から詳細へ到達できるようにする、といった変更を先に試します。

主要操作の短いラベルなど、サイズと文言の契約が明確な部品では局所的な調整を検討できます。ただし、調整後も読めること、操作できること、同じ情報へ到達できることを確認します。「崩れない見た目」だけで完了にしないことが、この折衷案の共通部分です。

Flutterではどう実装へ落とすか

Flutterでは、まず通常のTextがOS設定を受け取る状態を保ちます。独自倍率を作るのではなく、寸法計算が必要な場合も実際のフォントサイズをTextScaler.scaleへ渡します。

非線形スケーリングでは「現在の倍率」を一つ取り出し、フォント、余白、高さへ掛ける設計が成り立ちません。次のように、描画に使うfontSizeを変換戦略へ入力すると、そのサイズに対する結果を取得できます。

final textScaler = MediaQuery.textScalerOf(context);
final scaledFontSize = textScaler.scale(textStyle.fontSize!);

この値が必要なのは、カスタム描画やフォントサイズに応じた計算が本当に必要な場面です。通常のTextへ毎回指定するためのコードではありません。また、scaledFontSizeをそのままコンテナの高さやpaddingとして流用するのではなく、文字が占める実寸や内容からレイアウトを決めます。

固定高を倍率で増やす前に、改行、可変高、縦積みなどで内容自身が必要な大きさを決められないかを検討します。`Row`が窮屈なら`Wrap`や縦方向の配置へ変え、画面全体が長くなる場合はスクロールで到達可能にします。大きな文字で一画面に収めることより、情報と操作を失わないことを優先します。

OS由来の設定を入口にする

通常のTextがMediaQuery経由で受け取る文字サイズ設定を保ち、アプリ独自の倍率へ置き換えない。

フォントサイズをTextScalerへ渡す

非線形スケーリングでは単一係数の掛け算に戻さず、実際に使うfontSizeをscaleメソッドへ渡す。

内容から寸法を決める

文字倍率から固定高を逆算するより、改行や可変高を許し、内容が必要とする寸法をレイアウトへ反映する。

制限は局所的な例外にする

レイアウトで吸収しても成立しない短い操作ラベルなどに対象を限定し、代替経路と最大設定での確認をセットにする。

`MediaQuery.withClampedTextScaling`は、現在のTextScalerが返す範囲を指定した最小・最大係数の間へ制限するAPIです。利用者設定を消すのではなく、子サブツリーのスケーリング範囲を変えます。

MediaQuery.withClampedTextScaling(
  maxScaleFactor: 2,
  child: const Text('短い操作ラベル'),
)

まず改行・可変高・縦積みを検討し、それでも成立しない限定的なUIだけで使います。アプリのルートには置きません。短い操作ラベルでも、制限後の文字が利用者にとって十分か、ボタンの役割が別の方法でも分かるか、実際の最大設定で確認します。

つまり、TextScalerやclampはレイアウト検討を省略する道具ではありません。プラットフォームの変換を正しく受け取り、必要な箇所だけ明示的な契約を置くためのAPIです。公式の移行資料も、非文字寸法には一般的な移行則がなく、UIの再設計が必要になり得ると説明しています。

公式資料：TextScalerへの移行、MediaQuery.withClampedTextScaling API

確認チェックリスト

実装を読んだだけでは、文字の幅、翻訳後の長さ、OSごとの変換、実行中の設定変更までは分かりません。少なくとも次の条件を組み合わせ、主要な閲覧と操作の流れを確認します。

見るのは文字切れの有無だけではありません。ボタンが押せるか、スクロールして情報へ到達できるか、フォーカスや読み上げ順がレイアウト変更後も自然か、省略した情報に別の経路があるかを確認します。小さい画面と最大文字サイズが重なる条件は、問題を見つけやすい出発点です。

iOSとAndroidの大きな文字サイズ
Webの200%拡大
小さい画面
長い文言と多言語化
太字など文字幅へ影響する設定
実行中に文字サイズを変更した場合
文字切れ、重なり、操作不能、到達不能な情報
主要情報を省略する場合の代替経路

Webの200%拡大と、iOS・Androidの大きな文字設定は別々に確認します。片方が通ったことを、もう片方の代替にはしません。ブラウザズームではレイアウト幅も変わり、OSの文字設定ではプラットフォーム固有のスケーリングが適用されるため、現れる崩れ方が違います。

すべての画面を最初から網羅できない場合は、共通ナビゲーション、一覧、詳細、フォーム、ダイアログなど、表示契約が異なる代表コンポーネントから始めます。問題が見つかったときは単発の文字サイズ調整で閉じず、同じ固定高や横並びを使う箇所へ確認範囲を広げると再発を減らせます。

まとめと参考資料

文字拡大の資料は、同じ問題を別の言葉で繰り返しているわけではありません。WCAGはWebコンテンツが保つべき結果を示し、AppleとAndroidはOS設定とレイアウトの考え方を示し、Flutterは異なる変換を受け取るAPIを提供しています。対象を分けると、一つの倍率へ揃えるより、各層の役割を尊重する方が自然です。

各所の考え方を全部取り込むなら、利用者設定を尊重し、最初にレイアウトで吸収し、情報と操作を保ったうえで、必要な箇所だけ個別に調整する流れが扱いやすそうです。これは新しい適合基準ではなく、異なる資料を一つの実装判断へ並べ直した折衷案です。

実際の対象製品では、適用される規格、プラットフォーム、利用者の状況に合わせて検証範囲を決める必要があります。ここでの順序をたたき台にしつつ、利用者が選んだ文字サイズで主要な情報と操作を保てるかを、画面ごとに確かめるのが無理の少ない着地点です。

WCAG 2.2 （2026年7月22日確認）
WCAG Technique G179 （2026年7月22日確認）
デジタル庁 Webアクセシビリティ導入ガイドブック（2026年7月22日確認）
デジタル庁デザインシステムタイポグラフィ（2026年7月22日確認）
Apple Human Interface Guidelines: Typography （2026年7月22日確認）
Android 14: Non-linear font scaling to 200% （2026年7月22日確認）
Flutter: UI design & styling （2026年7月22日確認）
Flutter: Accessibility standards and regulations （2026年7月22日確認）
Flutter: Deprecate textScaleFactor in favor of TextScaler （2026年7月22日確認）
Flutter API: withClampedTextScaling （2026年7月22日確認）

仕様、ガイドライン、APIは更新される可能性があります。実装や評価に使う際は、リンク先の最新版を確認してください。