判別可能のガイドライン

1.4.1 色の使用 (レベル A)

色の違いだけで情報を伝えない

作成日: 2024.4.10 / 最終修正日: 2026.3.26

この達成基準は、情報や指示、操作の反応などを伝える際に、「色」だけを区別の手段としないことを目的としています。特定の色が区別しにくい利用者や、画面の色設定を変更している利用者でも、重要な情報を見分けられるように、色以外の視覚的な手がかりを併用します。

実践すべきこと

色以外の手段の併用

• 情報伝達や状態の表示に色を用いる場合は、「テキスト」「記号・アイコン」「下線や太字」「模様（パターン）」などの色以外の方法もあわせて提供する。

運用者への注意

テキストによる明確な案内

• 入力フォームで「赤い枠の項目は必須です」や「緑色のボタンを押してください」のように、色だけに依存した説明文を書かない。「必須アイコンのある項目」「『送信』と書かれた緑色のボタン」のようにテキストによる補足を加える。

グラフやチャートの工夫

• 円グラフや折れ線グラフを色分けだけで表現すると、似た明るさの色が判別できなくなる。線の種類（実線、点線）を変えたり、グラフの領域に直接文字（ラベル）を引き出したりして区別できるようにする。

開発者への注意

リンクの視覚的表現

• 本文中のテキストリンクを「文字色」だけで区別しない。リンクには下線を引くか、周囲のテキストと十分な明暗差（コントラスト比 3:1 以上）を持たせた上で、ホバー時などに下線が表示されるように実装する。

エラー状態の提示

• 入力エラーが発生した際、入力欄の枠線を赤くするだけでなく、エラーアイコン（⚠️など）を表示したり、具体的なエラーメッセージ（「メールアドレスを入力してください」）をテキストで明記する。

今のWeb環境で気をつけたい点

• ダークモードによる色の変化：利用者がOSをダークモードに設定していると、サイト上の色が自動的に反転・調整されることがある。色の違いだけで意味を持たせていると、その意味が失われたり、誤って伝わったりするリスクが高まる。
• カラーユニバーサルデザイン（CUD）の意識：デザインを作成する段階から、シミュレーターツール（Adobe Illustratorの色の見え方シミュレーションや、ブラウザのデベロッパーツールなど）を用いて、白黒や特定の色が区別しにくい状態でどのように見えるかをチェックする習慣をつけることが重要である。

参考リンク

解説書 達成基準 1.4.1: 色の使用

1.4.2 音声の制御 (レベル A)

自動再生される音声は、一時停止や音量調整ができるようにする

作成日: 2024.4.10 / 最終修正日: 2026.3.26

この達成基準は、ページを開いた瞬間に音声が再生されることで、スクリーンリーダー（音声読み上げソフト）の音声がかき消され、利用者が操作できなくなる事態を防ぐことを目的としています。また、音に敏感な人や、集中力を妨げられやすい人にとっても重要な基準です。

実践すべきこと

自動再生の制限と制御の提供

• ウェブページを開いたときに、音声（動画の音声やBGMなど）が自動的に再生されないようにする。
• どうしても自動再生させる場合、その音声が「3秒」より長く続くなら、利用者がそのページ上で音声を「一時停止」「停止」または「ミュート（消音）」できるボタンをページの先頭付近に配置する。

運用者への注意

動画埋め込み時の設定

• YouTubeなどの動画をページに埋め込む際、自動再生の設定（autoplay属性など）をオンにしない運用を徹底する。
• 背景で動画をループ再生（ヒーロー動画など）させる場合は、音声をミュート（muted属性）にしておく。

システム音量との独立

• サイト上の音量を調整・停止する機能は、端末の「システム全体の音量」とは独立して操作できる必要がある。（システム音量を下げると、スクリーンリーダーの音量も下がってしまい意味がないため）

開発者への注意

HTMLの標準属性の利用

• 動画や音声を配置する際は、video や audio 要素を使用し、controls 属性を付与して標準の再生・停止ボタンを利用者が操作できるようにする。

キーボード操作の確保

• 独自デザインの「ミュートボタン」や「一時停止ボタン」を実装する場合は、ポインタ操作だけでなくキーボード（TabキーやEnterキー）でも操作できるように実装する。

今のWeb環境で気をつけたい点

