この翻訳はWAICが公開する翻訳ではありません。これは私家訳であり、レビューもされていないため、翻訳に誤りがあるかもしれません。また、WAICの翻訳が更新され次第、このページは削除します。現在のWAICのリフローの解説書を見る

Skip to content

解説書 達成基準 1.4.10:リフロー (レベル AA)

要約

目標
行の長さを増すことなく、コンテンツを拡大できる。
何をすればよいか
テキストの行をビューポート内でリフローさせる。
なぜそれが重要か
大きな文字を必要とする人が、長い行を読むためにスクロールしなければならない場合、読むことに苦労する。

達成基準

コンテンツは、情報又は機能を損なうことなく、かつ、以下において 2 次元スクロールを必要とせずに提示できる:

  • 320 CSS ピクセルに相当する幅の縦スクロールのコンテンツ。
  • 256 CSS ピクセルに相当する高さの横スクロールのコンテンツ。

利用や意味の理解に 2 次元のレイアウトを必要とする一部のコンテンツを除く。

注記 1

320CSS ピクセルは、400% ズーム時の開始ビューポート幅 1280 CSS ピクセルに相当する。横スクロールになるように設計されたウェブコンテンツ (例えば、縦書きのテキスト) の場合、256 CSS ピクセルは、400% ズーム時の開始ビューポート高さ 1024 CSS ピクセルに相当する。

注記 2

2 次元のレイアウトを必要とするコンテンツの例としては、理解のために必要な画像 (地図、図解など)、映像、ゲーム、プレゼンテーション、データテーブル (個々のセルではない)、及びコンテンツを操作している間にツールバーを表示しておく必要のあるインタフェースが挙げられる。コンテンツのそのような部分には、2 次元スクロールを提供することが許容される。

意図

この達成基準の目的は、ユーザーが2次元でスクロールして読むことなく、テキストやその他の関連コンテンツを拡大できるようにすることです。テキストの行がビューポートの端を超えると、ユーザーは1行ずつ読むために前後にスクロールする必要があります。これにより、ユーザーはどこまで読んだのかがわからなくなり、身体的および認知的労力の両方が大幅に増加する可能性があります。したがって、コンテンツのほとんどのセクションは、この達成基準で定義された適切なサイズ要件の範囲内でリフローすることを求めます。

テーブル、地図など、理解と機能のために2次元レイアウトを必要とするコンテンツのセクションには、この達成基準に対する例外があります。しかし、テーブル内の各セルなど、2次元レイアウト内のコンテンツのセクションは、この達成基準を満たす必要があります。理解と機能のために2次元のレイアウトを必要とするコンテンツのセクションには例外がありますが、コンテンツ制作者はそのタイプのコンテンツのスクロールを減らす努力をすることで、ユーザーエクスペリエンスを向上させることができます。

基本のテキストのリフロー

リフローの最も基本的な形式は、テキストのみのページで発生します。デフォルトでは、長いテキスト行は使用可能なビューポート内に収まるように折り返されます。左から右(LTR)および右から左(RTL)の横書き言語で記述されたテキストの場合、ビューポートの幅内で折り返されます。縦書き言語の場合、テキストはビューポートの高さ内で折り返されます。

1対の画像。1番目の画像には、ページの幅に収まるさまざまな長さの水平線が表示され、2番目の画像には、ページの高さに収まるさまざまな長さの垂直線が表示されます。

図1 通常、ページを垂直方向にスクロールして読む言語(英語など)で書かれたページの場合、テキスト行を読むために水平方向の前後にスクロールするもないことが望ましいです。同様に、読むために水平方向にスクロールする言語(伝統的な中国語、日本語など)で書かれたコンテンツを読んでいるユーザーは、読むために垂直の前後にスクロールする必要もないことが望ましいです。

テキストを拡大(ズーム)して読む必要があるユーザーは、テキストがリフローされるときに大きなメリットがあります。テキストのサイズに関係なく、表示されているビューポート内で折り返されます。テキストの行全体が表示されるので、ある行の終わりから次の行の始まりまでを簡単に追跡できます。ユーザーは、読む方向にスクロールするだけで、追加のテキスト行を読むことができます。

図2 テキストのサイズが変更されると、テキスト行がビューポートを超えないように単語が折り返されます。(200%へのこの簡単なデモは、適合性のテストを説明することを意図したものではありません。)

この基準では、横書きの言語で記述されたコンテンツの例外でないセクションは、320 CSSピクセルに相当する幅に狭められたときにリフローすることが要求されます。同様に、縦書き言語で記述されたコンテンツのセクション(Webではそれほど一般的に使用されていないため、サンプルではあまり使用されません)は、256 CSSピクセルに相当する高さでレンダリングされたときにリフローできる必要があります。

図 3 テキストのコンテナの幅が狭くなると、テキスト行がコンテナの幅を超えないように単語が折り返されます。(この簡単なデモは、適合性のテストを説明することを意図したものではありません。)

ウェブサイトおよびウェブアプリケーションのリフロー

