WCAG 1.4.8: 視覚的提示

WCAG 1.4.8 は、読み取り、認知、または弱視の障害がある人々が、情報を失うことなく快適にコンテンツを読めるように、テキストのブロックがユーザーが制御できる方法で視覚的に提示されることを求めています。これには、前景色と背景色、行の幅、行間、テキストの配置が含まれます。

この規定が意味すること

Visual Presentation（視覚的提示）と題されたWCAG達成基準1.4.8は、知覚可能（Perceivable）という原則の下のレベルAAAに位置します。これは特にテキストのブロック、つまり単語1つやラベル、短いフレーズではなく、まとまった可読な文章に適用されます。この達成基準では、完全に適合するために同時に満たさなければならない5つの明確な要件が定められています。

第1に、前景色と背景色はユーザーが選択可能でなければなりません。ページは、両方の色を同時に指定することを避け（少なくとも一方はブラウザのデフォルトに任せる）、またはユーザーが自分の色の組み合わせを選べる仕組みを提供しなければなりません。固定された色の組み合わせを強制することは、たとえ高コントラストであっても、特定の色調を必要とするIrlen症候群や光過敏症などの状態を持つ読者にとって有害になり得ます。

第2に、テキストブロックの幅は80文字を超えてはなりません（CJK ― 中国語、日本語、韓国語 ― の文字体系では40文字）。この制限は要素の幅ではなく、レンダリングされたテキスト1行あたりの文字数で計算されます。フォントサイズが大きいために短い行しか含まない1200px幅のカラムは適合する場合がありますが、非常に小さい文字と長い連続文字列を含む狭いカラムは不適合となる可能性があります。

第3に、テキストを両端揃え（フルジャスティファイ）にしてはなりません（つまり左右両方のマージンに同時に揃えること）。両端揃えは不均一な単語間隔を生み出し、いわゆる「白い川」のような空白ができ、ディスレクシアやその他の読みの違いを持つ人にとって読みの流暢さを損ないます。左揃え（右側が不揃い）のテキストは常に許容されます。中央揃えや右揃えは短い文章であれば許容されます。

第4に、段落内の行間はフォントサイズの少なくとも1.5倍、そして段落間の間隔はフォントサイズの少なくとも2.25倍でなければなりません。これらの最小値は十分な垂直方向の余白を確保し、行を慎重に追って読む読者が行を見失ったり、隣接する行と混同したりしないようにするためのものです。

第5に、支援技術を使わずにテキストを200%まで拡大でき、かつコンテンツや機能が失われてはなりません。これはSC 1.4.4（Resize Text、レベルAA）とはやや異なり、特にテキストブロックの視覚的提示に対してこの挙動を明示的に要求している点と、スクリーン拡大ソフトやブラウザのズーム上書きに頼らず、ページ自体が拡大に適切に対応しなければならない点が異なります。

重要な公式の例外として、この要件はキャプションや文字画像には適用されません。ラスタ画像に埋め込まれたテキストはCSSでリサイズや再配色ができないため、SC 1.4.5（Images of Text）でその使用が別途推奨されていません。純粋にグラフィック要素として使われる装飾的なテキストも同様に除外されます。

適合とみなされるには、5つのサブ要件すべてを満たす必要があります。1つでも満たさない場合 ― 例えば、長い記事本文に対してtext-align: justifyを適用し、上書きの仕組みを提供しない場合 ― は、この達成基準全体の不適合となります。

なぜ重要か

テキストの視覚的提示は、標準的な印刷物や画面上の読書を苦もなく行えない読者に対して、非常に大きな影響を与えます。この達成基準の影響を最も直接受けるグループには、ディスレクシアのある人、スクリーン拡大ソフトではなくブラウザのズームに依存するロービジョンの人、Irlen症候群や暗所視感度異常のある人、読書速度や理解に影響する認知障害のある人、そして時間の経過とともに読書の快適さが低下した高齢ユーザーが含まれます。