• ブラウザの自動再生ブロック機能：現在、多くのモダンブラウザ（ChromeやSafariなど）は、利用者の操作なしに音声を自動再生することをデフォルトでブロックしている。しかし、利用者の設定次第では再生されてしまうため、「ブラウザが止めてくれるから大丈夫」と考えるのではなく、サイト側で自動再生しない（またはミュートにしておく）実装を行うことが有効である。
• 広告やウィジェット：外部から読み込んでいるバナー広告やチャットウィジェットが、予期せず音声を再生してしまうケースがある。外部スクリプトを導入する際は、音声制御のポリシーを確認する。

参考リンク

解説書 達成基準 1.4.2: 音声の制御

1.4.3 コントラスト (最低限) (レベル AA)

テキストと背景の間に十分なコントラスト（明暗差）を確保する

作成日: 2024.4.10 / 最終修正日: 2026.3.27

この達成基準は、視力の低下などで文字が読みにくい利用者や、光の反射が多い環境（屋外など）で画面を見ている利用者でも、テキストをはっきりと読めるようにすることを目的としています。文字色と背景色の間に十分な明暗の差を持たせることで、情報の視認性を大きく向上させます。

実践すべきこと

コントラスト比の確保

• 画像化された文字も含むすべての通常のテキストと背景色の間に、最低でも「4.5:1」のコントラスト比を確保する。
• 大きなテキスト（22pt以上、または太字で18pt以上 ※Webのピクセル換算ではおおよそ24px以上、または太字で18.5px以上）の場合は、最低「3:1」のコントラスト比を確保する。
• テキストフィールドのプレースホルダー（入力のヒントとなる文字）も、読ませる必要がある情報のため「4.5:1」の対象となる。

運用者への注意

目視ではなくツールで確認する

• モニターの設定（明るさや発色）によって見え方が大きく変わるため、「自分の目には読める」という感覚に頼らず、専用のカラーコントラストチェッカー（Webツールなど）を使用して数値を測定する。

例外事項の理解

• 企業の「ロゴ（ロゴタイプ）」や、純粋な装飾目的のテキスト、写真に偶然写り込んでいる文字、現在操作できない非アクティブなボタンのテキストなどは、この基準の対象外（例外）となる。

開発者への注意

透過やグラデーション背景の計算

• CSSで透過（opacityやrgba）を使用している場合や、背景がグラデーション、または写真である場合は、テキストの背後にある「最もコントラストが低くなる部分」で基準を満たしているか確認する。
• 必要に応じて、テキストにドロップシャドウをつけたり、テキストの背景に半透明の黒帯を敷いたりして視認性を確保する。

開発ツールでの検証

• Google Chromeなどのブラウザのデベロッパーツールには、コントラスト比を自動で計算して表示する機能が備わっているため、実装時にチェックする習慣をつける。

今のWeb環境で気をつけたい点

• プレースホルダーの注意点： プレースホルダーのコントラストを 4.5:1 まで上げると、色が濃くなりすぎて「すでに入力済みの文字」と区別しにくくなることがあります。重要な説明（パスワードの文字数制限など）はプレースホルダーに頼らず、入力欄の外に常時表示するテキストとして置くとよいです。
• ダークモードの注意点： ライトモードで 4.5:1 を満たしていても、OS のダークモードでは色が沈んでコントラストが下がることがあります。ライト／ダークの両方で確認するとよいです。

参考リンク

解説書 達成基準 1.4.3: コントラスト (最低限)

1.4.4 テキストのサイズ変更 (レベル AA)

文字を200%まで拡大しても、情報が欠けずに読めるようにする

作成日: 2024.4.10 / 最終修正日: 2026.3.27

この達成基準は、文字が読みにくい利用者が、テキストを読みやすい大きさに拡大しても、画面のレイアウトが崩れて文字が読めなくなったり、ボタンが押せなくなったりしないようにするためのものです。

実践すべきこと

ブラウザ拡大機能のサポート

• ブラウザの標準機能（ズーム機能やテキスト拡大機能）を使用して、画面を200%に拡大しても、すべてのテキストが読める状態を維持する。
• 拡大した際に、文字が他の要素と重なって見えなくなったり、画面の枠外にはみ出して見切れたりして情報が失われないようにする。

運用者への注意

実際のブラウザでの定期確認

• 新規ページを作成・更新した後は、ブラウザ（ChromeやEdgeなど）の機能で「200%」にズームし、テキストが重なって読めなくなっていないか、重要なボタンが画面外に消えていないかを目視でチェックする。

開発者への注意

タッチ操作でのピンチアウト拡大の許可

• タッチ操作を想定するサイトで、HTMLの meta viewport タグに user-scalable=no や maximum-scale=1.0 を指定しない。これは利用者のズーム操作（指を広げて拡大する操作）を止めてしまうため、達成基準を満たしにくくなる。