モダンなウェブサイトおよびアプリケーションでは、一般的にレスポンシブウェブデザインのベストプラクティスを採用して、コンテンツのセクションを調整または再配置して、より小さなビューポート内に収まるようにしています。ユーザーがコンテンツにアクセスできる限り、コンテンツの調整または再配置は情報または機能の損失とはみなされません。コンテンツを小さなビューポート内に収めることができれば、モバイルデバイスを使用しているユーザーがコンテンツを読むのに役立つだけではありません。また、この達成基準の目的と同様に、より大きなデバイスでウェブインターフェイスのサイズを変更したりズームしたりする必要がある人にも役立ちます。

コンテンツを単一の列に調整する

多くの記事駆動型のウェブページがリフローの達成基準を満たすための一般的な方法は、ウェブページの表示がコンテンツの単一の列に調整され、320 CSSピクセル幅のビューポートに適合し、ユーザーがウェブページのコンテンツを読むために垂直方向にスクロールするだけでよいことを保証することです。

ニュースサイトのホームページのスクリーンショット。ロゴと主要なナビゲーションで構成されるグローバルサイトバナーが表示されます。ライブニュースラジオ用のメディアプレーヤー。主要なストーリーが表示され、イントロテキストと行動喚起のリンクが1つの列に表示され、その横の列にストーリーに関連する写真が表示されます。そのすぐ下には、別の列に3つの追加のトップストーリーがあります。画像はそれぞれを紹介し、その後にストーリーのタイトルと簡単な説明が続きます。画像はそれぞれを紹介し、その後にストーリーのタイトルと簡単な説明が続きます。

図 4 デフォルトのブラウザーのズームとデスクトップ表示解像度で、ニュースサイトには、ニュースティーザー、広告、その他のマルチメディアウィジェットのスニペットがコンテンツの個別のセクションとして表示されます。これらのセクションは、ウェブページのデザインに合わせてサイズや配置を変えることができますが、それぞれのセクションは、視覚的なレイアウトまたは理解されるべきコンテンツの他のセクションに依存することなく、それ自体で読んで対話できます。

320ピクセル幅のビューポートでレンダリングされたニュースサイト。ナビゲーションはハンバーガーメニューにまとめられているので、グローバルヘッダーは視覚的に整理されており、デフォルトではハンバーガーメニュー、ロゴ、寄付ボタンだけが表示されます。メディアプレーヤーは、ビューポートの下部にある永続的なスティッキーウィジェットになりました。ニュース記事は1つの列に収まるように調整されています。これは、縮小されたビューポートサイズ内に一度に収まるニュース記事のリードインが1つだけであるためです。

図 5 ニュースサイトのレイアウトは、ブラウザーのサイズ変更またはズーム機能の使用によって、さまざまなビューポートサイズに合わせて調整されます。ウェブページのレイアウトが調整されると、コンテンツのセクションが垂直に積み重ねられ、一方向にスクロールして読むことができます。メインナビゲーションはハンバーガーメニューボタンの後ろに隠され、メディアプレーヤーは移動されて簡素化され、ページのコンテンツをブロックすることなく表示されたままになります。

「ひとつの列に積み重ねる」アプローチは、コンテンツのセクションをユーザーが読めるように表示することを主な目的とする多くのウェブページで機能します。たとえば、無関係のサイドバーを持つ記事や、視覚的なグリッドやメイソンリーレイアウトでティーザーコンテンツの異なるセクションを表示するホームページなどです。これらのレイアウトは、コンテンツの理解しやすさに必要不可欠ではありません。しかし、このアプローチは、一般的であるが複雑なウィジェットおよびレイアウトのすべてのインスタンスに対して機能するとは限らず、それらが単一の列レイアウトに適合するように単純に積み重ねられた場合、視覚的に理解したり相互作用したりすることがより困難になります。

意味または機能のために2次元レイアウトから利益を得ることができるコンテンツ

複雑なウェブインターフェイスを構築するには、多くの場合、複雑なレイアウトおよびウィジェットを組み込む必要があり、コンテンツが拡大されるときには、レイアウトの変更、機能の調整、またはその両方を必要になります。

この達成基準に適合することは、コンテンツのすべてのセクションが小さなビューポート内の1つの列に積み重ねる必要があることを意味するわけではありません。また、コンテンツのすべてのセクションを一方向にスクロールする必要もありません。ただし、各セクションが表示されるテキスト行を2次元スクロールせずに読むことができる場合に限ります。

以降の例は、水平スクロールなしで機能するように設計できますが、達成基準に適合していることを示すように設計されています。

ネストされたリストまたはコードのフォーマット

コードのリストやブロックは、階層や意味を視覚的に伝えるために、テキストのインデントに依存することがよくあります。インデントが削除されると、意味または機能が損なわれる可能性があります。例えば、順序付けされていないリスト階層のネストは、インデントが削除された場合、より気づきにくくなります。さらに、インデントと改行しない行を維持することは、コードが機能するために必要でなくても、コードパターンを理解するのに役立つ重要なことがあります。

