テキストのサイズ変更:
達成基準 1.4.4 を理解する
この達成基準の意図
この達成基準の意図は、軽度の視覚障害のある利用者が、例えば画面拡大ソフトのような支援技術を使わずにそのまま読むことができるように、テキストベースのコントロールを含む視覚的に描画されるテキスト（ [ASCIIのようにデータとしての属性を持ち続ける文字ではなく] 視覚的に見ることができるように表示された文字）を問題なく拡大可能にすることである。利用者がメリットを享受できるのは、ウェブページ上のすべてのコンテンツを拡大できることだが、テキストが最も重要な意味を持つ。
コンテンツを拡大縮小することは、第一にユーザーエージェントが果たすべき役割である。UAAG 1.0 チェックポイント 4.1を満たしているユーザーエージェントは、利用者がテキストの拡大及び縮小を設定できるようにしている。コンテンツ制作者が果たすべき役割は、ユーザーエージェントがコンテンツを効果的に拡大縮小できるように、ウェブコンテンツを制作することである。コンテンツ制作者は、コンテンツがユーザーエージェントによるテキストベースのコントロールを含むテキストのサイズ変更を妨げていないことを確認すること、又はテキストのサイズ変更あるいはレイアウトの変更を直接可能にすることによって、この達成基準を満たすことができる。一つの例は、様々なスタイルシートを適用することができるサーバーサイドのスクリプトによって直接可能にすることができるかもしれない。
利用者がユーザーエージェントの拡大縮小機能を使用できない場合、コンテンツ制作者は、HTML コンテンツでこの達成基準を満たすのにユーザーエージェントに依存することはできない。例えば、利用者が IE 6 又は Firefox を使用する必要のある環境で仕事をしている場合などである。
ユーザーエージェントが拡大縮小機能を提供していないウェブコンテンツ技術をコンテンツ制作者が使用している場合、拡大縮小機能を直接提供すること、又はユーザーエージェントの提供する機能と連携するコンテンツを提供することが、コンテンツ制作者の果たすべき役割である。ユーザーエージェントが拡大縮小機能を提供していなくても利用者がテキストの大きさを変更できる場合、テキストの大きさを変更してもコンテンツが利用できる状態のままであるようにすることが、コンテンツ制作者の果たすべき役割となる。
ラベルとしての機能を有し、コンテンツにアクセスするために利用者が起動する必要のあるユーザーインタフェース要素の中には、そのラベルのコンテンツに対応するには幅が十分でないものがある。例えば、ウェブメールのアプリケーションにおいて、考えられうる件名すべてに対応できるほど件名欄の幅が広くないことがある。しかし、件名の見出しを起動することで、利用者は件名見出しとメッセージが全部表示された状態にすることができる。また、ウェブベースの表計算ソフトでは、セルの内容が長すぎて欄の中に表示できない場合には省略され、そのセルの内容の全部は、そのセルがフォーカスを受け取ったときに利用者に提供される。ユーザーインタフェース要素のコンテンツも、利用者が欄の幅を変更できる場合には、ユーザーインタフェース要素の幅よりも広くなってしまうことがある。この種のユーザーインタフェース要素では、行の折り返しは必須ではない。ユーザーインタフェース要素がフォーカスを受け取った時、又は利用者がユーザーインタフェース要素を起動した後にすべてのコンテンツが入手可能になり、この情報はアクセス可能であるということが何らかの方法で利用者に提示されている場合には、省略は許容される。
コンテンツが200％まで、言い換えれば、幅と高さが2倍になるまで、拡大可能であれば、そのコンテンツはこの達成基準を満たしていることになる。コンテンツ制作者はそれ以上の拡大をサポートしてもよいが、コンテンツをそれ以上拡大していくにつれて、アダプティブ・レイアウトはユーザビリティの問題を引き起こす可能性がある。例えば、語句の横幅が広くなりすぎると、省略されてしまうことになる。レイアウト上の制約によって、拡大していったときに、テキストが他のコンテンツと重なり合ってしまうこともある。あるいは、文章中の一つの単語だけが各行にある状態になると、その文章が縦に表示されてしまって読みづらくなってしまう。
WCAGワーキンググループは、広範囲に及ぶデザイン及びレイアウトをサポートできるという点と、最小の拡大率が200％である古い画面拡大ソフトを補完するという点から、200％が妥当ではないかと考えている。200％を超えると、拡大（テキスト、画像、及びレイアウト領域のサイズを変更し、横スクロールと縦スクロールを必要とする可能性のある大きなキャンバスを作り出す）のほうが、テキストのサイズ変更よりも効果的かもしれない。200％を超える状況では、拡大機能専用の支援技術が通常は使用されており、コンテンツ制作者が利用者に直接提供する機能よりもより良いアクセシビリティを提供することができる。
注記： 画像化された文字は、画素に分解されてしまうので、テキストと同じように拡大できない。そのため、可能な限り、テキストを用いることを勧める。また、画像化された文字の前景と背景のコントラスト及び色の組合せを変更することを必要とする利用者もいるが、テキストよりも困難である。
達成基準 1.4.8 視覚的な表現を理解するも参照のこと。
達成基準 1.4.4 の具体的なメリット
この達成基準により、テキストのサイズを変更できるようにすることで、ロービジョンの利用者がコンテンツのテキストを読むことができるようになる。
達成基準1.4.4 の事例
視覚障害のある利用者が、ウェブページのテキストの大きさをブラウザで 1 em から 1.2 em に変更している。その利用者は小さいテキストを読むことはできないが、大きいテキストは読むことができる。テキストの大きさが大きくなっても、ページ上のすべての情報は表示されている。
ページを拡大縮小するためのコントロールがウェブページにある。異なる設定を選択すると、そのサイズで最適なデザインとなるようにページのレイアウトが変更される。
利用者が、ユーザーエージェントの拡大縮小機能を使って、コンテンツのサイズを変更している。すべてのコンテンツは均一に拡大し、必要に応じてユーザーエージェントがスクロールバーを提供している。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準1.4.4 の実装方法及び不適合事例 - テキストのサイズ変更
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされている場合にのみ、次に挙げる実装方法により、この達成基準を満たすことができる。
達成基準を満たすことのできる実装方法
テキストのサイズを変更した際に、テキスト・コンテナもサイズ変更するようにする、かつ、次の実装方法の一つ以上を用いて、コンテンツにあるその他の大きさと相対的な大きさにする
相対的な大きさの実装方法：
テキスト・コンテナのサイズを可変にする実装方法：
G178: 利用者がウェブページ上のすべてのテキストを200％まで徐々に変更できるコントロールをウェブページ上で提供する
G179: 文字サイズを変更しても、テキストコンテナのサイズが変更されない際に、コンテンツ又は機能が損なわれないようにする
達成基準 1.4.4 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能、または効果的であるとは限らない。
デフォルトで大きなフォントを提供する（リンク追加予定）
ページ比率のコンテナーサイズを用いる（リンク追加予定）
ユーザーエージェントのデフォルトよりも小さなサイズのフォント尺度を使わない（リンク追加予定）
注記： コンテンツ制作者は本当のフォントサイズを知ることはできないが、100%よりも小さな値の尺度を避けるべきである
両端揃えは避ける（リンク追加予定）
十分なスペースを持った行間を提供する（リンク追加予定）
アクセシブルな選択肢が提供できない場合、非テキストコンテンツは異なるサイズを提供する（リンク追加予定）
ビットマップ（ラスター画像）の文字の利用を避ける（リンク追加予定）
画像化された文字のサイズ変更にサーバーサイトスクリプトを用いる（リンク追加予定）
少なくとも18ポイント以上のビットマップ（ラスター画像）の文字を保証する（リンク追加予定）
文字サイズを50％に縮小する（リンク追加予定）
C20: カラム幅に相対サイズを用いて、ブラウザの画面サイズを変更しても各行の文字数が平均80字（日本語は40字）以下を維持できるようにする (CSS)
拡大するメカニズムをもつキャプションを提供する（リンク追加予定）
達成基準 1.4.4 のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準 1.4.4 に適合していないとみなした、よくある不適合事例である。
重要な用語
- キャプション
そのメディアのコンテンツを理解するのに必要な、会話及び会話でない音声情報の両方に対する、同期した視覚的表現又は代替テキスト。
注記 1： キャプションは発話のみの字幕と似ているが、次の点において異なる。すなわち、キャプションは、発話コンテンツだけでなく、その番組の内容を理解するために必要となる、発話ではない音声情報と等価な内容も伝える。つまり、効果音、音楽、笑い声、話者の特定、位置なども含まれる。
注記 2： クローズド・キャプションは、プレーヤーによっては表示／非表示を切り替えることのできる等価物である。
注記 3： オープン・キャプションは、非表示にすることのできないキャプションである。例えば、キャプションが映像に埋め込まれた、視覚的に等価な画像化された文字である場合がある。
注記 4： キャプションは、映像の伝えている情報を分かりにくくしたり遮ったりすべきではない。
注記 5： 国によっては、キャプションはサブタイトル（字幕）と呼ばれている。
注記 6： 音声ガイドは既に視覚的に提示されている情報の説明なので、キャプションにしてもよいが、そうする必要があるわけではない。
- テキスト
- 画像化された文字
特定の視覚的効果を得るために非テキスト形式（例えば、画像）でレンダリングされたテキスト。
注記： これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。
事例 ： 写真に写っている人の名札にある人名は含まれない。
- （この文書で用いられている）支援技術
ユーザエージェントとして機能する、又は主流のユーザエージェントと一緒に機能するハードウェア及び/あるいはソフトウェアで、主流のユーザエージェントで提供されている機能以上の機能を、障害のある利用者の要求を満たすために提供するもの。
注記 1： 支援技術が提供する機能としては、代替のプレゼンテーション（例：合成音声や拡大表示したコンテンツ）、代替入力手法（例：音声認識）、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換（例：テーブルをよりアクセシブルにするもの）などを挙げることができる。
注記 2： 支援技術は、API を用いて監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
注記 3： 主流のユーザエージェントと支援技術とを区別するのに、絶対的な基準などはない。多くの主流のユーザエージェントは、障害者を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者のニーズにより特化した適切なものである。主流のユーザエージェントは、プログラムのオブジェクトからウェブコンテンツを取り出したり、マークアップを識別可能な構造に解釈したりするような、重要な機能を支援技術に対して提供する場合がある。
事例 ： この文書の文脈において重要な支援技術としては、以下のものが挙げられる：
画面拡大ソフトおよびその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、および読書困難などの障害のある人が、レンダリング後のテキストおよび画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
音声変換ソフトウェア。認知障害、言語障害、および学習障害のある人が、テキストを合成音声に変換するために使用している。
音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
代替キーボード。特定の身体障害のある人がキーボードを擬似操作するのに使用している（ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、およびその他の特別な入力デバイスを使った代替キーボードを含む）。
代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンを擬似操作するのに使用している。