柔軟なCSSレイアウト（固定値の回避）

• テキストを囲む枠の高さを height: 50px; のように固定値で指定すると、文字が拡大された際に入りきらずにはみ出してしまう。高さには min-height を使用するか、コンテンツに合わせて自然に伸びる設計にする。
• 文字がはみ出た際に隠してしまう overflow: hidden の不用意な使用には注意する。

今のWeb環境で気をつけたい点

• 追従ヘッダー/フッターの注意点：画面の上下に常に固定されている（stickyやfixed）ヘッダー、フッター、あるいはチャットのポップアップボタンなどは、画面を200%に拡大すると表示領域の大部分を占領してしまい、肝心の本文が全く読めなくなることがある。拡大時（または画面の縦幅が狭い時）には固定を解除するなどのレスポンシブな配慮が望ましい。
• 文字画像（バナーなど）の注意点：画像として作られた文字は、200%に拡大すると解像度が粗くなり（ジャギーが発生し）、かえって読みにくくなる場合がある。1.1.1（非テキストコンテンツ）の基準とも関連するが、可能な限りHTMLのテキスト（Webフォント等）で実装することが拡大時にも有利に働く。

参考リンク

解説書 達成基準 1.4.4: テキストのサイズ変更

1.4.5 文字画像 (レベル AA)

可能な限り、文字情報は画像ではなくテキスト（HTML）で提供する

作成日: 2024.4.10 / 最終修正日: 2026.4.26

この達成基準は、すべての利用者が文字情報に容易にアクセスできるようにすることを目的としています。文字を画像（JPGやPNGなど）にしてしまうと、利用者が文字サイズを拡大したときに画質が粗くなって読めなくなったり、自分に合った文字色・背景色に変更（高コントラストモードなど）できなくなったりします。そうした読みにくさを防ぎます。

実践すべきこと

テキストの直接提供

• 見出しやボタン、バナー内の文字などは、可能な限り画像化せず、HTMLのテキストとして記述する。
• 企業やサービスの「ロゴ（ロゴタイプ）」など、特定のデザインであることが必要なものについては、例外として文字画像の使用が認められる（その場合も1.1.1に従い代替テキストを設定する）。

運用者への注意

バナーやアイキャッチ画像の作成ルール

• キャンペーンバナー等を作成する際、画像の中に大量の説明文や注意事項を埋め込まない。画像にはメインのキャッチコピーのみを入れ、詳細な情報は画像の下にHTMLテキストで記載する。

多言語展開の考慮

• 画像化された文字は、Google翻訳などのブラウザ標準の翻訳機能で翻訳されないため、その言語を母語としない利用者に情報が届きにくくなることに注意する。

開発者への注意

CSSとWebフォントの積極的な活用

• ドロップシャドウ、グラデーション、縁取りなどの装飾は、画像を切り出すのではなく、CSS（text-shadowなど）とWebフォントを活用して実装し、テキストの可読性とアクセシビリティを維持する。

SVGの適切な扱い

• どうしても複雑なタイポグラフィが必要で画像にする場合、拡大しても画質が劣化しない SVG フォーマットを検討する。HTML のテキストで表現できるならそれを優先し、画像は最終手段とする。

今のWeb環境で気をつけたい点

• 高解像度（Retina）ディスプレイでの劣化：高精細な画面では、文字画像の解像度が低いと「ぼやけて見える」原因になり、サイト全体の品質を低く見せてしまう。CSSによるテキストであれば、解像度に合わせてきれいに表示される。
• ダークモードへの追従：文字を画像にしてしまうと、利用者がOSをダークモードに切り替えた際、文字色と背景色が自動で反転・調整されない。結果として「黒い背景に黒い文字の画像」が表示され、読めなくなることがあるため、HTMLテキストでの実装が推奨される。
• SEO（検索エンジン最適化）への悪影響：検索エンジンは画像の代替テキスト（alt）よりも、HTMLとして直接記述されたテキストの方をより文脈として重要視する傾向があるため、文字画像への依存はマーケティング上も不利になる。

参考リンク

解説書 達成基準 1.4.5: 文字画像

1.4.6 コントラスト (高度) (レベル AAA)

文字と背景の色の明暗差（コントラスト）を、さらに読みやすい「7:1」以上にする

作成日: 2024.4.10 / 最終修正日: 2026.5.27