詳細については、テクニックG224: 意味のあるテキストのインデント及びリフローを考慮する [レビュー中]を参照。

カルーセルおよびカルーセルのようなウィジェット

垂直方向にスクロールするウェブページ内では、カルーセルの実装は、それらのコンテンツの水平スクロールを可能にできます。カルーセルがスクロールすると、可視ビューポート内に新しいカルーセルパネルが表示されます。カルーセル内の個々のパネルが320 CSSピクセルのビューポート内に収まる限り、ユーザーは単一方向にスクロールするだけで個々のパネルのコンテンツを読むことができます。

水平にスクロールするカルーセルには、販売されているさまざまな住宅に関するティーザーコンテンツの複数の「パネル」が含まれています(スクリーンショットには4つのティーザーパネルが表示されています)。 カルーセルパネルの1つが400%拡大しました。縦書きテキストは、320ピクセル幅のコンテナ内に収まります

図 6 合格: カルーセルには、販売中の住宅に関するさまざまなティーザーコンテンツのパネルが表示されます。カルーセルコンテナは、プライマリウェブページの垂直スクロールとは関係なく、水平方向にスクロールします。カルーセル内の個々のパネルは、ウェブページのコンテンツの読み取り方向(上から下)に従って垂直方向に読み取られるように設計されています。拡大すると、各パネルは320 CSSピクセルのビューポート内に収まります。

図 7 失敗: 前のカルーセルのこの修正バージョンでは、2番目のパネルのコンテンツが320 CSSピクセルビューポート内に収まりません。

詳細については、テクニックG225: 垂直にスクロールするページで 320 CSS ピクセルの幅に収まるように設計されている、水平にスクロールするセクションパネルを参照。

変更を編集する2列のプレゼンテーション

コードまたはテキストの違いを並べて確認できることは、スクロールする2列レイアウトがユーザーに利益をもたらす例となり得ます。

図 8 合格: コードまたは文書の変更を確認するためのインターフェイスでは、元のコンテンツと変更されたコンテンツを2列で比較できます。各列は320 CSSピクセル幅のコンテナ内に収まり、水平スクロールバーを使用して各列を可視ビューポートに配置できます。

別のビューでは、変更された行を重ねて表示できますが、2列の比較ビューでは、同じ水平の面で元のコード行と変更されたコード行を直接比較できます。これは、特に変更が複数の行にまたがる場合、一部のユーザーにとっては理解しやすく、元のコンテンツブロックと変更されたコンテンツブロックの間を垂直方向にスクロールする必要性が軽減されます。

リフローの例外を満たすコンテンツ

従来の多くのウェブページでは、ページの主な目的は、ユーザーが複数行のテキスト段落を含む個別のコンテンツのセクションを読むことであり、ウェブページは通常、垂直方向にスクロールします(西洋言語で書かれている場合)。ロービジョンの人は、コンテンツを読むためにウェブページをズームインする必要があるかもしれません。ブラウザーのズームを使用してズームインすると、コンテンツは大きくなりますが、ビューポートのサイズは小さくなります。

すべてのコンテンツが、情報や機能を低下させることなく、より小さなビューポートに完全にリフローできるわけではありません。すでに述べたように、これには、テーブル形式のデータ、グラフィックス、地図、プレゼンテーション、使用するために永続的なツールバーを必要とするインターフェイス、およびコンテンツの関連セクションへの一貫した方向付けが理解しやすさ、機能性、またはその両方にとって重要である2次元レイアウトが含まれます。

例外の範囲を理解する

コンテンツのセクションが2次元スクロールの例外を満たす場合、その例外はそのセクションにのみ適用されます。コンテンツのセクションがリフローから除外されても、その例外は、理解や機能のために2次元スクロールを必要としない他のコンテンツには自動的には適用されません。

表の下部とテキストの複数行の段落のスクリーンショットを拡大しました。 それぞれが画面外に拡張され、ページレベルで水平スクロールバーと垂直スクロールバーの両方が表示されます。

図 9 失敗: この例の実装方法により、ウェブページには水平スクロールバーと垂直スクロールバーの両方があります。この表は、理解のための2次元レイアウトの例外を満たしていますが、スクリーンショットのテーブルに続く段落は満たしていません。

データテーブルは、理解のために2次元レイアウトに依存しますが、そのテーブルをそれ自体のスクロール可能なコンテナ内に提示することによって、2次元レイアウト例外を満たさない他のコンテンツが、それを含む要素が調整されるにつれてリフローすることを可能にします。例えば、ブラウザーのサイズ変更やズームなどです。

テーブルの内容を表示するための双方向スクロールバーを提供する、包含要素内のテーブル。テーブルの上下のコンテンツは、ビューポートの使用可能な幅に収まるようにリフローされます。

図 10 合格: テーブルのデータはリフローの例外となっています。高さ、幅、またはその両方が最小のテーブルを含む要素は、双方向スクロールバーを提供するようにスタイル設定できます。これにより、ユーザーはテーブルの内容をスクロールし、ページレベルで表示される双方向スクロールバーを軽減できます。左側では、デフォルトでズームされたウェブページのユーザーがアクセスできるファイルを表す4つの列からなるテーブルが表示されます。右側では、ウェブページがズームインされ、独自の双方向スクロールバーを持つ要素内にテーブルがレンダリングされています。

