WCAG 1.4.4: テキストの再サイズ

WCAG 1.4.4 は、支援技術を使用せずに、かつコンテンツや機能を損なうことなく、テキストを最大 200% まで拡大できることを求めています。この基準は、ブラウザのズーム機能やカスタムのフォントサイズ設定に頼って快適にウェブコンテンツを読む、ロービジョンのユーザーにとって不可欠です。

このルールの意味

WCAG 1.4.4 Resize Text（レベルAA）は、支援技術を使用せずに、かつコンテンツや機能を失うことなく、テキストを最大200パーセントまで拡大できなければならないと定めています。平たく言えば、ユーザーがブラウザのズームを200%にしたり、ブラウザやOSの設定で基本のフォントサイズを大きくしたとき、ページ上のすべてのテキストが読みやすい状態を保ち、すべての機能がそのまま利用可能でなければならないということです。

この達成基準は、ウェブページ上でレンダリングされるすべてのテキストに広く適用されます。本文、見出し、ラベル、ボタンのテキスト、フォームフィールド内のプレースホルダーテキスト、ナビゲーションリンク、表の内容、キャプションなどが含まれます。ロゴやブランド名の一部であるテキストや、情報を伝えず純粋に画像コンテンツとして提示される装飾的なテキスト（テキスト自体がアクセシブルなコンテンツではない手書きメモのスキャン写真など）は対象外です。

合格とみなされるには、ブラウザの組み込みページズーム（Ctrl/Cmd + プラスキー、または「表示」>「ズーム」メニュー）やブラウザの最小フォントサイズ設定によって200%ズームにした際、次の条件がすべて満たされている必要があります。テキストがコンテナによって切り取られたり隠れたりしないこと、テキスト同士やインタラクティブ要素と重なり合わないこと、ビューポート幅いっぱいの状態で水平スクロールバーが表示されないこと（地図やデータテーブルなど、本当に2次元スクロールが必要なコンテンツを除く）、そしてすべてのインタラクティブなコントロールが引き続き操作可能であることです。

不合格となるのは、固定ピクセル値によってテキストサイズが固定され拡大できない場合、固定高さのコンテナがあふれたテキストを切り取ってしまう場合、ビューポートのmetaタグでuser-scalable=noやmaximum-scale=1.0を使用してモバイルでのピンチズームをブロックしている場合、あるいはJavaScriptがズームジェスチャーを傍受して拡大を妨げている場合です。この達成基準は明示的に技術非依存です。実装にCSS、SVGテキスト、canvas上のテキストのいずれを用いていても、ユーザーにとっての結果こそが重要です。なお、SVGテキストやcanvas上のテキストは本質的にリサイズが難しく、追加のエンジニアリング対応が必要になることが多い点に注意してください。

なぜ重要か

世界保健機関によると、世界で約2.2億人が何らかの視覚障害を抱えています。その中でも非常に多くの人がロービジョン（低視力）に該当します。これは、眼鏡やコンタクトレンズで完全には矯正できないものの、全盲ではない状態です。ロービジョンのユーザーは、ブラウザのズームを日常的に150%、200%あるいはそれ以上に設定したり、OSの設定でテキストをより大きな基本サイズで表示するようにしています。ウェブサイトがこの行動を妨げたり、ズームによってレイアウトが崩れてしまうと、これらのユーザーはコンテンツから完全に排除されてしまいます。

診断されたロービジョンに限らず、状況要因は事実上すべてのインターネットユーザーにいつか影響します。小さな画面、強い日差し、疲労、加齢による視力低下、慣れない言語での読書などは、いずれも小さな文字を読み取りにくくします。特に高齢者は、世界的にもトルコでも急速に増えている人口層であり、専門的な支援技術を利用する前の第一のアクセシビリティ手段として、ズーム機能に頼ることが多くあります。

具体的なシナリオを考えてみましょう。60代の患者が、病院ポータルのスマートフォン版からオンライン予約確認を読もうとしています。病院のモバイル用スタイルシートでは、本文のフォントサイズが固定ピクセル値の12pxに設定されており、ビューポートのmetaタグにはmaximum-scale=1.0が含まれています。患者がピンチズームを試みても、インターフェースは拡大を受け付けません。日付や診療科名をはっきり読めず、自信が持てない状態です。患者は病院のヘルプデスクに電話し、スタッフの時間を消費するとともに、患者に不安を与えます。これは、この達成基準が守られていれば完全に防げた事態です。