この達成基準は、視力が低下している利用者が、画面拡大ソフトなどの特別な支援技術を使わなくてもテキストを快適に読めるようにすることを目的としています。レベルAAの「1.4.3 コントラスト (最低限)」をさらに強化したもので、通常の文字と背景色の間に「7:1」という非常に高いコントラスト比（明暗の差）を求めています。

実践すべきこと

高度なコントラスト比の確保

• 通常のテキスト： 背景色とのコントラスト比を 7:1 以上 にする。
• 大きなテキスト： （おおよそ24ピクセル以上の文字、または太字で18.5ピクセル以上の文字）背景色とのコントラスト比を 4.5:1 以上 にする。

例外事項（適用されないもの）

• 押せないボタンの文字、純粋な装飾としての文字、写真の中にたまたま写り込んでいる文字。
• 企業やサービスの「ロゴマーク」に含まれる文字。

運用者への注意

ブランドカラーとテキストカラーの切り離し

• 企業のブランドカラー（明るいブルーやオレンジなど）の背景に白文字を載せた場合、7:1という高いコントラスト比をクリアできる色は少ないです。「ボタンなどの背景色はブランドカラーを使うが、文字は濃いグレーや黒にする」「ブランドカラーをそのまま文字色として使う場合は、色を暗く調整した専用のカラーパレットを用意する」といった、デザインとアクセシビリティを両立させるためのルール作りが必要です。

開発者への注意

ツールによる確実な検証

• 見た目の感覚だけで 7:1 を判断するのは難しいです。ブラウザの開発者ツールやコントラストチェッカーツールを使用して、すべてのテキスト要素のコントラスト比を数値で正確に計測・検証しながら実装を進めるとよいです。

今のWeb環境で気をつけたい点

• レベルAAAの難易度と優先度： コントラスト比 7:1 をサイト全体の基本デザインに適用すると、使用できる色の組み合わせが制限され、ブランド独自の表現を出すことが難しくなる場合もあります。そのため、この基準は「レベルAAA」に設定されています。まずはレベルAAの「1.4.3 コントラスト (最低限)」（4.5:1）を満たすことが優先ですが、文字が読みにくい利用者が多いサイト（病院、公的機関、福祉サービスなど）や、「エラーメッセージ」などの重要なテキストに限定して適用するのは効果的です。
• ダークモードでのコントラスト： 近年普及している「ダークモード」では、真っ黒の背景に真っ白の文字（コントラスト比 21:1）を配置すると、逆にまぶしすぎて文字がにじんで見えるなど、読みにくくなる人がいます。7:1以上を確保しつつも、コントラストを極端に強めすぎないといった配慮が求められるようになっています。

参考リンク

解説書 達成基準 1.4.6: コントラスト (高度)

1.4.7 小さな背景音、又は背景音なし (レベル AAA)

音声コンテンツの背景音（BGMなど）をなくすか、話し声より十分に小さくする

作成日: 2024.4.10 / 最終修正日: 2026.5.27

この達成基準は、聴力が低下している利用者や、複数の音の中から特定の音を聞き分けるのが苦手な利用者が、音声コンテンツの「話し声」をはっきりと聞き取れるようにすることを目的としています。BGMや環境音が大きすぎると、肝心の話し声が背景音に埋もれてしまい、内容がまったく理解できなくなってしまうためです。

実践すべきこと

主音声と背景音の明確な分離

• 動画の音声トラックやポッドキャストなど、人の話し声がメインとなる収録済みの音声コンテンツにおいて、以下のいずれかを満たすようにする。
  • 背景音を入れない。
  • 利用者が背景音だけをオフにできる機能を提供する。
  • 背景音を、メインの話し声よりも少なくとも20デシベル（dB）以上小さくする（※1〜2秒間だけの短い効果音などはこれより大きくてもよい）。

運用者への注意

動画・音声制作のガイドライン化

• 動画や音声メディアを制作する際、演出の雰囲気を出すためにBGMの音量を上げすぎないよう、制作チームや外部の動画クリエイターと事前に「声とBGMの音量バランス（20dBの差）」についてのルールを共有しておく。

開発者への注意

BGMのオン・オフ機能の検討

• どうしてもBGMを大きめに流したいエンターテインメント系のコンテンツ等で、Web上のプレーヤーを独自開発する場合は、話し声のトラックとBGMのトラックを分け、利用者がボタン一つで「BGMのみをミュート（消音）」できる機能を実装することも、この基準を満たす有効な手段となります。

今のWeb環境で気をつけたい点