2次元の除外されたコンテンツが可視ビューポートを超えて拡張され、ページ全体がスクロールする場合があります。同時に、同じページ上の他の除外されていないコンテンツは、可視ビューポート内でリフローされます。前のテーブルの例では段落がリフローされていなかったのとは異なり、このような状況は合格します。リフローは、ウェブページがコンテンツの個々のセクションに対して水平スクロールバーと垂直スクロールバーの両方を表示することを禁止するものではありません。また、除外コンテンツの表示をサポートするために、ページ(ビューポート)レベルでの双方向スクロールバーの使用を禁止することもありません。ただし、除外されていないコンテンツが一方向にスクロールするだけでよい場合に限ります。

可能な限り、ページ全体を2次元でスクロールさせるのではなく、そのようなスクロールを必要とするコンテンツの個々のセクションのみに2次元スクロールを制限することが、ユーザーにとって最善の利益となります。例えば、不要な水平スクロールバーが表示されると、ユーザーは画面外にスクロールできるコンテンツが存在すると考える可能性があります。しかし、そのスクロールバーが除外されたコンテンツの1つのインスタンスのためだけに表示される場合、ユーザーは、存在しない他のリフローしないコンテンツを探すために労力を費やすかもしれません。

BBC Earthのビデオは、ブラウザのビューポートの横幅をはるかに超えて拡張されているため、ウェブページに大きな水平スクロールバーが表示されます。それ以外の場合、ウェブページのコンテンツは幅320 pxのコンテナに収まります。このコンテナは、ブラウザの開発者ツールを使用して検証され、含まれる要素の幅が320 pxであることが示されます。

図 11 合格: max-width:100% CSSプロパティを持たないビデオプレーヤーでは、小さい(拡大表示された)ビューポートでもフルサイズのままになります。ページの残りのコンテンツは、320 CSSピクセル幅のコンテナ内でリフローされます。 そういうわけで、ページレベルで大きな水平スクロールバーが表示されますが、これはビデオプレーヤーにリフローの例外があるためです。前のテーブルの例では、段落が画面外に拡張され、読むために2次元のスクロールが必要な方法でページが実装されていましたが、このシナリオは、除外されていないすべてのコンテンツがリフローするため、このシナリオは合格です。しかし、これは最良のユーザーエクスペリエンスを提供するものではなく、理想的には、ビデオプレーヤーのスタイリングを更新して、そうでなければ不要な水平スクロールバーを軽減します。

ビデオプレーヤーは、拡大表示されたブラウザビューポート内に収まる、ビデオプレーヤーを含む要素内に視覚的に収まります。

図 12 合格: ビデオプレーヤーにmax-width: 100% CSSプロパティを指定すると、ビデオはコンテナ要素の中に収まります。水平スクロールバーがページに表示されなくなり、ビデオ以外のコンテンツが可視ビューポートの外に表示される可能性が軽減されます。

グラフィックス、ビデオ、その他の固定寸法のメディア

グラフィックスとビデオは、その性質上2次元です。グラフィック(写真、図面、グラフなど)をスライスしてブロックを積み重ねると、グラフィックが理解しにくくなります。理解できなくなることはありません。ただし、他のコンテンツが400%にズームされても、これらの要素をビューポートの範囲内に収めることができます。

詳細については、参考テクニックC37: 画像を収めるために、CSS の max-width 及び height を使用するを参照。

テーブル形式のデータとグリッドベースのUI

データテーブルおよびグリッドでは、列ヘッダーと行ヘッダーおよびデータセルの間に2次元の関係があります。したがって、この達成基準には、データテーブルおよびグリッドがテキストの方向にスクロールせずに表示する必要があるという例外があります。ただし、セルに使用方法や意味のために2次元レイアウトを必要とするコンテンツが含まれていない限り、個々のセルはリフローを満たす必要があります。

テーブルとグリッドの例外は、一般的に「テーブルデータ」と見なされるもの以外のコンテンツを対象とします。例えば、 「電子番組ガイド」 は、オンラインでストリーミングするメディア番組を表示するために使用されるグリッドの一種です。これは、グリッドベースのレイアウト以外の他のコンテンツと一緒に表示される場合があります。視聴方法およびポスターアートに関する情報を含む番組ガイドの個々のセルは、必要な幅または高さ内に収まることが期待されます。

先行する見出し、検索フィールド、異なるデータセットを読み込むための付随するページ区切りなど、テーブルまたはグリッドに関連するその他のコンテンツは、リフローを満たすことから除外されません。例えば、テーブルは、その理解しやすさを維持するために2次元スクロールを必要とする場合がありますが、テーブルを紹介する見出しまたは段落、または、ユーザーがテーブルコンテンツの異なる「ページ」を検索またはナビゲートすることを可能にする検索フィールドおよびページ区切りコンポーネントは、この例外を拡張しません。ユーザーが不必要にUIをスクロールして除外されていないコンテンツを見つけて操作する必要性を減らすために、より小さなビューポートに調整することが期待されます。

