テキストのサイズ変更:
達成基準 1.4.4 を理解する
この達成基準の意図
この達成基準の意図は、軽度の視覚障害のある利用者が、例えば画面拡大ソフトのような支援技術を使わずにそのまま読むことができるように、テキストベースのコントロールを含む視覚的に描画されるテキスト（ [ASCIIのようにデータとしての属性を持ち続ける文字ではなく] 視覚的に見ることができるように表示された文字）を問題なく拡大可能にすることである。利用者がメリットを享受できるのは、ウェブページ上のすべてのコンテンツを拡大できることだが、テキストが最も重要な意味を持つ。
コンテンツを拡大縮小することは、第一にユーザエージェントが果たすべき役割である。UAAG 1.0 チェックポイント 4.1を満たしているユーザエージェントは、利用者がテキストの拡大及び縮小を設定できるようにしている。コンテンツ制作者が果たすべき役割は、ユーザエージェントがコンテンツを効果的に拡大縮小できるように、ウェブコンテンツを制作することである。コンテンツ制作者は、コンテンツがユーザエージェントによるテキストベースのコントロールを含むテキストのサイズ変更を妨げていないことを確認すること、又はテキストのサイズ変更あるいはレイアウトの変更を直接可能にすることによって、この達成基準を満たすことができる。一つの例は、様々なスタイルシートを適用することができるサーバーサイドのスクリプトによって直接可能にすることができるかもしれない。
利用者が、拡大機能を持つユーザエージェントを利用できない場合、制作者は、HTML コンテンツに対するこの達成基準を満たすためにユーザエージェントに依存することはできない。例えば、利用者が、IE6を使用する必要のある環境で作業をしている場合である。
ユーザエージェントが拡大縮小機能を提供していないウェブコンテンツ技術をコンテンツ制作者が使用している場合、拡大縮小機能を直接提供すること、又はユーザエージェントの提供する機能と連携するコンテンツを提供することが、コンテンツ制作者の果たすべき役割である。ユーザエージェントが拡大縮小機能を提供していなくても利用者がテキストの大きさを変更できる場合、テキストの大きさを変更してもコンテンツが利用できる状態のままであるようにすることが、コンテンツ制作者の果たすべき役割となる。
ラベルとして機能し、コンテンツにアクセスするために利用者によるアクティベーションを必要とするいくつかのユーザインタフェース コンポーネントは、ラベル コンテンツを収容するのに十分な幅がない。例えば、ウェブメール アプリケーションにおける件名のカラムは、全ての実行可能な件名の見出しを収容するために十分な幅でなくてもよいが、件名の見出しをアクティブにすることで、利用者は、完全な件名の見出しを伴う完全なメッセージを得る。ウェブベースのスプレッドシートでは、カラム内に表示するには長すぎるセルのコンテンツは切り落とされ、そのセルの全コンテンツは、セルがフォーカスを受け取ったとき、利用者に提供される。ユーザインタフェース コンポーネントのコンテンツは、利用者がカラムの幅の幅を変更することができるユーザインタフェースでも同様に、広くなるかもしれない。コンポーネントの完全なコンテンツが、フォーカスを置く又は利用者のアクティベーションの後に利用可能であり、この情報にアクセスすることができることが示され、それが切り捨てられるという事実の他にいずれかの方法で利用者へ提供される場合、切り捨ては許容される。
コンテンツが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 ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
十分な達成方法
SL22: Supporting Browser Zoom in Silverlight (Silverlight)
SL23: Using A Style Switcher to Increase Font Size of Silverlight Text Elements (Silverlight)
テキストのサイズを変更した際に、テキスト・コンテナもサイズ変更するようにする、かつ、次の達成方法の一つ以上を用いて、コンテンツにあるその他の大きさと相対的な大きさにする
相対的な大きさの達成方法：
C12: フォントサイズにパーセントを使用する (CSS)
C13: フォントサイズにキーワードを使用する (CSS)
C14: フォントサイズに em 単位を使用する (CSS)
テキスト・コンテナのサイズを可変にする達成方法：
G178: 利用者がウェブページ上のすべてのテキストを 200％まで徐々に変更できるコントロールをウェブページ上で提供する
1.4.4 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
デフォルトで大きなフォントを提供する（リンク追加予定）
ページ比率のコンテナーサイズを用いる（リンク追加予定）
ユーザエージェントのデフォルトよりも小さなサイズのフォント尺度を使わない（リンク追加予定）
注記: コンテンツ制作者は本当のフォントサイズを知ることはできないが、100%よりも小さな値の尺度を避けるべきである
両端揃えは避ける（リンク追加予定）
十分なスペースを持った行間を提供する（リンク追加予定）
アクセシブルな選択肢が提供できない場合、非テキストコンテンツは異なるサイズを提供する（リンク追加予定）
ビットマップ（ラスター画像）の文字の利用を避ける（リンク追加予定）
画像化された文字のサイズ変更にサーバーサイトスクリプトを用いる（リンク追加予定）
C17: テキストを含むフォームの要素を拡大する (CSS)
少なくとも18ポイント以上のビットマップ（ラスター画像）の文字を保証する（リンク追加予定）
文字サイズを50％に縮小する（リンク追加予定）
C20: カラム幅に相対サイズを用いて、ブラウザの画面サイズを変更しても各行の文字数が平均 80 字（日本語は 40 字）以下を維持できるようにする (CSS)
拡大するメカニズムをもつキャプションを提供する（リンク追加予定）
達成基準 1.4.4 のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.4に適合していないとみなした、よくある不適合事例である。
重要な用語
- (この文書で用いられている) 支援技術 (assistive technology (as used in this document))
ユーザエージェントとして機能する、又は主流のユーザエージェントと一緒に機能するハードウェア及び/あるいはソフトウェアで、主流のユーザエージェントで提供されている機能以上の機能を、障害のある利用者の要求を満たすために提供するもの。
注記 1: 支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。
注記 2: 支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
注記 3: 主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害者を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。
事例: この文書の文脈において重要な支援技術としては、以下のものが挙げられる:
画面拡大ソフト及びその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、及び読書困難などの障害のある人が、レンダリング後のテキスト及び画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
音声変換ソフトウェア。認知障害、言語障害、及び学習障害のある人が、テキストを合成音声に変換するために使用している。
音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
代替キーボード。特定の身体障害のある人がキーボード操作をシミュレートするのに使用している (ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、及びその他の特別な入力デバイスを使った代替キーボードを含む)。
代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンの動きをシミュレートするのに使用している。
- キャプション (captions)
そのメディアのコンテンツを理解するのに必要な、会話及び会話でない音声情報に対する、同期した視覚、又はテキストによる代替。
注記 1: キャプションは会話のみの字幕と似ているが、会話の内容だけを伝えるのではなく、その番組の内容を理解するために必要な効果音、音楽、笑い声、話者の特定、位置などを含む、会話でない音声情報と同等の内容も伝える点が異なる。
注記 2: クローズドキャプションは、音声情報と同等の内容で、プレーヤーによっては表示／非表示を切り替えることができるものを指す。
注記 3: オープンキャプションは、非表示にできないキャプションである。例えば、キャプションが同等の視覚化された文字画像で映像に埋め込まれている場合である。
注記 4: キャプションは、映像に含まれる情報を分かりにくくしたり遮ったりすべきではない。
注記 5: 国によっては、キャプションは "subtitle" と呼ばれている。
訳注： subtitleには、「字幕」の意がある。日本では、キャプションのことを一般に字幕と呼ぶことが多い。
注記 6: 音声解説にキャプションをつけることもできるが、つける必要はない。なぜなら、音声解説は既に視覚的に提示されている情報の説明だからである。
- テキスト (text)
プログラムによる解釈が可能な文字の並びで、自然言語で何かを表現しているもの。
- 文字画像 (image of text)
特定の視覚的効果を得るために非テキスト形式 (例えば画像) でレンダリングされたテキスト。
注記: テキスト以外の部分が重要な視覚的コンテンツである場合、画像に含まれるテキストは該当しない。
事例: 写真に写っている人の名札にある人名。