• レベルAAAの難易度と優先度： 映像や音声作品において「背景音を話し声より20デシベル以上小さくする」ことは、制作者の演出や臨場感を制限してしまう場合があるため、この基準は「レベルAAA」に設定されています。まずは 1.2.2（キャプション）などの文字による情報保障を満たすことが最優先ですが、ニュース動画、オンライン講義、インタビュー音声など「内容の正確な伝達」が最優先される実用的なコンテンツにおいては、この音声バランスの配慮が重要になります。
• YouTubeやポッドキャストの注意点： YouTubeや音声メディアなどで、BGMを比較的大きめに流しながら話すスタイルの配信は、複数の音を聞き分けるのが苦手な人にとっては内容を理解しにくくなる原因になります。「BGMはあくまで脇役であり、主役の声を邪魔しない」という基本設計が、アクセシビリティの観点からも求められます。

参考リンク

解説書 達成基準 1.4.7: 小さな背景音、又は背景音なし

1.4.8 視覚的提示 (レベル AAA)

利用者が色を変更でき、かつ行間や文字数などの「読みやすいレイアウト」を保てるようにする

作成日: 2024.4.10 / 最終修正日: 2026.5.27

この達成基準は、文字の読み取りに時間がかかる利用者や、文字が読みにくい利用者が、テキストを自分の読みやすい状態にカスタマイズして読めるようにすることを目的としています。文字が密集しすぎている、行が長すぎる、コントラストが強すぎる（または弱すぎる）といった「読みにくさの壁」を取り除くための、5つの具体的な条件が定められています。

実践すべきこと

視覚的カスタマイズとレイアウトの要件

• テキストのまとまりに対して、利用者が以下のすべてを実現できる仕組みを提供する。
  • 色の変更： 前景色（文字色）と背景色を利用者が自由に選択できる。
  • 1行の長さ： 1行の長さを半角80文字（日本語などの全角文字の場合は40文字）以内にする。
  • 両端揃えを避ける： テキストを「両端揃え（均等割付 / text-align: justify）」にしない（※単語の間に不規則な隙間ができ、行を追いにくくなるため）。
  • 行間と段落間： 行間（行の高さ）を1.5文字分（1.5倍）以上にし、段落と段落の間隔は、その行間のさらに1.5倍以上にする。
  • 横スクロールの防止： ウィンドウを全画面表示にした状態で、テキストを200%まで拡大しても、横スクロールせずに（折り返して）読めるようにする。

運用者への注意

「読ませる」コンテンツでの配慮

• ブログ記事、ニュース、規約ページなど、長文を読ませるページにおいて、文字がぎっしり詰まっていないか、1行が長すぎて次の行の頭を見失わないかをチェックする。

開発者への注意

CSS設計の基本方針

• 日本語のWebサイトでは、max-width を使ってテキストブロックの最大幅を制限し、1行が40文字前後になるようにレイアウトを制御する。
• line-height: 1.5;（またはそれ以上）を基本のスタイルとして設定し、段落（<p>）の下マージンをしっかりと確保する。

今のWeb環境で気をつけたい点

• レベルAAAの難易度と優先度： サイト側で文字色・背景色を選べる表示設定UIを用意したり、1行の文字数や段落間隔をすべてのページで厳密に守ったりすることは、デザインや運用への影響が大きいため、この基準は「レベルAAA」に設定されています。まずは 1.4.4（テキストのサイズ変更）や 1.4.12（テキストの間隔）といったレベルAAを満たすことが最優先ですが、長文のコラム記事や教育用コンテンツ、公的機関の規約など「じっくり読む必要のあるページ」に限定してこの基準の考え方を取り入れることは、すべての利用者にとって有益です。
• 文字色・背景色の変更について： 1.4.8では、本文などのテキストブロックについて、利用者が文字色と背景色を選べる仕組みが利用できることが求められます。ただし、これはサイト上に独自の色変更ボタンを設置するという意味ではありません。ブラウザの表示設定、利用者側のスタイルシート、リーダーモード、高コントラスト表示など、利用者側の設定が正常に働くように作ることも重要です。
• ブラウザの「リーダーモード」の活用： 現代のブラウザには、メインの文章だけを抽出し、利用者が背景色や文字サイズ、行間などを調整しやすくする「リーダーモード」が用意されている場合があります。サイト側で独自のカスタマイズ機能を開発しなくても、HTMLの <article> や <main> タグを正しく使い、見出し構造を整理しておくことで、こうした利用者側の読みやすさ調整を助けることができます。

参考リンク

解説書 達成基準 1.4.8: 視覚的提示