British Dyslexia Associationによると、人口のおよそ10%が何らかの程度のディスレクシアを持ち、そのうち約4%は重度とされています。これらのユーザーにとって、両端揃えのテキストは視覚的な歪みを生み、読書をほぼ不可能にすることがあります。行の長さが長いと、行末で目が移動しなければならない距離が増え、次にどの行を読むべきか見失う可能性が高まり、この問題をさらに悪化させます。上書きできない固定の色の組み合わせは、読書を楽にすることを自ら見出した色付きオーバーレイやコントラストスキームをユーザーが適用することを妨げます。

ロービジョンのユーザー ― 世界保健機関によれば世界で約246百万人と推計される ― にとって、ページの流れの中でテキストをリサイズできることは極めて重要です。テキストを200%に拡大した際にレイアウトが崩れたり、コンテンツが切り捨てられたり、ナビゲーションが隠れてしまうと、これらのユーザーは事実上サイトの一部にアクセスできなくなります。専用のスクリーン拡大ソフトにアクセスできない場合もあれば、自分で調整したブラウザのズーム設定によるよりきめ細かな制御を好む場合もあります。

具体的なシナリオを考えてみましょう。中程度のディスレクシアがあるユーザーが、長文の調査報道記事を読むためにオンラインニュースポータルを訪れます。記事本文はtext-align: justifyを使用し、900pxのカラム（デフォルトのフォントサイズでは1行あたり約120文字）、固定のダークグレー文字／白背景の配色、行の高さは1.2です。ユーザーはブラウザをセピア背景を優先するように設定していますが、サイトのCSSが前景色と背景色の両方を上書きし、その設定を無効化しています。2段落も読まないうちに、不均一なスペーシング、過度な行の長さ、好みの色調を適用できないことが重なり、その記事は事実上読めない状態になります。これは仮想的なレアケースではなく、今日の多くの大手編集系ウェブサイトのデフォルトデザインをそのまま描写したものです。

障害のある人のアクセスにとどまらず、これらの要件はUXリサーチで認められている一般的な可読性のベストプラクティスとも重なります。行の長さ、行間・段落間のスペーシング、色の柔軟性を尊重するサイトは、読者の滞在時間が長くなり、直帰率が下がり、可読性スコアが向上する傾向があります ― これらはすべて、測定可能なSEOやエンゲージメントへの影響を持ちます。

テスト方法