見出し、検索バー、表、ページ区切りのスクリーンショット。失敗した例では、見出しと検索バーが同じ水平ページに表示され、それぞれがビューポートの表示領域の外側に拡張されています。ページ区切りも同様に切断され、「次へ」ボタンが失われます。次の例では、320ピクセル幅のビューポート内の見出しと検索バーが互いに重なり合っています。テーブルはスクロール可能な領域内にあり、移動するページが少なくなるようにページネーションのサイズが縮小されていますが、「前へ」ボタンと「次へ」ボタンは正しく表示されています。

図 13 失敗: 左側では、テーブルはスクロール可能なコンテナ内でレンダリングされません。インターフェイスの実装では、読むためにズームする必要があることを考慮していなかったため、より小さなビューポートサイズに適応していました。2次元スクロールバーはビューポート全体をスクロールするために使用されますが、一部のコンテンツは正しくレンダリングされず、使用できないとは言わないまでも困難になります。

合格: 右側では、テーブルの前には見出しと検索入力があり、その後にページ区切りコンポーネントがあります。これらはすべて、可視ビューポート内にあります。テーブルはリフローから除外され、スクロール可能なコンテナ内でレンダリングされます。見出しとページ区切りは例外ではなく、拡大表示されたビューポート内に収まるように調整されています。

固定ツールバーとのインターフェイス

コンテンツを編集するためのツールバーのあるインターフェイスは、ビューポートにコンテンツとツールバーの両方を表示する必要があります。ツールバーボタンの数によっては、ツールバーをテキストの方向にスクロールする必要がある場合、またはツールバーを完全に表示したままリッチテキストコンテンツや編集可能なキャンバス領域と一緒にスクロールする必要がある場合もあります。

写真編集インターフェースのモックアップ。ツールバーとパネル/ダイアログは、編集可能なイメージキャンバスの編集に必要なコントロールが含まれているため、常に表示されたままになります。

図 14 合格: 写真編集インターフェイスには、固定サイズのキャンバス領域、ならびに編集可能な画像キャンバスを操作するための永続的なツールバー、パネル、およびコントロールのダイアログが表示されます。パネルおよびダイアログはサイズ変更が可能で、320px 幅のビューポート内に収まるようにすることができます。

使用と意味に必要なレイアウト

複雑なウェブアプリケーションインターフェイスを使用すると、定義された寸法にコンテンツセットを作成できます。例えば、プレゼンテーションや文書は、物理的な印刷または表示サイズに基づくことができます。複雑なインターフェイスでは、多くの場合、一次コンテンツ制作者が作成したコンテンツの一部ではなく、コンテンツに直接関連するコンテンツを作成することができます。例えば、プレゼンテーションノート、テキスト文書に対するコメント/提案の編集、メッセージ(チャット)インターフェイスと共に提示される動的メッセージングなどです。コンテンツのこれらの関連するセクションのそれぞれは、しばしば互いに並行して提示される必要があり、それらの全体的な位置が変化した場合、それらの理解しやすさは低下する可能性があります。

オンラインリッチテキストドキュメント-左側:テキストドキュメントは、ページの物理的な幅と高さを表す寸法で表示されます。右:文書ドキュメント内のハイライト表示されたテキストを参照するコメント。

図 15 リッチテキストドキュメントは、物理的に印刷された場合にページがどのようにフォーマットされるかを表す高さと幅の寸法で表示されます。一部のテキストは強調表示され、コメントが関連付けられていることを示します。このコメント(コンテンツの関連セクション)は、リッチテキストドキュメントの横の独自の列に配置されます。このコメントは編集インターフェイスの一部としてのみ存在するため、特定の高さまたは幅を維持する必要はありません。したがって、このコメントは、リッチテキストドキュメントが必要な高さおよび幅を維持できる一方で、320 CSSピクセル幅のビューポート内に収まるようにリフローされることが期待されます。

コメントはドキュメントのコンテンツ制作者を対象としたものであり、印刷されるものではないため、ドキュメントのテキストに沿ってコメントを表示すると、寸法固有のレイアウトの表示が変更されます。

双方向スクロールバーは、リッチテキストドキュメントからコメントの列まで水平方向にスクロールできるようにするために必要です。

最後に、ユーザーによって生成されたプレゼンテーションの作成またはレンダリングを表すインターフェイス(例えば、スライドデッキの作成または提示)は、多くの場合、コンテンツを単純にリフローすることができません。なぜなら、そうすることは、コンテンツ制作者のコンテンツのプレゼンテーションに容易に破損をもたらす可能性があるからです。

その代わりに、そのようなインターフェイスは、この達成基準の要件を満たす代替プレゼンテーションを作成する手段をコンテンツ制作者に提供することが期待されます。

なぜ明確に320 pxと256 pxなのですか？