1.4.9 文字画像 (例外なし) (レベル AAA)

見出しやバナーなどでは、文字を画像化せずテキストで提供する

作成日: 2024.4.10 / 最終修正日: 2026.5.27

この達成基準は、文字が読みにくい利用者が、文字の色、サイズ、フォント、行間などを自分の読みやすいようにブラウザや支援技術で自由にカスタマイズできる状態を保つことを目的としています。文字が画像の一部として焼き付けられていると、利用者が文字だけを抽出してスタイルを変更することができないため、ロゴなどを除き、文字画像の利用を控えます。

実践すべきこと

文字画像を使わない方針

• 見出し、ボタン、ナビゲーションメニュー、バナー広告の中のキャッチコピーなど、情報を伝えるためのすべてのテキストを、画像ではなく「テキストデータ（HTMLのテキスト）」として提供する。
• 文字画像が許されるのは、企業やサービスの「ロゴマーク」や、文字自体に意味がなくデザインの一部となっている「純粋な装飾」の場合のみとする。

運用者への注意

バナー制作ルールの見直し

• キャンペーンバナーなどを作成する際、画像の中にキャッチコピーや説明文を焼き付けるのではなく、「背景画像」と「HTMLテキスト」を分離して構成するデザイン方針を標準ルールとして検討する。

開発者への注意

CSSとWebフォントの最大限の活用

• デザイナーが意図した影、グラデーション文字、縁取りなどのタイポグラフィや視覚効果を画像化せずに実現するため、CSS3の高度なスタイリング技術やWebフォントを積極的に活用して実装する。

今のWeb環境で気をつけたい点

• レベルAAAの難易度と優先度： キャンペーンのバナー画像やアイキャッチ画像など、Webデザインにおいて「文字を画像に配置する」表現は現在でも使われています。この基準は、そうした文字画像を控えるため、デザインの自由度や制作プロセスに与える影響が大きい場合があり「レベルAAA」に設定されています。まずは代替テキストを提供する 1.1.1（非テキストコンテンツ）や、基本を抑える 1.4.5（文字画像）を満たすことが優先ですが、画面を見ずに利用する人や、利用者が自分の環境で読みやすくカスタマイズする必要がある規約ページなどでは、この「すべてをテキストで組む」というアプローチが有効です。
• SEOとレスポンシブへの大きなメリット： AAAへの準拠を目的としなくても、「文字を画像にしない」ことは今のWeb制作においてはベストプラクティスです。小さな画面から大型モニターまで画面サイズの違いに対応しやすいため、HTMLテキストで組むことは、アクセシビリティだけでなく、SEOやマルチデバイス対応においてもメリットがあります。

参考リンク

解説書 達成基準 1.4.9: 文字画像 (例外なし)

1.4.10 リフロー (レベル AA)

400%拡大しても、縦横の両方にスクロールさせない

作成日: 2024.4.10 / 最終修正日: 2026.4.26

この達成基準は、文字が読みにくい利用者が画面を大きく拡大（400%など）した際でも、情報が画面の横幅に自動で収まり（リフローされ）、縦方向のスクロールだけで快適に読み進められることを目的としています。行の端を読むために毎回横にスクロールし、次の行を読むためにまた左に戻る、といった操作は利用者にとって非常に大きな負担となります。

実践すべきこと

一方向のみのスクロールに収める

• 横書きのコンテンツを閲覧する際、画面を拡大しても「縦方向のスクロールのみ」で情報や機能にアクセスできるようにする。（縦書きの場合は「横方向のスクロールのみ」）

レスポンシブデザインの採用

• 端末の画面幅に合わせてコンテンツの幅が自動的に調整される、レスポンシブウェブデザインを採用する。

運用者への注意

例外となるコンテンツの理解

• 「地図（Googleマップなど）」「複雑なデータテーブル（表）」「動画」「スライドショー」など、どうしても横スクロールしないと意味が通じない、または機能しないコンテンツは、この基準の例外として認められます。
• ただし、例外となる要素であっても、それ以外の本文テキストまで巻き込んで画面全体に横スクロールを発生させないように注意が必要です。

開発者への注意

固定値（px）の回避

• コンテンツを囲むコンテナ要素の幅を width: 1000px のように固定せず、max-width や %、vw などを活用して柔軟なレイアウトを実装する。

画像やテキストの制御

• 画像には max-width: 100%; height: auto; などを指定し、画面幅をはみ出さないようにする。
• 長いURLなどの連続したテキストが画面幅を超えてしまう場合は、CSSの word-break: break-word; などを指定して適切に折り返すようにする。