ページ上のテキストブロックを特定する。記事、商品説明、利用規約、ヘルプドキュメントなど、コンテンツ量の多い代表的なページに移動します。この達成基準の対象となる、まとまった流し込みテキスト ― 段落、リスト本文、文章を含む表セル ― をすべて特定します。画像キャプションや装飾的なテキストは除外します。
色の制御を確認する。ブラウザのDevTools（F12）を開き、テキストブロックの計算済みスタイルを検査します。colorとbackground-colorの両方がページのCSSによって明示的に設定されている（ブラウザのデフォルトから継承されていない）場合、ページが代替手段 ― テーマスイッチャー、高コントラストモードのトグル、ユーザースタイルシートを有効にする手順など ― を提供しているか確認します。何もなければ、このサブ要件は不適合です。Firefoxで一時的にユーザースタイルシートを強制する（about:config → layout.css.has-selector.enabled）か、Chrome DevToolsの「Forced Colors」エミュレーションを使用して、サイトがシステムの色設定を尊重しているかどうかを観察することもできます。
行の長さを測定する。「Line Length」などのブラウザ拡張機能や、axe DevToolsパネルの「Intelligent Guided Tests」を使用して文字数をオーバーレイ表示するか、代表的な長い行の文字数を手動で数えます。あるいは、1行分のテキストをワードプロセッサに貼り付けて文字数を数えます。行が一貫して80文字（CJKでは40文字）を超え、ユーザーがカラムを狭める仕組みがない場合、このサブ要件は不適合です。
テキストの配置を確認する。DevToolsで各テキストブロックの計算済みtext-align値を確認します。長文テキストブロックに対するjustifyの値は、ユーザーが左揃えに切り替えられるトグルをページが提供していない限り、不適合です。
スペーシングの値を検証する。DevToolsでテキストブロックの計算済みline-heightを確認します。24pxのように倍率以外の単位で指定されている場合は、font-sizeの値で割ります。その結果は1.5以上でなければなりません。次に段落要素のmargin-bottom（またはmargin-top）を確認し、フォントサイズで割った値が2.25以上であることを確認します。ユーザーによる上書きを妨げる!important付きの値は、リスク要因として記録しておきます。
200%リサイズをテストする。ブラウザでズームを200%に設定します（Ctrl/Cmd +「プラス」キー、または表示 → 拡大を100%から2回）。すべてのテキストブロックについて、切り捨て、overflow: hiddenによって隠されるオーバーフロー、他の要素の背後に隠れてしまうテキスト、アクセス不能になるナビゲーションがないか確認します。必要に応じてChrome DevToolsのデバイスツールバーを使用して、ズームされたビューポートをシミュレートします。テキストコンテンツが失われる、または機能が利用できなくなる箇所があれば不適合です。
支援技術による確認。NVDAとFirefoxを使用し、ページを200%にズームして矢印キーで記事内を移動します。すべてのテキストがスクリーンリーダーによって読み上げられることを確認します（ズーム後にoverflow: hiddenで視覚的に切り捨てられたコンテンツは、視覚的には見えなくても読み上げられる場合があります ― その場合でも視覚的な不適合としてフラグ付けします）。macOSのVoiceOverとSafariでも同様にズームテストを繰り返します。これらのチェックは、ズームに伴うレイアウト変更がコンテンツをアクセシビリティツリーから除外していないことを確認するのに役立ちます。
ユーザー上書きのシミュレーション。Firefoxで、設定 → 一般 → フォントと色 → 色に移動し、「指定した色を使用する」を有効にして、カスタムの前景色と背景色を設定します。ページに戻り、サイトがこれらの選択を尊重しているか、それとも上書きしているかを確認します。色指定に!importantを使用しているサイトはユーザーの設定を上書きしてしまい、色の選択可能性サブ要件の不適合となります。

修正方法

ユーザー制御のない固定色の組み合わせ ― 不適切な例

<!-- Both color and background-color are hardcoded; user browser preferences are overridden -->
<style>
  .article-body {
    color: #1a1a1a;
    background-color: #ffffff;
    /* No theme switcher provided */
  }
</style>
<div class='article-body'>
  <p>Long-form article content goes here...</p>
</div>

ユーザー制御のない固定色の組み合わせ ― 適切な例

<!-- Uses CSS custom properties so a theme switcher or user stylesheet can override both values -->
<style>
  :root {
    --text-color: #1a1a1a;
    --bg-color: #ffffff;
  }
  [data-theme='sepia'] {
    --text-color: #3b2a1a;
    --bg-color: #f5edd6;
  }
  [data-theme='high-contrast'] {
    --text-color: #ffffff;
    --bg-color: #000000;
  }
  .article-body {
    color: var(--text-color);
    background-color: var(--bg-color);
  }
</style>
<!-- Theme switcher gives users explicit control -->
<div role='group' aria-label='Color theme'>
  <button onclick="document.documentElement.setAttribute('data-theme','default')">Default</button>
  <button onclick="document.documentElement.setAttribute('data-theme','sepia')">Sepia</button>
  <button onclick="document.documentElement.setAttribute('data-theme','high-contrast')">High Contrast</button>
</div>
<div class='article-body'>
  <p>Long-form article content goes here...</p>
</div>

過度な行の長さを伴う両端揃えテキスト ― 不適切な例

<!-- text-align: justify applied to a very wide unrestricted column -->
<style>
  .content {
    text-align: justify;
    /* No max-width constraint; lines easily exceed 80 characters */
  }
</style>
<div class='content'>
  <p>This paragraph stretches across the full width of the viewport, creating uneven word spacing that makes reading difficult for users with dyslexia or other reading differences. Each line may contain well over 100 characters.</p>
</div>

過度な行の長さを伴う両端揃えテキスト ― 適切な例

