判断可能のガイドライン

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の標準属性の利用
  • 動画や音声を配置する際は、videoaudio 要素を使用し、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まで上げると、色が濃くなりすぎて「すでに入力済みの文字」と区別がつきにくくなるというUI上の問題が発生する。現代のベストプラクティスとしては、プレースホルダーに重要な説明(例:パスワードの文字数制限など)を入れず、入力欄の外側に常時表示されるテキストとして配置することが推奨される。
  • ダークモードの注意点:ライトモード(白背景)の時に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=nomaximum-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)

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

この達成基準は、すべての利用者が文字情報に容易にアクセスできるようにすることを目的としています。テキスト形式で提供される情報は、利用者のニーズに応じて拡大表示やコントラスト調整が可能であり、読み上げや異なる言語への翻訳が容易になります。

実践すべきこと

WCAG 2.0
テキストの直接提供
  • 文字情報は、可能な限りテキスト形式で提供する。

運用者への注意

定期的な確認
  • 新規ページや更新されたコンテンツにおいて、提供されるコンテンツが適切にテキスト化されているかを定期的にチェックする。
  • 必要に応じて画像テキストをテキスト形式に置き換える。

開発者への注意

CSSの利用
  • 文字の画像化を避け、装飾にはCSSを活用することで、テキストの可読性やアクセシビリティを保持する。

1.4.6 コントラスト (高度)の達成基準(レベルAAA)

WCAG 2.1 解説書

1.4.7 小さな背景音、又は背景音なしの達成基準(レベルAAA)

WCAG 2.1 解説書

1.4.8 視覚的提示の達成基準(レベルAAA)

WCAG 2.1 解説書

1.4.9 文字画像 (例外なし)の達成基準(レベルAAA)

WCAG 2.1 解説書

1.4.10 リフローの達成基準(レベルAA)

400%拡大で予期せぬスクロールを表示させない

この達成基準は、利用者がズームや異なるデバイスでコンテンツにアクセスする際に、情報や機能を損なうことなく、縦または横の一方向のスクロールだけで読み進めることができるようにすることを目的としています。
ブラウザのズーム機能を使用してコンテンツを400%まで拡大しても、一貫した読みやすさを確保します。

実践すべきこと

WCAG 2.1
レスポンシブデザインの採用
  • 画面サイズに適応するレスポンシブウェブデザインを採用する。
縦または横一方向のスクロール
  • 縦または横の一方向にのみスクロールするようにデザインする。

運用者への注意

定期的な確認
  • 新規ページや更新されたコンテンツを400%まで拡大した場合、予期せぬスクロールが発生していないかを定期的にチェックする。

開発者への注意

レスポンシブデザインの採用
  • コンテナサイズの変更に柔軟に対応できるよう、フレキシブルなレイアウトを実装する。
画像やメディアコンテンツのサイズ調整
  • 画像やメディアコンテンツはビューポートに収まるよう適切にサイズ調整する。
テキストの折り返し
  • テキストはビューポートの幅に合わせて適切に折り返すようにする。

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

重要なグラフや画像や操作に必要な要素はコントラスト比を高めて視認性を向上させる

この達成基準は、支援技術を使用しない視覚障害の利用者もテキストを読めるように、テキストとその背景との間に十分なコントラストを確保することを目的としています。
適切なコントラスト比により、光の反射が多い環境や画面の明るさが不十分な場合でも、重要な画像やコントロール要素をはっきりと識別できるようになります。

実践すべきこと

WCAG 2.1
コントラスト比の確保
  • 重要なグラフや画像、操作に必要なボタンやフォーム要素などは隣接する色との間に少なくとも3:1のコントラスト比を確保する。

運用者への注意

色設定の遵守
  • 提供された色設定を守り、利用者による独自色の使用を避けるようにする。
  • コントラスト比を確認する場合、モニターによって値が変わることがあるので専用のツールを使用して確認する。

開発者への注意

コントラスト比の測定
  • コントラスト比を確認するためには、専用のツールやチェッカーを使用し、適切なコントラストが確保されていることを確認する。

1.4.12 テキストの間隔の達成基準(レベルAA)

テキストスタイルを調整をしても表示が崩れないようにする

この達成基準は、テキストの読みやすさを向上させるために、行間、段落間、文字間、単語間の間隔などテキストスタイルを調整してもコンテンツの理解や機能を確保することを目的としています。

実践すべきこと

WCAG 2.1
適切なテキスト間隔の設定
  • 少なくとも行間はフォントサイズの1.5倍、段落間隔はフォントサイズの2倍、文字間隔はフォントサイズの0.12倍、単語間隔はフォントサイズの0.16倍に設定する。
テキスト間隔の柔軟性確保
  • 利用者がテキスト間隔を調整しても、コンテンツや機能が損なわれないようにする。

運用者への注意

定期的な確認
  • 新規ページや更新されたコンテンツのテキスト間隔を調整しても、機能が損なわれないかいないかを定期的にチェックする。

開発者への注意

テキスト間隔の設定
  • line-height(行間)、margin(段落の間隔)、letter-spacing(文字間隔)、word-spacing(単語間隔)などを適宜設定する。
テキスト間隔の調整による影響の回避
  • テキスト間隔を調整した場合、テキストは切り取られず、他のコンテンツと重ならないようにする。

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

ホバーやフォーカスによって表示されるコンテンツの表示非表示のタイミングを制御できるようにする

この達成基準は、ホバーやキーボードフォーカスと連動して現れたり消えたりする追加のコンテンツの表示非表示のタイミングを制御できるようにすることを目的としています。

実践すべきこと

WCAG 2.1
ホバーやフォーカスに連動するコンテンツの回避
  • 利用者がコンテンツを自分のペースで利用できるよう、ホバーなどに連動されるコンテンツの設計を可能な限り避ける。
表示されるコンテンツは非表示にできる
  • キーボードでも追加表示されるコンテンツを閉じることができるようにする。
表示されるコンテンツ上で移動できる
  • 追加表示されるコンテンツにもホバーできるようにする。
表示されるコンテンツの表示を持続できる
  • 追加表示されるコンテンツは意図的に非表示にするまで表示され続ける。

運用者への注意

定期的な確認
  • 新規ページや更新されたコンテンツにおいて、ホバーやフォーカスに連動するコンテンツがあるか定期的にチェックする。

開発者への注意

非表示メカニズム
  • 追加表示されるコンテンツを非表示にするメカニズム(例:Escキーによる非表示)を提供する。
トリガー要素の位置関係
  • 追加表示されるコンテンツがトリガーとなる要素に十分近く、かつ追加表示されるコンテンツ上でのホバーが可能な設計を心がける。
キーボード操作でのアクセス性
  • 追加表示されるコンテンツの表示をトリガーする要素は、キーボード操作でもアクセス可能であることを確保する。

目次へ戻る

ウェブのことで困ったら、
まずは「ましじめ」へ

何から手をつければいいか分からない段階でも大丈夫です。
北九州のホームページ制作から、「こんな仕組みは作れる?」といったご相談まで大歓迎。
専門的な技術力と自社事業の経験を活かし、課題解決の「近道」をご提案します。
まずは今の状況をお聞かせください。