コンテンツを垂直方向にスクロールするための320 CSSピクセルという値は、コンテンツ制作者が達成できる妥当な最小サイズとして選択されました。この値は、この基準が最初に起草されたときに利用可能であった一般的なモバイルデバイスの小さなディスプレイの報告されたビューポート幅と一致しました。320 CSSピクセルは、通常、デスクトップブラウザーのウィンドウ幅を1280ピクセルに設定し、ブラウザーのビューポートを400%にズームした場合に相当します。400 ％は領域ではなく次元に適用されることに注意すべきです。これは、デフォルトのズームレベルのビューポート幅の4倍とデフォルトのズームレベルの高さの4倍を意味します。

小さいスクリーンのデバイスは近づけ、大きなスクリーンのデバイスは遠ざけて、網膜上に同じ像を映すための視距離によって必要とされる文字の大きさを示す図。

図 16 異なる解像度の異なるディスプレイ上の同じ CSS ピクセルサイズの文字

何かを読む際に、表示の大きさは目の網膜に映し出される像ほどは重要ではありません。携帯電話機は近くで見るように設計され、デスクトップは離れてみるよう設計されています。結果として、携帯電話機の 16px 表示はデスクトップの 16px 表示より物理的に小さくなります。どちらの印刷サイズも、意図した距離で見た場合、網膜上に同じ画像を投影するため、これは通常は問題になりません。ウェブで使用されるpx単位であるCSS参照ピクセルは、これを反映しています。CSS基準単位は角度の寸法(1.278分角)であり、長さの寸法ではありません。ほとんどの高齢者およびロービジョンの人は、通常よりも携帯電話を近くに持っていますが、繰り返しになりますが、CSS参照ピクセルを使用することで、開発者(ならびにデザイナーおよびコンテンツ制作者)はデザイン選択のための安定した指標を得ることができます。

ビューポートと解像度の不一致の確認

技術が進化し、ユーザーと技術との対話が進化するにつれて、リフローに従うことは、この達成基準のサイズ要件にきちんと適合する特定の解像度またはブラウザーのズームレベルがあるかどうかということではなく、コンテンツのセクションをこれらのサイズ要件と同等のビューポートに表示することができることです。例えば、ブラウザーウィンドウをディスプレイの半分にドッキングさせている場合、ビューポートの幅は960 CSSピクセルになる。ユーザーはブラウザーを300%ズームして、320 CSSピクセル幅のビューポートを実現できます。

さらに、リフローの恩恵を受けることができるすべてのユーザーが、リフローのサイズ要件のいずれかにきちんとズームする画面解像度でウェブページを表示しているわけではありません。むしろ、オペレーティングシステムの表示解像度とブラウザーのビューポートのサイズは、通常は一致しません。例えば、デスクトップコンピューターのディスプレイ解像度を1280×1024ピクセルに設定した場合、ブラウザーのビューポートはこれらの寸法よりも小さくなります。これは、オペレーティングシステムとブラウザーのUIが利用可能な画面領域を損なうためです。一部のオペレーティングシステムでは、ズームレベルに関係なく、320または256 CSSピクセル寸法に適切にスケールするディスプレイ解像度さえ提供されない場合があります。

WAI How to Meet WCAGクイックリファレンスウェブサイト。1280 x 1024ピクセルの解像度のディスプレイで400%のズームを行うと、ブラウザのビューポートには318 x 236ピクセルしか表示されません

図 17 1280×1024ピクセルの解像度でラップトップに表示されたブラウザーウィンドウ。ウェブページは400%に拡大されています。しかし、オペレーティングシステムのタスクバーが自動非表示に設定され、ブラウザーUIが最小限に抑えられていても、ビューポートは、この違いを理解していない人が最初に信じていたものよりも小さくなります。ブラウザーがページの垂直スクロールバーを表示する必要があるため、ビューポートの幅は318ピクセルです。ブラウザーのタブとアドレスバーUIが垂直方向のスペースを占有するため、ビューポートの高さは236ピクセルになります。

すべてのユーザーエージェントがこの達成基準の標準的なサイジング要件をサポートするわけではない

リフローをサポートできるようにする上で重要な要素は、ユーザーエージェントが、ウィンドウ自体のサイズではないにしても、コンテンツの特定のウィンドウ内でコンテンツを調整できるようにすることです。リフローが最初に起草されたとき、ほとんどのモバイルオペレーティングシステムのブラウザーは、従来のデスクトップブラウザーとは異なる方法でコンテンツのズームとリフローを処理していました。たとえば、ウェブページのコンテンツは、モバイルデバイスの向きが変わった場合にのみリフローできました。これは、当時の多くのモバイルブラウザーにとって、ウェブページのズームは拡大機能に近かったからです。「ピンチズーム」ジェスチャーまたはダブルタップで拡大すると、ウェブページのコンテンツが拡大され、ユーザーはウェブページをスワイプしたりドラッグしたりして、拡大された画面でその一部を見ることができます。