表（テーブル）のはみ出し対策

• 例外として認められる表（table）が画面幅を超える場合、表の親要素に overflow-x: auto; などを設定し、「表の内部だけ」が横スクロールするように実装する。

今のWeb環境で気をつけたい点

• 狭い画面への対応とリフロー：現代のWebサイトはレスポンシブ対応されていることが多いため、基本的には「ブラウザ幅を320px程度まで狭めたときに、画面全体に横スクロールバーが出なければクリア」と判断して問題ありません。
• 非表示要素による横幅の拡張：CSSアニメーションの都合などで、画面外（右側）に要素を配置している場合、それが原因で意図せぬ横スクロールが発生してしまうことがあります。不要なはみ出しは overflow-x: hidden; で適切に隠す必要があります。

参考リンク

解説書 達成基準 1.4.10: リフロー

1.4.11 非テキストのコントラスト (レベル AA)

ボタンや入力欄、重要な図解などの形がはっきりわかるようにする

作成日: 2024.4.10 / 最終修正日: 2026.4.26

この達成基準は、文字だけでなく「操作に必要な部品（ボタンや入力フォーム）」や「情報を伝える図解（グラフやアイコン）」についても、視覚的に認識しやすくすることを目的としています。部品の境界線や図形の色が背景と同化してしまうと、画面が見えにくい利用者や、屋外など光の反射が多い環境で見ている利用者が「どこを操作していいか」や「グラフの意味」を理解しにくくなります。

実践すべきこと

コントラスト比「3:1」の確保

• 操作に必要なUIコンポーネント（ボタン、入力フィールドの枠、チェックボックスなど）は、隣接する背景色との間に少なくとも「3:1」のコントラスト比を確保する。
• 情報伝達に必要なグラフィック（円グラフの色分け、折れ線グラフの線、意味のあるアイコンなど）も、隣り合う色との間に「3:1」のコントラスト比を確保する。

運用者への注意

グラフや図解の色使い

• 円グラフなどで複数の色を使う場合、隣り合う色同士のコントラスト比が足りなくなることが多い。間に白い隙間（境界線）を入れるか、色だけでなく模様（斜線やドット）を併用して区別できるようにする。

専用ツールでの確認

• テキストのコントラスト（1.4.3）と同様に、モニターの明るさや個人の見え方によって見え方が変わるため、目視ではなく専用のカラーコントラストチェッカーで数値を測定する。

開発者への注意

入力フォームの枠線と背景

• 入力フィールドの境界を示す枠線（border）や背景色が薄すぎると、入力エリアとして認識されない。背景とのコントラスト比が3:1以上になる色を指定する。

状態（ステート）の変化

• ボタンをホバーした時や、選択（focus）した時の色の変化も、変化前後の違いや背景色との間に十分なコントラストを持たせる。

今のWeb環境で気をつけたい点

• 近年のフラットデザインでは、入力欄の枠線を消して薄い背景色だけで表現したり、ボタンの境界線をなくしたりする表現が多いです。コントラストが弱いと「どこが入力できる場所か」という視覚的な手がかりが失われやすくなります。デザイン性とアクセシビリティのバランスに注意するとよいです。
• ブラウザ標準のチェックボックスやラジオボタンを CSS でカスタマイズ（独自デザインに変更）する際、枠線のコントラストが 3:1 を下回り、基準を満たさない例がよくあります。
• OS のダークモード適用時に、グラフの色や枠線が黒い背景に沈んで見えなくならないか、ライト／ダークの両方で検証するとよいです。

参考リンク

解説書 達成基準 1.4.11: 非テキストのコントラスト

1.4.12 テキストの間隔 (レベル AA)

利用者が文字の間隔や行間を広げても、情報が隠れたり崩れたりしないようにする

作成日: 2024.4.10 / 最終修正日: 2026.4.26

この達成基準は、文字の読み取りに時間がかかる利用者や、文字が読みにくい利用者が、読みやすさを向上させるためにブラウザの拡張機能などで「行間や文字間隔を広げる」設定を行っても、コンテンツの理解や機能が損なわれない（テキストが途切れたり、ボタンと重なったりしない）ようにするためのものです。

実践すべきこと

指定された間隔までの拡張に耐えるレイアウトの構築