純粋に商業的な観点から見ても、アクセシブルなテキストサイズ対応は、すべてのユーザーに利益をもたらす使いやすさの向上と相関しています。検索エンジンも、通常サイズと拡大サイズの両方で読みやすいテキストを表示するサイトを高く評価します。Googlebotは、Core Web Vitalsやページエクスペリエンスのランキング要因の一部として可読性のシグナルを評価しているためです。リサイズの問題を解消することは、SEOの改善、サポート負荷の軽減、潜在的なオーディエンスの拡大を同時に実現します。

テスト方法

まず自動スキャンを実行する。 ChromeまたはFirefoxでページを開き、axe DevTools（ブラウザ拡張）またはLighthouse（Chrome DevToolsのLighthouseタブ）を実行します。特にmeta-viewportルールの違反がないか確認してください。フラグが立っている場合は重大な不具合として記録します。また、axeのベストプラクティス警告に表示されるpx単位のfont-size宣言がCSS監査にないか確認します。
ソース内のビューポートmetaタグを確認する。 DevTools（F12）を開き、「Elements」タブでmeta name='viewport'を検索します。content属性を注意深く読みます。user-scalable=no、user-scalable=0、またはmaximum-scale=1（あるいは2未満の値）が含まれている場合、これは1.4.4の直接的な不合格です。
ブラウザのズームを200%に設定する。 ChromeまたはFirefoxで、Ctrl + プラス（Windows/Linux）またはCmd + プラス（macOS）を繰り返し押し、ブラウザのズーム表示が200%になるまで上げます。あるいは、「表示」>「拡大」を使用します。macOSのSafariでは「表示」>「拡大」を使用します。このテストではOSレベルの表示スケーリングは使用せず、必ずブラウザのズームを使ってください。
200%ズームでページのすべてのセクションをスクロールする。 ページの上から下まで体系的にスクロールします。コンテナによってテキストが切り取られたり隠れたりしていないか、テキストがボックスからはみ出して隣接コンテンツと重なっていないか、フォームラベルが入力欄の後ろに隠れていないか、ボタンのテキストが途中で切れていないか、ドロップダウンメニューが画面外にはみ出してスクロールしても見えない部分がないか、モーダルダイアログがビューポートを超えてスクロールできない状態になっていないかを確認します。
200%ズームで全インタラクティブ機能をテストする。 すべてのナビゲーションメニューを開閉し、すべてのモーダルを開き、フォームを送信し、ツールチップやポップオーバーを表示し、カルーセルやアコーディオンなどがあれば操作します。これらが「見えている」だけでなく、完全に操作可能な状態を保っていることを確認します。
NVDA + Firefox（Windows）でテストする。 NVDAを有効にし、Firefoxを200%ズームで開きます。Tabキーと矢印キーでナビゲートします。フォーカス可能な要素にフォーカスが移動すること、フォーカスインジケーターが見えること（WCAG 2.4.7とも関連しますが、ここでも有用です）、拡大された状態でも読み上げ順が視覚的な順序と一致していることを確認します。
VoiceOver + Safari（macOS/iOS）でテストする。 VoiceOverを有効にします。iOSでは、「設定」>「アクセシビリティ」>「画面表示とテキストサイズ」に移動し、「さらに大きな文字」を有効にします。同じページをナビゲートし、コンテンツの整合性を確認します。また、ピンチズームジェスチャーを使い、ズームがブロックされていないことも確認します。
ブラウザの最小フォントサイズ設定をテストする。 Firefoxで「設定」>「一般」>「フォントと配色」に移動し、最小フォントサイズを24pxに設定します。ページを再読み込みし、すべてのテキストがこの最小サイズを満たしていること、レイアウトが崩れていないことを確認します。これは同じ達成基準に対する別の観点からのテストです。
JAWS + Chrome（Windows）でテストする。 Chromeでページを開き、ズームを200%に設定してJAWSを有効にします。JAWSの読み上げコマンド（Insert + 下矢印でカーソル位置から読み上げ）を使用し、すべてのテキストコンテンツが読み上げられ、オーバーフローによるクリッピングで隠れているコンテンツが読み飛ばされていないことを確認します。

修正方法

ビューポートmetaタグによるズームのブロック — 誤り

<!-- WRONG: user-scalable=no prevents pinch-to-zoom on mobile,
     directly violating WCAG 1.4.4 -->
<meta name='viewport' content='width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no'>

ビューポートmetaタグによるズームのブロック — 正しい例