<!-- Left-aligned text with a max-width that keeps lines under 80 characters -->
<style>
  .content {
    text-align: left; /* Ragged-right prevents uneven word spacing */
    max-width: 66ch;  /* ch unit approximates character width; 66ch ≈ 80 average chars */
    line-height: 1.6; /* Exceeds the 1.5× minimum */
  }
  .content p {
    margin-bottom: 2.5em; /* 2.5× font-size exceeds the 2.25× paragraph spacing minimum */
  }
</style>
<div class='content'>
  <p>This paragraph is constrained to a comfortable reading width, uses left alignment, and has generous line and paragraph spacing — satisfying three of the five sub-requirements simultaneously.</p>
</div>

200%ズームで破綻する不十分な行間 ― 不適切な例

<!-- line-height set in pixels; does not scale with font resizing -->
<style>
  .article p {
    font-size: 16px;
    line-height: 18px; /* Only 1.125× font size — below the 1.5× requirement */
  }
</style>
<div class='article'>
  <p>When the user zooms to 200%, this text becomes 32px but line-height remains 18px, causing lines to overlap and become unreadable.</p>
</div>

200%ズームで破綻する不十分な行間 ― 適切な例

<!-- line-height as a unitless multiplier scales with any font size change -->
<style>
  .article p {
    font-size: 1rem;   /* Respects browser default font size setting */
    line-height: 1.6;  /* Unitless: always 1.6× the current font size, even when zoomed */
    margin-bottom: 2.5em; /* Scales proportionally with font size */
  }
</style>
<div class='article'>
  <p>At any zoom level or font size, this paragraph maintains correct proportional spacing because line-height is expressed as a unitless number rather than a fixed pixel value.</p>
</div>

よくある間違い

line-heightを単位なしの倍率ではなくピクセルやポイントで設定すること。ユーザーがテキストを拡大したりページをズームしたりすると、ピクセルベースのline-heightは固定されたままになり、行が重なってしまいます。スペーシングが比例して拡大するよう、1.6のような単位なしの値を常に使用してください。
長文の本文テキストにtext-align: justifyを使用し、代替手段を提供しないこと。デスクトップのデフォルトズームでは両端揃えが整然として見えても、ディスレクシアのあるユーザーにとっては不規則な単語間の隙間を生み出します。文章ブロックから両端揃えを取り除くか、ユーザー向けの配置切り替えトグルを追加してください。
max-widthを文字単位（ch）や相対単位（em）ではなくピクセルで設定すること。ピクセルベースのmax-widthは、ユーザーがブラウザのデフォルトフォントサイズを変更しても適応しません。その結果、フォントサイズが小さいときには1行が80文字を超え、大きいときには余白が無駄になる可能性があります。
bodyやarticle要素でcolorとbackground-colorの両方を!important付きで宣言すること。!importantを使用すると、ユーザースタイルシートによる色の上書きを明示的にブロックしてしまいますが、これは光過敏症やIrlen症候群のあるユーザーが読書環境をカスタマイズする主な手段です。
200%ズームでテストせずにテキストコンテナにoverflow: hiddenを頼ること。ビューポート単位や固定ピクセルでサイズ指定されたコンテナは、ユーザーがズームインしたときにテキストをクリップし、リフローさせるのではなくコンテンツを完全に隠してしまいます。
paddingだけで段落間のスペーシングを設定し、marginを使わないこと。親コンテナにoverflow: hiddenが設定されていると、下方向のpaddingは視覚的に潰れ、スペーシングがないように見えます。段落間のスペーシングにはmargin-bottomを使用する方が確実です。
段落間のスペーシングをemではなくピクセル（margin-bottom: 20px）で設定すること。line-heightと同様に、ピクセルベースの段落間スペーシングはフォントサイズの変更に追従せず、ユーザーがブラウザ設定で大きな基本フォントを選んだときに段落が詰まりがちになります。
ビューポートが狭ければ自動的に行の長さも短くなると想定すること。モバイルビューポートでは、フォントサイズが小さいと1行あたりの文字数が非常に多くなることがあります。カラム幅をピクセルで測るだけでなく、そのデバイスのデフォルトフォントサイズで1行あたりの文字数を必ず確認してください。
色の選択可能性ではなくコントラスト比だけを変える高コントラストテーマトグルを提供すること。ライトモードからダークモードに切り替えるトグルは、依然として前景色と背景色の両方を指定しています。この達成基準は、ユーザーが自分の色を選べることを求めており、プリセットの組み合わせから選ぶだけでは不十分です。プリセットにカスタムカラーピッカーを補完するか、ページがprefers-color-schemeおよびforced-colorsメディアクエリを尊重していることを確認してください。
スクロール可能なコンテナ内の長文テキストのテストを忘れること。overflow: scrollやoverflow: autoを持つ要素内のテキストブロックは、手動レビューから見落とされがちです。これらのコンテナは独自の幅制約を持ち、行の長さやズーム時の挙動がメインの文書フローとは異なる場合があります。

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

