WCAG 1.4.10: リフロー

WCAG 1.4.10 Reflow は、コンテンツが情報や機能を失うことなく、また 320 CSS ピクセルに相当する幅で表示されたときに、2 方向へのスクロールを必要とせずに提示できることを求めています。これは、ズームや小さなビューポートに依存するユーザー（ロービジョンの人やモバイルユーザーを含む）が、水平スクロールなしであらゆるコンテンツにアクセスできるようにするためのものです。

このルールの意味

WCAG 1.4.10 Reflow は、WCAG 2.1 で導入され、WCAG 2.2 に引き継がれているレベル AA の達成基準です。これは、ウェブコンテンツがリフローできること、つまり自らを再配置・再サイズして、ビューポートの幅が320 CSS ピクセル相当になっても、ユーザーがコンテンツを読んだり操作したりするために水平方向にスクロールする必要がないよう、完全に利用可能な状態を保つことを求めています。320 CSS ピクセルという基準値は、標準的な 1280px 幅のディスプレイでブラウザのズームレベルを 400% に設定したときにユーザーが見る幅に相当します。

中核となる要件は、この制約された幅において情報や機能が失われないことです。すべてのテキストは読みやすい状態を保ち、すべてのインタラクティブなコントロールは操作可能であり、意味のあるコンテンツはすべて、2 次元スクロールを引き起こすことなく可視のままでなければなりません。垂直スクロールは許可されています。この達成基準が禁止しているのは、縦方向に流れるコンテンツに対する水平方向のスクロール（および、横方向に流れるコンテンツに対する垂直スクロールですが、これはまれです）だけです。テキストの段落を読むために、上下と左右の両方に同時にスクロールすることをユーザーに強いるレイアウトは、この達成基準に不適合となります。

W3C は、2 次元スクロールが許容される明示的な例外を定義しています。これには、2 次元レイアウトがその利用と意味にとって本質的であるコンテンツが含まれます。多数の列を持つ大きなデータテーブル、複雑な地図や地理的図、ビデオプレーヤーとその再生コントロール、横一列に並んだ複数のアクションボタンを持つツールバー、要素間の正確な空間的関係が必要なゲームやインタラクティブな図などです。これらの例外は狭く解釈されなければなりません。免除が適用されるのはコンテンツ自体（たとえばデータテーブルのセル）であり、それを取り囲むナビゲーション、見出し、説明テキストなどには適用されません。

ページがこの達成基準に適合しているのは、ブラウザを 400% にズーム（またはビューポートを幅 320px に設定）したときに、コンテンツが 1 カラムにリフローし、ナビゲーションが適切に折りたたまれるか積み重なり、画像が比例してリサイズされ、ユーザーがデフォルトのズームレベルと同じことを垂直スクロールだけで行える場合です。ページが不適合となるのは、文を読む、ボタンに到達する、免除対象ではないコンテンツにアクセスするために水平スクロールが必要になる場合です。

なぜ重要か

世界保健機関によると、世界で約 22 億人が何らかの視覚障害を抱えています。そのうちのかなりの割合の人々は、テキストやインターフェース要素を十分に大きくして快適に知覚できるようにするため、ブラウザのズーム、OS の拡大機能、あるいは ZoomText や Windows Magnifier のような専用の画面拡大ソフトウェアに依存しています。高いズームレベルでレイアウトが崩れ、コンテンツが画面外に押し出されたり、水平スクロールを強いられたりすると、これらのユーザーは、1 文ごとに左右へパンしなければならない分断された読書体験を強いられます。これは単なる不便にとどまらず、複雑なコンテンツを事実上利用不可能にしてしまうことがあります。

加齢黄斑変性のある 65 歳のユーザーが、ブラウザを 300% ズームに設定してトルコの病院の予約ポータルを閲覧している状況を考えてみてください。予約フォームが固定幅のカラムでレンダリングされると、「送信」ボタンが可視領域の右端の外側に完全に押し出されてしまうかもしれません。ユーザーはそのボタンの存在を知ることすらできず、ましてやそれを操作することもできません。自力で予約を完了することができないのです。これは、Reflow に不適合であることによって生じる直接的で具体的な不利益です。

低視力のユーザー以外にも、Reflow は幅広い人々に利益をもたらします。スイッチアクセスやヘッドトラッキングデバイスを使用する運動障害のあるユーザーにとって、水平スクロールは極めて困難か、信頼して行うことが不可能な場合があります。認知障害は人口のかなりの割合に影響しており、研究では一貫して、適切に実装された Reflow に典型的な、狭い 1 カラムレイアウトが認知負荷を軽減し、読解力を向上させることが示されています。小さな画面のデバイスを使用している人や、画面分割モードで閲覧している人も、障害の有無にかかわらず直接的な恩恵を受けます。