<!-- CORRECT: Remove user-scalable=no and do not cap maximum-scale below 2.
     Allowing zoom to at least 2 (200%) satisfies WCAG 1.4.4. -->
<meta name='viewport' content='width=device-width, initial-scale=1.0'>

ピクセル固定のフォントサイズ — 誤り

<!-- WRONG: font-size in px ignores the user's browser font-size preference.
     If the user sets a larger default, px values override that preference. -->
<style>
  body {
    font-size: 14px;
  }
  h1 {
    font-size: 24px;
  }
  .caption {
    font-size: 11px;
  }
</style>
<p>Your appointment is confirmed.</p>

ピクセル固定のフォントサイズ — 正しい例

<!-- CORRECT: Use rem units relative to the root font size (typically 16px browser default).
     1rem = 16px by default, but scales with user preference.
     Setting font-size on :root in % rather than px also respects user settings. -->
<style>
  :root {
    font-size: 100%; /* inherits browser default, typically 16px */
  }
  body {
    font-size: 0.875rem; /* ~14px at default, but scales with user preference */
  }
  h1 {
    font-size: 1.5rem; /* ~24px at default */
  }
  .caption {
    font-size: 0.75rem; /* ~12px at default — still scalable */
  }
</style>
<p>Your appointment is confirmed.</p>

テキストを切り取る固定高さコンテナ — 誤り

<!-- WRONG: A fixed height with overflow:hidden will clip enlarged text.
     At 200% zoom, the text grows but the box does not, hiding content. -->