最近では、モバイルデバイスまたはその他のデバイスで、ユーザーが固定された寸法(例えば、全画面、分割画面)でアプリケーションを開くことができるようにするブラウザーが増えており、従来のデスクトップブラウザーのズームとより一致したスケーリング機能が可能になっています。あるいは、これらのデバイスは、OSレベルでズーム機能を組み込んでおり、ウェブページのコンテンツの少なくともあるレベルのリフローを可能にすることができます。しかし、これらの機能の多くは、通常、固定寸法のブラウザーのビューポートを、コンテンツを垂直方向にスクロールする場合は320 CSSピクセル幅に、水平方向にスクロールする場合は256 CSSピクセル高さに調整しません。

この基準で使用されている320 CSSピクセルまたは256 CSSピクセルのサイズに固定寸法のブラウザーのサイズを変更できないことは、ユーザーエージェントのサポートの問題であると考えられますが、コンテンツを表示するためにデバイスがこれらの特定のサイズをサポートする必要があることを義務付けることは、この基準の意図ではなく、また、コンテンツが特定のデバイス上でそのようなサイズ内で表示できない場合に、ウェブページがリフローに合格または不合格になると想定することもありません。この基準のサイズ要件を正確にテストできるデバイスでウェブページを表示できる場合、ウェブページがリフローを満たす能力があるかどうかを判断するのに最適なのはそのようなデバイスです。

他の達成基準との重なり

リフローのウェブページを調べると、他のWCAGの達成基準に関連する問題が発見される可能性があります。次は、他の達成基準との潜在的な重複の例ですが、すべての重複する達成基準が言及されているわけではありません。

テキストのサイズ変更

リフローの達成基準の目的は、ユーザーがウェブページのサイズを変更したり、拡大したりできるようにすることです。これにより、コンテンツのセクション内のテキストを2方向にスクロールせずに読むことができます。達成基準 1.4.4 テキストのサイズ変更は、リフローを同時に満たしながら、すべてのテキストのサイズを少なくとも200%に増加させることが可能であるはずなので、この目標と重なっています。

注記

ウェブページを200%拡大した結果、ビューポートがリフローのサイズ要件よりも小さくなった場合、2次元スクロールが発生する可能性があります。ビューポートのサイズがリフローで必要とされるサイズよりも小さくなるため、これはリフローの失敗ではありません。

多くのウェブページでは、ブラウザーの倍率が増加するにつれてページのテキストが拡大し続けると予想されるため、ユーザはテキストを最大(およびそれ以上)400%まで拡大することができます。人々がズームインしてもテキストのサイズが一貫して増加しない実装(小さな画面の使用に適応するためにメディアクエリーに基づいて変換される場合など)では、テキストのサイズ変更の基準を満たすために200%の拡大が可能である必要があります。リフローの意図は一般にテキストの拡大をもたらしますが、リフローは特にテキストサイズの拡大を達成することを要求しないことに留意することが重要です。一部のテキストが大きくなりすぎないようにして、不要な2次元スクロールの可能性を軽減する必要がある場合もあります。

例えば、既定のブラウザー設定である100%ズームで、ウィンドウの幅が1280 CSSピクセルのときにテキストが20 pxに設定されている場合、200%ズームでは2倍のサイズで表示されます。400%ズームした後、ページは320 CSSピクセルのビューポート内に収まるようにリフローされます。コンテンツ制作者は、ページのテキストサイズを10 pxに設定することを決定できます。テキストはCSSピクセルで元のサイズの半分になりましたが、400%に拡大されたため、デフォルトのブラウザー設定である100%ズームと比較して2倍のサイズで表示されます。特定のブレークポイント内でテキストを200%拡大する必要はありませんが(ズームによって新しいブレークポイントのバリエーションがアクティブになる可能性があるため)、デフォルトの100%ズームと比較して、何らかの方法で200%のテキスト拡大が可能である必要があります。

達成基準 2.4.11 隠されないフォーカス (最低限)

コンテンツのセクションがより大きなビューポートサイズで固定位置または「スティッキー」になるように設計されている場合、コンテンツ制作者は、このようなスティッキーコンテンツがユーザーのキーボードフォーカスを持つ要素を完全に隠れないようにする必要があります。または、コンテンツ制作者が作成したコンテンツがコンテンツを隠す場合、ユーザーがキーボードフォーカスを進めることなく隠されないコンテンツを退ける方法があります。このようなスティッキーなコンテンツや固定されたコンテンツは、キーボードのフォーカスを隠すだけでなく、コンテンツを読むことを不可能ではないにしても困難にする可能性があるため、リフローの恩恵を受ける人にとって重大な問題を引き起こす可能性があります。

例えば、ウェブサイトのコンテンツは、320 CSSピクセル幅のビューポート内に収まるように適切にリフローされます。ウェブサイトには固定位置の広告も表示されます。広告は、大きなビューポートでレンダリングされると、ウェブページの下の隅に表示されることがよくあります。しかし、ページを拡大しようとすると、広告は固定位置に残ります。それら広告は、ページのフォーカス可能な要素を隠すだけでなく、閉じるボタンを探したり、キーボードでナビゲートしたりしないと広告を閉じることができないだけでなく、読むために利用可能なスペースを著しく減少させます。

