Skip to content

解説書 達成基準 1.4.4:テキストのサイズ変更 (レベル AA)

要約

目標
テキストを拡大可能にする。
何をすればよいか
テキストを 2 倍の大きさにできるようにする。
なぜそれが重要か
テキストが大きくないと読めない人がいる。

意図

この達成基準の意図は、テキストベースのコントロール ([ASCII などのデータ形式であるテキスト文字に対して] 視覚的に見ることができるように表示された文字) を含む視覚的にレンダリングされたテキストを、例えば画面拡大ソフトのような支援技術を使わずに軽度の視覚障害のある人が、そのまま読むことができるように保証することである。利用者はウェブページ上のすべてのコンテンツを拡大することでメリットを得ることができるが、テキストは最も重要である。

コンテンツを拡大縮小することは、第一にユーザエージェントが果たすべき役割である。UAAG 1.0 Checkpoint 4.1 を満たしているユーザエージェントは、利用者がテキストの拡大縮小を設定できるようにしている。コンテンツ制作者の責任は、ユーザエージェントがコンテンツを効果的に拡大縮小することを妨げないウェブコンテンツを制作することである。コンテンツ制作者は、コンテンツがテキストベースのコントロールを含むテキストのサイズ変更のためのユーザエージェントのサポートを妨げていないことを確認すること、又はテキストのサイズ変更もしくはレイアウトの変更を直接サポートすることによって、この達成基準を満たすことができる。直接サポートの例は、異なるスタイルシートを割り当てるために使用できるサーバーサイドスクリプトを介したものかもしれない。

コンテンツ制作者がユーザエージェントによるズームサポートの提供がない技術を使用している場合、コンテンツ制作者は、このタイプの機能を直接提供する、又はユーザエージェントによって利用可能なこのタイプの機能と連携するコンテンツを提供する責任がある。ユーザエージェントがズーム機能を提供していないが、利用者にテキストの大きさの変更するのを許可する場合、コンテンツ制作者は、テキストの大きさを変更するときにコンテンツが利用可能なままであることを保証する責任がある。

ラベルとして機能し、コンテンツにアクセスするために利用者によるアクティベーションを必要とするユーザインタフェースコンポーネントの中には、ラベルコンテンツを収容するのに十分な幅がないものがある。例えば、ウェブメールアプリケーションにおける件名のカラムは、全ての可能性がある件名の見出しを収容するために十分な幅でなくてもよいが、件名の見出しをアクティブにすることで、利用者は、完全な件名の見出しを伴う完全なメッセージを得る。ウェブベースのスプレッドシートでは、カラム内に表示するには長すぎるセルのコンテンツは切り落とされ、そのセルの全コンテンツは、セルがフォーカスを受け取ったとき、利用者に提供される。ユーザインタフェースコンポーネントのコンテンツは、利用者がカラムの幅の大きさを変更することができるユーザインタフェースでも同様に、広くするかもしれない。このタイプのユーザインタフェースコンポーネントでは、改行が必須ではない。コンポーネントの完全なコンテンツが、フォーカスを置く又は利用者のアクティベーションの後に利用可能であり、この情報にアクセスすることができることが示され、それが切り捨てられるという事実の他にいずれかの方法で利用者へ提供される場合、切り捨ては許容される。

コンテンツが 200％ まで、言い換えれば、幅と高さが 2 倍になるまで拡大可能である場合、コンテンツは達成基準を満たしている。コンテンツ制作者はそれ以上の拡大をサポートしてもよいが、拡大が極端に大きくなると、アダプティブレイアウトはユーザビリティの問題を引き起こす可能性がある。例えば、語句自体の幅が使用可能な横幅に収まりきらないほど広くなり、切り取られることがある。レイアウト上の制約によって、拡大していったときに、テキストが他のコンテンツと重なり合ってしまうこともある。あるいは、文章中の一つの単語だけが各行にある状態になり、その文章が縦に表示されてしまって読みづらくなってしまうこともある。

WCAG ワーキンググループは、広範囲に及ぶデザイン及びレイアウトをサポートできるという点と、最小の拡大率が 200％ である古い画面拡大ソフトを補完するという点から、200％ が合理的な適応と考えている。200％ を超えると、拡大 (テキスト、画像、及びレイアウト領域のサイズを変更し、横スクロールと縦スクロールの両方を必要とする可能性のある大きなキャンバスを作り出す) のほうが、テキストのサイズ変更よりも効果的かもしれない。このような状況では、通常、拡大機能専用の支援技術が使用されており、コンテンツ制作者が利用者に直接サポートする機能よりもより良いアクセシビリティを提供することができる。

注記

文字画像は、画素に分解されてしまうので、テキストと同じように拡大できないため、可能な限りテキストを用いることを勧める。また、文字画像の前景と背景のコントラスト及び色の組み合わせを変更することを必要とする利用者もいるが、テキストよりも困難である。

1.4.8 視覚的提示も参照のこと。

利点

  • この達成基準は、コンテンツのテキストサイズを拡大して読むことができるようにすることで、ロービジョンの人に役立つ。

事例

  • 視覚障害のある利用者は、ブラウザにあるウェブページのテキストの大きさを 1 em から 1.2 em に増やしている。その利用者は、小さいテキストを読むことはできないが、大きいテキストは読むことができる。テキストに大きなフォントを使用すると、ページ上のすべての情報が表示される。
  • ウェブページは、ページの縮尺を変更するコントロールを含んでいる。異なる設定を選択すると、ページのレイアウトが変更され、その縮尺に最適なデザインが使用される。
  • 利用者は、ユーザエージェントのズーム機能を使って、コンテンツの縮尺を変更する。すべてのコンテンツは均一に拡大し、必要に応じてユーザエージェントがスクロールバーを提供している。