<style>
  .card {
    height: 120px;
    overflow: hidden;
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

テキストを切り取る固定高さコンテナ — 正しい例

<!-- CORRECT: Use min-height instead of height so the container grows
     with the content when text is enlarged. -->
<style>
  .card {
    min-height: 7.5rem; /* sets a minimum but allows growth */
    overflow: visible; /* or remove overflow:hidden entirely */
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

画像に焼き込まれたテキスト — 誤り

<!-- WRONG: A banner image containing text cannot be resized by the browser.
     Even with alt text, the visual text is inaccessible at high zoom levels. -->
<img src='promo-banner-with-text.jpg' alt='50% indirim — sadece bu hafta sonu'>

画像に焼き込まれたテキスト — 正しい例

<!-- CORRECT: Use real HTML text over a background image so the browser
     can resize it. The image is decorative background; text is live HTML. -->
<div class='promo-banner' role='region' aria-label='Promosyon'>
  <p class='promo-text'>50% İndirim &mdash; Sadece Bu Hafta Sonu</p>
</div>
<!-- CSS sets the background image on .promo-banner, while .promo-text
     uses rem font-size and contrasts safely against the background. -->

よくある間違い

モバイルでの「レイアウト崩れ」を防ぐ目的でビューポートmetaタグにuser-scalable=noを追加すること — これは1.4.4の直接的かつテスト可能な違反であり、決して使用してはなりません。ユーザーのズーム機能を抑制するのではなく、レイアウトを修正してください。
maximum-scale=1.0または2.0未満の値を設定すること — user-scalable=noがなくても、ズームを1.0や1.5に制限するとユーザーは200%に到達できず、この達成基準に不合格となります。
JavaScriptのイベントリスナーでピンチズームやホイールイベントに対してevent.preventDefault()を呼び出すこと — ネイティブのズームをプログラム的にブロックすることは、ビューポートmetaタグによるアプローチと機能的に同等であり、同じ達成基準に違反します。
<html>や<body>要素にピクセル単位でfont-sizeを設定し、その上で他のすべてをem単位で指定すること — ルートのフォントサイズがpxで固定されている場合、その子孫のem/remも実質的に固定され、ユーザーのブラウザのフォントサイズ設定に反応しなくなります。
カードコンポーネント、サイドバー、モーダル本体にmin-heightではなくheightを使用すること — 200%ズーム時には、拡大されたテキストが固定高さのボックスからはみ出し、overflow: hiddenによって切り取られ、重要なコンテンツが隠れてしまいます。
重要なテキストを<canvas>要素内にのみ配置すること — canvas上のテキストはラスタ化されたビットマップであり、ブラウザのテキストリサイズやズーム機構によって拡大することはできません。ユーザーが読む必要のある意味のあるテキストは、実際のHTMLテキストとして、少なくともアクセシブルな代替テキストとして提供されなければなりません。
絶対座標とviewBoxスケーリングなしのSVG <text>要素を使用すること — SVGがviewBoxを使用し、相対単位でサイズ指定されている場合、SVGテキストはスケーラブルです。しかし、固定のwidthとheightを持つSVG内で、x、y、font-size属性をピクセル単位で固定したSVGテキストは、すべてのブラウザでブラウザズームに追従してリサイズされるとは限りません。
ブラウザのズームが自動的にこの達成基準を満たしてくれると想定し、手動テストを省略すること — ブラウザズームは画像やレイアウトを含むページ全体を拡大しますが、100%の時点ですでに小さすぎたり、切り取られたり、重なり合っていたテキストは、200%ではさらに深刻な問題になります。ズームレベルでの手動検証は常に必要です。
サードパーティの埋め込みウィジェットのテストを忘れること — チャットウィジェット、決済用iframe、クッキー同意バナー、アナリティクスのオーバーレイなどは、サードパーティによって固定pxサイズで開発されていることが多く、ズームをブロックする場合があります。コードがサードパーティ製であっても、ユーザーに提供されるページ全体にこの達成基準は適用されます。
デスクトップレイアウトのズーム対応だけを修正し、モバイルのブレークポイントを放置すること — 多くのチームはデスクトップでのズームをテストして問題なしと判断しますが、モバイルのビューポートで200%ズームにした場合は別のレイアウト課題が生じます。特に、固定ピクセル高さに依存するナビゲーションメニュー、固定ヘッダー、ボトムナビゲーションバーなどで顕著です。

トルコのアクセシビリティ規制との関係

トルコの大統領通達2025/10は、2025年6月21日付官報第32933号で公布され、トルコで事業を行う特定の組織に対して、ウェブおよびモバイルのアクセシビリティ要件を義務付けています。この通達は国際的に認められたアクセシビリティ標準を参照しており、実質的にトルコの要件をWCAG 2.1およびWCAG 2.2レベルAAと整合させ、適合のベンチマークとしています。

WCAG 1.4.4 Resize TextはレベルAAの達成基準であり、レベルAAへの適合は、家族・社会サービス省（Aile ve Sosyal Hizmetler Bakanlığı）が発行するアクセシビリティロゴ（Erişilebilirlik Logosu）を取得するための閾値です。アクセシビリティロゴは公共の信頼のシグナルであると同時に規制上のチェックポイントでもあります。この通達の対象となる組織がロゴを表示したり、監査人に適合を示したりするには、1.4.4を含むすべてのレベルAA達成基準を満たさなければなりません。

大統領通達2025/10の対象となる主体のカテゴリーには、あらゆるレベルの政府機関・公的機関、eコマースプラットフォームおよびオンラインマーケットプレイス、銀行監督機構（BDDK）の規制下にある銀行および金融サービス提供者、デジタルな患者向けサービスを提供する病院・ヘルスセンターその他の医療機関、20万件以上の加入者を持つ通信事業者、旅行代理店およびオンライン旅行プラットフォーム、デジタルチケットや予約サービスを提供する民間輸送会社、国民教育省（Millî Eğitim Bakanlığı, MoNE）に認可された私立学校および教育機関が含まれます。

これらの各主体にとって、1.4.4の実務的な意味は大きなものです。モバイルでピンチズームをブロックする銀行のオンラインバンキングポータルは、単なるユーザビリティの問題にとどまらず、監査で指摘されたりアクセシビリティロゴプログラムから排除されたりする可能性のある規制上の不適合です。固定ピクセルのフォントサイズをクリッピングコンテナ内で使用している病院の予約システムは、ロービジョンの患者にサービスを提供できていないだけでなく、この通達に基づく義務にも違反しています。同様に、拡大可能なHTMLテキストではなく画像内にテキストを埋め込んでいる私立学校の入学手続きプラットフォームも不適合です。

組織は、WCAG 1.4.4を単なる狭義の技術的チェック項目ではなく、視覚障害のあるユーザーへの敬意の最低限の表明として捉えるべきです。トルコの法律、国際的なベストプラクティス、基本的なユーザビリティは、いずれもこの期待に収れんしています。AccsibleのオーバーレイSDKは、ユーザーがブラウザのズームとは独立してテキストサイズを拡大できる設定可能なフォントスケーリングコントロールを提供することで、テキストリサイズへの準拠を支援します。これは、サイト側が実装すべきベースライン要件に加え、追加の配慮レイヤーを提供するものです。

出典と参考資料

AWCAG 1.1.1: 非テキストコンテンツ AWCAG 1.2.1: 音声のみおよび映像のみ（事前録画）AWCAG 1.2.2: キャプション（事前録画）