技術的・ビジネス的な観点から見ると、Reflow を正しく実装することは、構造化されたレスポンシブデザインを構築することとほぼ完全に重なります。つまり、1.4.10 に適合することは自然とモバイルのユーザビリティを向上させ、直帰率を下げ、検索エンジンのランキングに影響する Core Web Vitals 指標にも良い影響を与えます。特にトルコの e コマースプラットフォームでは、モバイルトラフィックが支配的であるため、Reflow への準拠と商業的なモバイル最適化は本質的に同じ目標と言えます。

テスト方法

自動プレスキャン: 各ページに対して Chrome DevTools で axe DevTools または Lighthouse を実行します。特に、ズームがブロックされ Reflow の不適合が保証されることを示す meta-viewport 違反を探します。また、「要レビュー」としてフラグされたオーバーフロー関連の警告にも注目します。結果を記録しますが、自動スキャンで問題が検出されなかったとしても Reflow への適合が確認されたことにはならない点を理解してください。手動ステップは必須です。
ビューポートを 320px に設定: Chrome または Firefox の DevTools でデバイスツールバー（Ctrl+Shift+M / Cmd+Shift+M）を開き、カスタムデバイスサイズとして 320×568 ピクセル（高さは任意）を入力し、デバイスピクセル比を 1 に設定します。あるいは、1280px 幅のブラウザウィンドウを開き、Ctrl+=（Mac では Cmd+=）で 400% までズームします。どちらの方法も、WCAG が指定する 320 CSS ピクセルの条件をシミュレートします。
ページ全体を縦方向にスクロール: ページの先頭から、垂直スクロールバーまたはマウスホイールのみを使って下方向にスクロールします。免除対象ではないコンテンツに対して水平スクロールバーが表示されるべきではありません。表示された場合、そのページは不適合です。すべてのテキストが完全に読めること、文が途中で切れていないこと、文字がビューポートの端でクリップされていないことを確認します。
すべてのインタラクティブ機能をテスト: 幅 320px の状態で、主要なユーザータスクをすべて完了できるか試します。フォームの入力と送信、ナビゲーションメニューの開閉、モーダルやダイアログの起動、アコーディオンやタブの使用、カルーセルとのインタラクション、動的コンテンツのトリガーなどです。すべてのコントロールは、垂直スクロールと通常の操作だけで到達・操作できなければなりません。
すべてのページテンプレートと状態を確認: ホームページ、内部コンテンツページ、フォーム、チェックアウトフロー、エラー状態、認証後のビューなどをテストします。ホームページではレスポンシブナビゲーションが正しく折りたたまれていても、別テンプレートを使用する深い階層の商品ページでは崩れている場合があります。
スクリーンリーダーとの併用（補足）: 幅 320px の状態で、Firefox と NVDA、または Safari と VoiceOver を使用し、リフロー後もコンテンツの順序と意味が保たれているか確認します。CSS ベースのリフローによって視覚的な順序だけが変わり、DOM の順序が変わらない場合、スクリーンリーダーの読み上げが混乱を招くことがあります。これは厳密には Reflow のテストではありませんが、別のアクセシビリティ問題を生むリフロー実装を検出するのに役立ちます。
例外を文書化: 水平スクロールが必要なコンテンツ（データテーブル、地図、コードブロックなど）がある場合、それが WCAG で定義された例外に真に該当することを検証し、文書化します。埋め込みコンポーネントがリフローしない場合でも、その周囲のページコンテンツ（見出し、説明、ナビゲーション）が正しくリフローしていることを確認します。

修正方法

固定幅コンテナがレイアウトを壊している — 不適切な例

<!-- Fixed pixel width forces horizontal scrolling at small viewports -->
<div style='width: 960px; margin: 0 auto;'>
  <p>This content will overflow a 320px viewport and require horizontal scrolling.</p>
  <button>Submit Application</button>
</div>

固定幅コンテナがレイアウトを壊している — 適切な例

<!-- Use max-width with 100% so container never exceeds its parent but shrinks on small screens -->
<div class='content-wrapper'>
  <p>This content reflows naturally at any viewport width.</p>
  <button>Submit Application</button>
</div>

<!-- In your CSS (external stylesheet) -->
<!-- .content-wrapper { max-width: 960px; width: 100%; margin: 0 auto; box-sizing: border-box; padding: 0 1rem; } -->

ビューポートメタタグがズームをブロックしている — 不適切な例

<!-- This prevents users from zooming at all, making Reflow impossible to achieve -->
<meta name='viewport' content='width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no'>

ビューポートメタタグがズームをブロックしている — 適切な例