中世の歴史に関する音楽史ウェブサイトのセクション。固定位置の広告は、コンテンツの大部分を妨害する。

図 18 固定位置の広告は、キーボードフォーカスを持つハイパーリンクを妨害するだけでなく、ウェブページのコンテンツを読むために利用可能なスペースを著しく制限します。

スティッキー広告が表示されなくなった同じ音楽履歴ウェブページはスティッキーではなくなり、ページのコンテンツがカバーされなくなります。ハイパーリンク「音楽の中世」は、テキストの段落内に表示されます。

図 19 広告の配置を静的にすると、ウェブページのリフローされたコンテンツを読み取ることができ、ページをスクロールしても広告(このスクリーンショットには表示されていません)を表示できます。

注記

このスティッキー広告の例を超えて、一般に、ツールバー、メニューバー、ナビゲーション、および他の「サイドバー」コンテンツは、より大きなビューポートサイズでスティッキーまたは固定位置で提示される場合があります。より小さなビューポートサイズでは、このようなコンポーネントを静的な位置決めを持つように修正するか、ユーザーが表示を切り替えることができるようにすることを強く勧めます。これにより、スティッキーコンポーネントがウェブページのコンテンツの表示を妨げることがなくなるため、ズームインされたコンテンツをユーザーが確実に読むことができます。

事例

  • レスポンシブデザインにおける 1 カラム表示

    ズーム率があがると、ナビゲーションが最初に変更されて 「More」 ドロップダウンメニューの背後にあるオプションが非表示になることに注意します。ズームを続けると、ほとんどのナビゲーションオプションは 「ハンバーガー」 メニューボタンの後ろになります。全ての情報及び機能はまだこのウェブページで利用可能です。横スクロールもありません。

  • リフローを提供する PDF

    PDF/Universal Accessibility (ISO 14289) に適合する形で作成された PDF では、ロービジョンの人でも読めるように、コンテンツをリフロー及び拡大することができます。

  • コンテンツの切り詰めに代わる表示方法

    ウェブページには、スペースを節約するために切り詰められた長いテキスト文字列が表示されます。例えば、インタフェースの設計に割り当てられたスペースに収まらないユーザー生成コンテンツや、ラップされない認証キーなど。コンテンツは切り詰められたものとして提示されますが、コンテンツが切り詰められることなく完全に見えるウェブページへのリンクが提供される、または切り詰められたコンテンツを明らかにするためのメカニズムがウェブページ上に提供されます。

  • 意味を伝える書式設定されたテキスト

    レイアウトが特定の意味を持つテキストの表示(Pythonのコードインデント、2つの例としての「アスキーアート」など)は、レイアウトが正しく表示されないと意味を失います。この達成基準は、その意味が失われる場合には適用されません。ただし、これは、意味を失うことなくテキストの折り返しを適用できるテキストの他のほとんどのインスタンスには当てはまりません。さらに、意味を伝えるインデントのインスタンスでは、ズームインレベルでインデントのサイズを小さくすることを検討してください。テキストが大きくなるにつれて、インデント幅が小さくなっても目立つことがあります。

関連リソース

リソースは、情報提供のみを目的としており、推奨を意味するものではありません。

テクニック

Each numbered item in this section represents a technique or combination of techniques that the Accessibility Guidelines Working Group deems sufficient for meeting this Success Criterion. A technique may go beyond the minimum requirement of the criterion. There may be other ways of meeting the criterion not covered by these techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.

十分なテクニック

参考テクニック

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

失敗例

The following are common mistakes that are considered failures of this Success Criterion by the Accessibility Guidelines Working Group.

重要な用語

assistive technology

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents

Note 1

Functionality provided by assistive technology includes alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).

Note 2

Assistive technologies often communicate data and messages with mainstream user agents by using and monitoring APIs.

Note 3

The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality to assistive technologies like retrieving web content from program objects or parsing markup into identifiable bundles.

CSS pixel

visual angle of about 0.0213 degrees

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. This unit is density-independent, and distinct from actual hardware pixels present in a display. User agents and operating systems should ensure that a CSS pixel is set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [css3-values], which takes into account the physical dimensions of the display and the assumed viewing distance (factors that cannot be determined by content authors).

user agent

any software that retrieves and presents web content for users

viewport

object in which the user agent presents content

Note 1

The user agent presents content through one or more viewports. Viewports include windows, frames, loudspeakers, and virtual magnifying glasses. A viewport may contain another viewport (e.g., nested frames). Interface components created by the user agent such as prompts, menus, and alerts are not viewports.

Note 2

This definition is based on User Agent Accessibility Guidelines 1.0 Glossary [UAAG10].

テストルール

The following are Test Rules for certain aspects of this Success Criterion. It is not necessary to use these particular Test Rules to check for conformance with WCAG, but they are defined and approved test methods. For information on using Test Rules, see Understanding Test Rules for WCAG Success Criteria.

Back to Top