• 利用者が以下の設定までテキストスタイルを上書き（拡張）しても、情報が欠損したり他の要素と重なったりしないように設計する。
  • 行送り（行間）：フォントサイズの 1.5倍
  • 段落に続く余白（段落間）：フォントサイズの 2倍
  • 文字間隔（字送り）：フォントサイズの 0.12倍
  • 単語間隔：フォントサイズの 0.16倍

運用者への注意

テストツールを用いた定期的な確認

• 新規ページを作成した際などは、ブラウザの拡張機能などを使用して、意図的に上記の間隔設定を適用し、テキストが枠からはみ出して隠れていないか、ボタンの文字が途切れていないかを目視でチェックする。

開発者への注意

柔軟な高さ設定（固定値の回避）

• テキストを囲む要素（ボタンやカード型のコンポーネントなど）の高さを height: 40px; のように固定しない。文字間隔が広がってテキストが複数行に折り返された際に、はみ出しや重なりが発生するため、min-height や padding を用いて、テキスト量に合わせて自然に広がるように実装する。

切り取りの回避（overflow設定）

• 長いテキストを1行に収めるための overflow: hidden; や text-overflow: ellipsis;（...で省略する手法）は、間隔を広げた際に重要な情報が見えなくなるリスクがあるため、使用箇所に注意する。

今のWeb環境で気をつけたい点

• 制作者がこの数値を事前に設定する必要はない：よくある誤解ですが、サイトのデフォルトのCSS（line-heightやletter-spacing）をこの数値に設定する基準ではありません。あくまで「利用者がこの数値に変更したときに、レイアウトが壊れないように作る」という基準です。
• モバイルアプリ風のUIでの崩れ：狭い画面向けのサイトで、アプリのように下部に固定されたタブメニューや、小さなバッジ（通知アイコン内の数字など）は、文字間隔を広げると表示崩れを起こしやすい代表的なパーツです。

参考リンク

解説書 達成基準 1.4.12: テキストの間隔

1.4.13 ホバー又はフォーカスで表示されるコンテンツ (レベル AA)

ホバーで現れる追加コンテンツを「勝手に消さない」かつ「任意で消せる」ようにする

作成日: 2024.4.10 / 最終修正日: 2026.4.26

この達成基準は、ポインタを合わせたり（ホバー）、キーボードで選択（フォーカス）したりしたときに現れる追加コンテンツ（ツールチップやドロップダウンメニューなど）が、利用者の意図に反して消えたり、逆に邪魔になって本文が読めなくなったりするのを防ぐことを目的としています。

実践すべきこと

表示されるコンテンツの3つの条件を満たす

• 非表示にできる：ポインターを移動させなくても、Escキーを押すなどの簡単な操作で追加コンテンツを消すことができる。
• ホバーできる：現れた追加コンテンツの上にポインタを移動させても、コンテンツが消えずに表示されたままになる。
• 表示を持続できる：ホバーやフォーカスを外すか、利用者が明示的に消すまで、勝手に（数秒経ったからといって）消えずに表示され続ける。

運用者への注意

そもそもホバーに依存しないUIの検討

• ホバーで情報を表示する設計は、アクセシビリティの観点でもタッチ操作の観点でもトラブルになりやすいため、可能な限り「選択（クリックやタップ）で開閉するアコーディオンやモーダル」の採用を優先的に検討する。

開発者への注意

CSSのホバー領域（隙間）の設計

• トリガーとなるボタンと、出現したツールチップの間に「隙間（マージン）」があると、ポインタをツールチップへ移動させる途中でホバーが外れ、ツールチップが消えてしまう。CSSの padding や見えない要素（疑似要素など）を使って、隙間なく移動できるように設計する。

キーボード操作（Escキー）への対応

• CSSの :hover だけでドロップダウンを実装すると、Escキーで閉じる処理などが困難になる。JavaScriptを使用して、キーボードのフォーカス制御や keydown イベント（Escapeキー）でコンテンツを非表示にする仕組みを実装する。

今のWeb環境で気をつけたい点

• メガメニューと拡大表示： ホバーで大きなメガメニューが開く UI は、画面を拡大している利用者では表示領域を大きく占有し、背面のコンテンツが操作しにくくなることがあります。Esc キーやフォーカス移動で確実に閉じられるか、拡大時の挙動を確認するとよいです。
• タッチデバイスとホバー： タッチ環境ではホバーが安定しないため、ポインタ操作のホバーだけで開閉する設計は動きにくくなることがあります。開閉は選択（クリックやタップ）で切り替える動線を用意するとよいです。

参考リンク

解説書 達成基準 1.4.13: ホバー又はフォーカスで表示されるコンテンツ

目次へ戻る