<!-- Allow zooming by removing maximum-scale and user-scalable restrictions -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!-- Users can now zoom to 400% and content will reflow as required by WCAG 1.4.10 -->

横並びナビゲーションバーがオーバーフローしている — 不適切な例

<!-- Navigation items forced into a single row with no wrapping or collapse mechanism -->
<nav aria-label='Primary navigation'>
  <ul style='display: flex; flex-wrap: nowrap; white-space: nowrap;'>
    <li><a href='/home'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About Us</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/blog'>Blog</a></li>
    <li><a href='/support'>Support</a></li>
  </ul>
</nav>

横並びナビゲーションバーがオーバーフローしている — 適切な例

<!-- Hamburger/disclosure pattern for small viewports; full navigation accessible at all sizes -->
<nav aria-label='Primary navigation'>
  <button aria-expanded='false' aria-controls='nav-menu' id='nav-toggle'>
    Menu
  </button>
  <ul id='nav-menu'>
    <li><a href='/home'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About Us</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/blog'>Blog</a></li>
    <li><a href='/support'>Support</a></li>
  </ul>
</nav>
<!-- CSS media query hides #nav-menu by default below a breakpoint and shows it on toggle -->
<!-- The button is hidden above the breakpoint where the full nav is always visible -->

リフロー対応のないデータテーブル — 不適切な例

<!-- Wide table with no scroll container; overflows the viewport with no warning to users -->
<table>
  <caption>Quarterly Sales Data</caption>
  <thead>
    <tr>
      <th scope='col'>Region</th>
      <th scope='col'>Q1</th>
      <th scope='col'>Q2</th>
      <th scope='col'>Q3</th>
      <th scope='col'>Q4</th>
      <th scope='col'>Total</th>
    </tr>
  </thead>
</table>

リフロー対応のないデータテーブル — 適切な例

<!-- Wrap the table in a scrollable container scoped to just the table element -->
<!-- This is an explicit WCAG 1.4.10 exception for complex data tables -->
<div role='region' aria-labelledby='table-caption' tabindex='0' class='table-scroll-container'>
  <table>
    <caption id='table-caption'>Quarterly Sales Data (scroll horizontally to view all columns)</caption>
    <thead>
      <tr>
        <th scope='col'>Region</th>
        <th scope='col'>Q1</th>
        <th scope='col'>Q2</th>
        <th scope='col'>Q3</th>
        <th scope='col'>Q4</th>
        <th scope='col'>Total</th>
      </tr>
    </thead>
  </table>
</div>
<!-- CSS: .table-scroll-container { overflow-x: auto; } -->
<!-- The caption warns users, role=region + aria-labelledby makes it keyboard-focusable -->

よくある間違い

根本的なオーバーフローを修正せずに、<body> やトップレベルのラッパーに overflow: hidden を設定して水平スクロールバーを隠すこと: これはスクロールバーを隠すだけで、コンテンツ自体は依然としてクリップされアクセス不能です。ユーザーにはビューポートの外側にコンテンツが存在することが分からないため、可視のオーバーフローよりも状況が悪化する場合があります。
高いズームでモバイルレイアウトが「壊れて見える」のを防ぐために、viewport メタタグで max-scale=1 や user-scalable=no を設定すること: これはユーザーのズーム機能を完全に無効化し、Reflow の不適合であると同時に、WCAG 1.4.4 Resize Text の違反にもなります。
ブレークポイントごとの上書きなしに、テキストコンテナ、ナビゲーションリスト、ボタングループに white-space: nowrap を適用すること: これは利用可能なスペースに関係なくテキストを 1 行に強制し、320px での水平オーバーフローの最も一般的な原因の 1 つです。
レスポンシブなフォールバックなしに、CSS Grid の grid-template-columns 定義で絶対ピクセル値（例: grid-template-columns: 300px 600px）を使用すること: 幅 320px のとき、2 つのカラムの合計は 900px となり、メディアクエリで定義を 1fr や 100% に置き換えない限り、リフローせずにオーバーフローします。
サードパーティコンテンツ（地図、動画、フォーム）を指す固定の width と height 属性を持つ <iframe> 要素を埋め込むこと: Iframe は自動的にはスケールしないため、幅 600px の埋め込み地図は幅 320px のビューポートでオーバーフローします。Iframe をアスペクト比を維持するコンテナでラップし、iframe 自体には width: 100% を設定します。
幅 320px より大きな固定の最小幅を持つモーダルダイアログやオフキャンバスパネルを設計すること: min-width: 500px のモーダルはオーバーフローし、小さなビューポート幅では閉じるボタンが画面外に隠れてしまい、キーボードユーザーをダイアログ内に閉じ込めてしまう可能性があります。
コードブロックや <pre> 要素を、水平スクロール可能なコンテナでラップせずに Reflow の例外として扱うこと: 生のコードブロックは WCAG の例外として挙げられていません。コードコンテンツ自体は複雑であっても、周囲のページはリフローしなければなりません。コードブロックは overflow-x: auto を持つラッパー内で独立してスクロールし、ページ全体に水平スクロールを発生させてはなりません。
認証後や動的な状態のテストを忘れること: 多くのチームはログアウト状態のホームページだけをテストします。ダッシュボード、ユーザープロファイルページ、多段階フォーム、JavaScript で読み込まれるエラー状態などは、固定幅を前提に構築されていることが多く、マーケティングページが適合していても Reflow に不適合となることがよくあります。
真のレスポンシブレイアウトを実装する代わりに、CSS の transform: scale() を使ってコンテンツを視覚的に縮小すること: スケーリングは見かけのサイズを小さくするだけでコンテンツをリフローさせません。テキストは読みやすい 1 カラムにリフローするのではなく小さく読めない状態になるため、Reflow と Resize Text の両方の達成基準に不適合となります。
モバイルレスポンシブデザインであれば自動的に Reflow に適合すると想定すること: レスポンシブデザインは通常、360px、768px、1024px といったブレークポイントをターゲットにします。WCAG の基準である 320px は、ほとんどのモバイルブレークポイントよりも狭く、標準的な小型スマートフォンで問題なく見えるコンテンツでも、320px ではオーバーフローする可能性があります。一般的な「モバイル」サイズではなく、必ず正確に 320px でテストしてください。

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