トルコの大統領通達第2025/10号は、2025年6月21日付官報第32933号で公布され、WCAG 2.1（WCAG 2.2のベストプラクティスとも強く整合）を直接参照する必須のデジタルアクセシビリティ要件を定めています。この通達は、トルコで事業を行う幅広い主体 ― あらゆるレベルの公的機関・政府機関、eコマースプラットフォーム、銀行・金融サービス提供者、病院・民間医療機関、20万以上の加入者を持つ通信事業者、旅行代理店、民間輸送会社、国民教育省に認可された私立学校 ― に対して、法的拘束力のある義務を課しています。

WCAG 1.4.8はレベルAAAの達成基準であり、通達が最低限の法的基準としてこれを義務付けているわけではありません ― 法的なベースライン要件は一般にWCAGレベルAAへの適合です。しかし、Visual PresentationのようなレベルAAAの達成基準は、トルコの組織にとって実務的にも評判上も大きな意味を持ちます。

第1に、通達の対象となる公的機関や大規模民間企業は、時間の経過とともにアクセシビリティの継続的な改善を示すことが期待されています。監査人や監督機関は、チェックボックス的な遵守を超えた真のコミットメントの指標として、AAAの達成基準を見る傾向が強まっています。特に色テーマの制御を提供し、システムの色設定を尊重し、適切なテキストスペーシングを維持するなど、1.4.8を積極的に実装している組織は、ディスレクシア、ロービジョン、光過敏症のあるユーザーからの苦情に直面する可能性が大幅に低くなります。

第2に、トルコには1.4.8の恩恵を直接受けるユーザーが相当数存在します。ディスレクシアの有病率は推定10%であり、ロービジョンのユーザーも数百万人規模と考えられます。大規模な消費者基盤にサービスを提供する銀行、通信事業者、eコマースプラットフォーム、病院などの主体は、非適合な視覚的提示によって苦労するユーザーが相当数存在することを想定すべきです。これに対処しないことは、アクセシビリティ上の障壁であると同時にビジネス上のリスクでもあります。

第3に、特に教育（国民教育省に認可された私立学校）や医療といった特定の専門サービスでは、子ども、高齢患者、認知障害のある人など脆弱な人々に提示されるコンテンツについて、基準をAAAまで引き上げるセクター固有の規制ガイダンスに直面する可能性があります。こうした文脈では、1.4.8は理想的な目標から事実上必須の要件へと変わります。

トルコ市場で最高水準のアクセシビリティを示し、規制の進化に合わせてコンプライアンス体制を将来にわたって確かなものにしたい組織は、1.4.8を「任意の改善」ではなくデザイン標準として扱うべきです。色テーマ用のCSSカスタムプロパティの実装、ch単位によるカラム幅の制約、文章ブロックからの両端揃えの排除、単位なしのline-height値の使用は、コストが低く効果が高い変更であり、幅広いユーザーに利益をもたらすとともに、トルコの規制枠組みの下で真のアクセシビリティリーダーシップを示すことにつながります。

出典と参考資料

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