関連リソース

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

テクニック

この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断するテクニック、又は複数のテクニックの組み合わせを表している。しかしながら、必ずしもこれらのテクニックを用いる必要はない。その他のテクニックについての詳細は、WCAG 達成基準のテクニックを理解するの「その他のテクニック」を参照のこと。

十分なテクニック

参考テクニック

適合のために必須ではないが、コンテンツをよりアクセシブルにするために、次の追加のテクニックを検討することが望ましい。ただし、すべての状況において、すべてのテクニックが使用可能、又は効果的であるとは限らない。

失敗例

以下に挙げるものは、WCAG ワーキンググループが達成基準の失敗例とみなした、よくある間違いである。

重要な用語
ASCII アート (ASCII art)

文字又はグリフの空間的配置によって作られた図画 (典型的には、ASCII で定義されている 95 の印字可能文字から作られる)。

支援技術 (assistive technology)

障害のある利用者の要件を満たすために、主流のユーザエージェントが提供する機能を超えた機能を提供するような、ユーザエージェントとして動作する、又は主流のユーザエージェントと共に動作するハードウェア及び／又はソフトウェア。

注記

支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。

注記

支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。

注記

主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害のある個人を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。

音声 (audio)

音の再生技術。

注記

音声には、合成して作られたもの (音声合成を含む)、実世界の音を収録したもの、又はその両方が含まれる。

音声解説 (audio description)

主音声のトラックだけでは理解できない重要で視覚的な詳細を説明するために、音声トラックに追加されたナレーション。

注記

映像の音声解説は、動作、登場人物、場面の変化、画面上のテキスト、及びその他の視覚的なコンテンツに関する情報を提供する。

注記

標準的な音声解説では、ナレーションが会話の合間に挿入される。(拡張音声解説も参照。)

注記

映像情報のすべてが既存の音声ですでに提供されている場合、補足の音声解説は不要である。

注記

"video description" や "descriptive narration" とも呼ばれる。

訳注

日本語では「音声ガイド」とも呼ばれる。
キャプション (captions)

そのメディアのコンテンツを理解するのに必要な、会話及び会話でない音声情報に対する、同期した視覚、及び／又はテキストによる代替。

注記

キャプションは会話のみの字幕と似ているが、会話の内容だけを伝えるのではなく、その番組の内容を理解するために必要な効果音、音楽、笑い声、話者の特定、位置などを含む、会話でない音声情報と同等の内容も伝える点が異なる。

注記

クローズドキャプションは、音声情報と同等の内容で、プレーヤーによっては表示／非表示を切り替えることができるものを指す。

注記

オープンキャプションは、非表示にできないキャプションである。例えば、キャプションが同等の視覚化された文字画像で映像に埋め込まれている場合である。

注記

キャプションは、映像に含まれる情報を分かりにくくしたり遮ったりすべきではない。

注記

国によっては、キャプションは "subtitle" と呼ばれている。

訳注

subtitle には、「字幕」の意がある。日本では、キャプションのことを一般に字幕と呼ぶことが多い。

注記

音声解説にキャプションをつけることもできるが、つける必要はない。なぜなら、音声解説は既に視覚的に提示されている情報の説明だからである。

拡張音声解説 (extended audio description)

映像を一時停止することで追加の説明を付加するための時間を確保し、視聴覚提示に付加した音声解説。

注記

この手法は、追加の音声解説がないと映像の意味が損なわれてしまい、かつ会話又はナレーションの合間が短すぎる場合だけに用いられる。

自然言語 (human language)

人間とコミュニケーションをとるために話される、書かれる、又は (視覚的もしくは触覚的な手段で) 手話にされる言語。

注記

手話も参照。

文字画像 (image of text)

特定の視覚的効果を得るために非テキスト形式 (例えば画像) でレンダリングされたテキスト。

注記

テキスト以外の部分が重要な視覚的コンテンツである場合、画像に含まれるテキストは該当しない。

非テキストコンテンツ (non-text content)

プログラムによる解釈が可能な文字の並びではないコンテンツ、又は文字の並びが自然言語においても何をも表現していないコンテンツ。

注記

これには、 (文字による図画である) ASCII アート、顔文字、 (文字を置き換える) リートスピーク、文字を表現している画像が含まれる。

プログラムによる解釈 (programmatically determined)

支援技術を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。

手話 (sign language)

意味を伝えるために、手と腕の動き、顔の表情又は身体の姿勢の組み合わせを用いる言語。

テキスト (text)

プログラムによる解釈が可能な文字の並びで、自然言語で何かを表現しているもの。

テキストによる代替 (text alternative)

非テキストコンテンツとプログラムで関連付けられるテキスト。又は非テキストコンテンツとプログラムで関連付けられるテキストから参照されるテキスト。プログラムで関連付けられたテキストとは、その場所を、非テキストコンテンツからプログラムによる解釈が可能なテキストである。

注記

より詳細な情報は、Understanding Text Alternatives を参照。

ユーザエージェント (user agent)

ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。
映像 (video)

写真又は画像を動かす、又はシーケンス化する技術。

注記

映像は、アニメーション画像もしく実写画像、又はその両方で構成され得る。

テストルール

以下は、この達成基準の特定の側面に関するテストルールである。この特定のルールを使用して WCAG に適合しているかどうかを確認する必要はないが、これらのルールは定義され、承認されたテスト方法である。テストルールの使用については、WCAG 達成基準のテストルールを理解するを参照のこと。

Back to Top