トルコの大統領通達 2025/10は、2025 年 6 月 21 日付官報（番号 32933）で公布され、トルコで事業を行う幅広いデジタルサービス提供者に対して拘束力のあるアクセシビリティ要件を定めています。この通達は、対象組織に対し、国際的なウェブアクセシビリティ標準への準拠を義務付けており、そのベースラインとして WCAG 2.1 レベル AA を位置付けています。1.4.10 Reflow を含む 2.1 のすべての達成基準を取り込んだ WCAG 2.2 レベル AA への準拠は強く推奨されており、家族・社会サービス省（Aile ve Sosyal Hizmetler Bakanlığı）が発行するErişilebilirlik Logosu（アクセシビリティロゴ）を取得するために求められる標準でもあります。

大統領通達 2025/10 の対象となる組織には、あらゆるレベルの公的機関・政府機関、銀行や金融機関、病院や医療提供者、20 万人以上の加入者を持つ通信会社、e コマースプラットフォーム、旅行代理店、民間輸送会社、国民教育省（Millî Eğitim Bakanlığı）に認可された私立学校などが含まれます。これら各分野において、ウェブサイト、ウェブアプリケーション、モバイルウェブコンテンツといった一般向けのデジタルインターフェースはすべて、ズームやビューポート調整に依存してコンテンツを知覚する人を含む障害者にとって利用可能でなければならない、というのが期待される水準です。

WCAG 1.4.10 Reflow は、トルコの文脈において特に重要な意味を持ちます。その理由はいくつかあります。第一に、トルコではモバイルインターネットの普及率が非常に高く、多くのユーザーがさまざまなズームレベルのモバイルブラウザを通じて、行政サービス、バンキングポータル、e コマースプラットフォームにアクセスしています。Reflow に不適合な病院の予約システムは、低視力の高齢患者が自力で診察予約を行うことを妨げる可能性があり、これはアクセシビリティ法と対象機関の公共サービス使命の双方に対する直接的な不履行です。第二に、Erişilebilirlik Logosu プログラムでは、すべてのレベル AA 達成基準を対象とする適合監査が求められており、1.4.10 に不適合であれば、他の点で適合しているサイトであってもロゴ取得資格を失います。第三に、多数の加入者を抱える通信会社にとって、アクセシブルなセルフサービスポータルやアカウント管理インターフェースは不可欠です。固定幅のアカウントダッシュボードが 400% ズームでオーバーフローする場合、本来であれば店舗訪問やサポートへの電話を必要としない視覚障害のある加入者に直接的な不利益を与えることになります。

トルコのアクセシビリティ規制の下で適合を示そうとする組織は、レスポンシブデザインの実装が 320 CSS ピクセルの閾値で特に検証されていること、ユーザーのズームをブロックする viewport メタタグが存在しないこと、認証フロー、フォーム送信、ドキュメントダウンロードを含むすべてのインタラクティブ機能が、水平スクロールなしで完全に操作可能な状態を保っていることを確認すべきです。Reflow テストを文書化されたアクセシビリティ監査の一部として組み込むことは、規制当局に対して適合を示すうえで、また Erişilebilirlik Logosu の取得資格を維持するうえで不可欠となります。

出典と参考資料

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