予測可能のガイドライン

3.2.1 フォーカス時 (レベル A)

要素にフォーカスが当たっただけで、利用者の意図しないページ移動などを起こさない

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

この達成基準は、利用者がキーボードでページ内を移動し、ある要素にフォーカスが当たった瞬間に、利用者の意図しない大きな変化が起こらないようにすることを目的としています。予測しない変化は、キーボードで操作する利用者や、画面の変化を把握しづらい利用者にとって、現在位置や次の操作をわかりにくくします。

実践すべきこと

フォーカス単独での実行を避ける

• 要素にフォーカスが当たったことをきっかけとして、以下のような画面の大きな切り替わりを起こさない。
  • フォームの自動送信
  • 新しいウィンドウまたはタブを開く
  • 別のページへの自動遷移
  • ページ内の別のコンポーネントへの意図しないフォーカス移動

運用者への注意

キーボード操作での確認

• 新規ページや入力フォームを公開する前に、キーボード操作でTabキーだけを使ってページを順番に移動し、ただフォーカスしただけで意図せず画面が切り替わったりしないかをテストする。

開発者への注意

明示的なアクションの要求

• 機能の実行や画面遷移は、要素へのフォーカス時（onfocusイベント）ではなく、利用者による明示的な選択（クリック、タップ、Enterキー、Spaceキーの押下など）をトリガーとして実装する。

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

• ツールチップやメニューの展開： フォーカスに合わせて補足テキストを出したり、メニューを開いたりするだけの変化は、多くの場合、3.2.1 で問題にされる画面の大きな切り替わり（ページ遷移や送信など）には当たりません。ただし表示が画面全体を覆うほど大きくなり、操作の流れが変わってしまう場合は別途検討が必要です。避けたいのは、上の「実践すべきこと」に挙げたような、利用者の明示操作なしに起きる大きな変化です。
• 無限スクロールとフォーカス： 「もっと見る」などに Tab で入った瞬間だけで追加読み込みが走り、フォーカスが意図しない位置へ移ると、フッターへ進めなくなるなどの不具合が起きやすくなります。追加取得は、選択や Enter キーなど、利用者がはっきり起こした操作に紐づけるとよいです。

参考リンク

解説書 達成基準 3.2.1: フォーカス時

3.2.2 入力時 (レベル A)

チェックボックスやセレクトメニューを選んだだけで、意図しない画面切り替えを起こさない

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

この達成基準は、利用者がフォームに文字を入力したり、ラジオボタンやセレクトメニューを選択したりしただけで、利用者の意図しない大きな変化が起こらないようにすることを目的としています。特に、キーボードの矢印キーで選択肢を選ぼうとしている利用者が、途中の選択肢を通過・選択しただけでページが飛んでしまうといった事故を防ぎます。

実践すべきこと

入力・選択単独での実行の回避

• チェックボックスの切り替えやセレクトメニューの選択操作によって、直接的にページ遷移や別ウィンドウの表示などの画面の大きな切り替わりを引き起こさない。
• 「送信」や「移動」といった、利用者が明確にアクションを起こすためのボタン（<button> や <input type="submit">）を用意する。

運用者への注意

キーボード操作でのフォーム確認

• フォームやプルダウンメニューがあるページを公開する際、キーボードの Tab キーと矢印キーだけで操作し、選択肢を移動させただけで意図せず画面が切り替わったり送信されたりしないかをテストする。

開発者への注意

onchange イベントの慎重な使用

• <select> 要素などの onchange イベントで即座にページ遷移（window.location.href の書き換えなど）を行う実装は、この基準を満たしにくくなるため避ける。

事前警告の提供（やむを得ず実装する場合）

• 仕様上どうしても選択と同時に画面が切り替わる実装をせざるを得ない場合は、そのコントロールの直前などで「選択すると画面が切り替わります」と事前に説明し、混乱を抑える。可能であれば即時遷移をやめ、別途「実行」などのボタンで遷移させる方が望ましい。

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

• <select> によるジャンプメニュー： プルダウンでリンク先を選ぶとすぐ遷移する実装では、キーボードで矢印キーから選択肢を辿るだけで、意図しない行先に移ってしまうことがあります。遷移は「移動」「決定」などのボタンを押したあとに行うか、仕様どおり即時遷移にする場合は直前の注意書きなど、上の開発者向けの方針に沿って検討するとよいです。
• 非同期の絞り込み： チェックを入れた結果、画面遷移なしに一覧だけが更新されるような Ajax の絞り込みは、フォーカス位置が変わらず同じ画面内の結果が差し替わるだけのことが多く、3.2.2 でいう画面の大きな切り替わりには当たらないと説明されることが多いです。利用者が予期しない挙動に感じないよう、ラベルやライブリージョンなど別の観点も合わせて確認するとよいです。

参考リンク

解説書 達成基準 3.2.2: 入力時

3.2.3 一貫したナビゲーション (レベル AA)

複数のページに共通して配置するメニューは、常に同じ順番で並べる

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

この達成基準は、サイト内のどのページに行っても、グローバルメニューや検索バーなどの「共通ナビゲーション要素」がいつも同じ場所・同じ順番で並んでいる状態を保つことを目的としています。利用者が「会社概要はいつも一番右にあるな」と学習できるようにすることで、理解や判断の負担を下げ、迷わずスムーズにサイト内を移動できるようにします。

実践すべきこと

ナビゲーション順序の一貫性

• サイト全体にわたって繰り返し表示されるグローバルナビゲーション、フッターリンクなどのナビゲーション要素は、利用者が自ら設定を変更しない限り、どのページでも同じ相対的な順序で表示する。

運用者への注意

リンク追加・変更時のルール徹底

• キャンペーン期間中などで、「特定のページにだけメニューの項目を増やしたり、目立たせるために並び順を入れ替えたりする」といった運用は、利用者の混乱を招くため避ける。ナビゲーションを変更する場合は、サイト全体のルールに従って一貫して反映させる。

開発者への注意

コンポーネントの統一

• ヘッダーの <nav> 要素やフッターのリンク群など、共通するナビゲーション部分はテンプレートやコンポーネントとして共通化し、ページごとにソースコード上の順序が変わってしまうミスをシステム的に防ぐ。

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

• レスポンシブと並び順： 広い画面では横並び、狭い画面ではハンバーガー内の縦並びに切り替わるだけなら、レイアウトが変わること自体はよくあるパターンです。見た目の方向が変わっても、グローバルナビなど繰り返し現れるブロックのなかで、各リンクの相対的な順序がページ間でそろっているかを確認します。
• サブメニューやローカルナビ： 特定のセクション配下だけに下位リンクを増やす、現在位置に応じて一段だけ展開する、といった変化は、サイト全体のメニュー順を入れ替えるのとは性質が異なることが多いです。利用者が「いつもと同じ並びが崩れた」と感じないか、解説書の例と照らしつつ判断するとよいです。

参考リンク

解説書 達成基準 3.2.3: 一貫したナビゲーション

3.2.4 一貫した識別性 (レベル AA)

同じ機能を持つアイコンやボタンには、サイト全体で同じ名前をつける

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

この達成基準は、サイト全体を通して検索ボタン、印刷アイコン、カートを見るリンクなど同じ機能を提供する要素に対して、常に一貫した名前を使用することを目的としています。ページによって呼び方が変わると、特に画面を見ずに操作する利用者や、同じ機能かどうかの判断に時間がかかる利用者が「これはさっきと同じ機能だろうか？」と迷ってしまいます。

実践すべきこと

ラベルと代替テキストの統一

• サイト全体の中で、同じ機能を持つコンポーネントには、一貫したテキストラベルや画像代替テキスト（alt 属性）を使用する。

運用者への注意

表記揺れのチェックとガイドライン化

• あるページでは「お問い合わせ」、別のページでは「コンタクト」、また別のページでは「連絡する」など、同じ機能のボタンで表記揺れが発生していないかを確認し、サイトの運用ガイドライン（用語集）として統一ルールを設ける。

開発者への注意

アイコンの alt や aria-label の統一

• 虫眼鏡のアイコンを「検索」機能として使う場合、すべてのページでそのアイコンの alt 属性や aria-label に「検索」という同じテキストを設定する。一部のページだけ「探す」や「サイト内検索」と変更しないようにする。

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

• 見た目が違っても機能が同じとき： ヘッダーの虫眼鏡アイコンと、ページ下の「検索」と書かれたボタンなど、見た目は違っても同じ検索へ進むのであれば、アクセシブルな名前（表示テキスト、alt、aria-label など）をサイト内で揃えることが本達成基準の意図です。表記ゆれ（「検索」と「探す」など）がないかもあわせて確認するとよいです。
• 同じ見た目でも機能が違うとき： どちらも虫眼鏡でも、一方はサイト全体の検索でもう一方は一覧の絞り込み、といったように役割が違う場合は、「サイト内検索」「一覧を絞り込む」など、中身が伝わる別の名前を付けると、音声操作や読み上げで取り違えにくくなります。

参考リンク

解説書 達成基準 3.2.4: 一貫した識別性

3.2.5 要求による変化 (レベル AAA)

画面の切り替わりや自動更新など「大きな変化」は、利用者がボタンを押すなど自ら要求した時だけ起こるようにする

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

この達成基準は、画面の状況を素早く把握するのが苦手な利用者や、画面を見ずにスクリーンリーダーを利用している人が、「自分が今どこにいて、何が起きたのかわからない」と混乱してしまうのを防ぐことを目的としています。ページが利用者の意図と関係なく別の画面に切り替わったり、新しいウィンドウが開いたり、コンテンツが自動更新されたりする「予期せぬ状況の変化」を減らし、利用者が「次に進む」「更新する」という明確なアクションを起こした時だけ変化が発生するように求めています。

実践すべきこと

利用者の明確な操作による変化の実行

• ページ遷移、新しいウィンドウの展開、フォームの自動送信、データの定期的な自動リロードなど、画面全体の状況が大きく変わる動きは、利用者がリンクやボタンを選択（クリック、タップ、Enterキーなど）した結果として発生させる。
• または、それらの自動的な変化を利用者自身がオフにできるように機能を提供する。

運用者への注意

「勝手な動き」の見直しとボタンの配置

• プルダウンメニューから項目を選んだ瞬間に別のページへ移動する仕様や、一定時間で自動的に画面がリフレッシュされるニュースティッカーなどの採用を見直す。
• どうしても新しいウィンドウを開く必要がある場合は、リンクテキストに「（新規ウィンドウで開く）」と事前に明記し、利用者が納得してから選択できるようにする。

開発者への注意

明示的な「実行ボタン」の実装

• JavaScriptを用いて、セレクトボックスの選択直後や、入力フィールドからフォーカスが外れた瞬間など利用者の意図しないタイミングで window.location.href を書き換えたり、フォームを自動で submit() したりする実装を避ける。
• 操作を完了させるための「適用する」「送信する」「検索する」といった明示的な実行ボタン（<button> や <input type="submit">）を配置する。

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

• レベルAAAの難易度と優先度： ECサイトの絞り込み検索などでは、チェックボックスを押した瞬間に自動で商品一覧が更新されるUIが、操作の手間を省くリアルタイム性のあるデザインとして取り入れられる場合があります。これらをすべて「実行ボタンを押すまで更新しない」仕様に統一することは、一般的なユーザビリティと衝突する可能性があるため、「レベルAAA」に設定されています。まずはフォーカス時や入力時に予期せぬ変化を起こさない 3.2.1 や 3.2.2 から取り組むとよいですが、初めて使う人が多いサイトや、画面の変化を追うのが苦手な利用者が多い行政・インフラ系のシステムにおいては、この「利用者がボタンを押して進む」設計が安心感につながります。

参考リンク

解説書 達成基準 3.2.5: 要求による変化

3.2.6 一貫したヘルプ (レベル A)

お問い合わせやFAQへのリンク、チャットなどの「ヘルプ機能」は、常に同じ場所に配置する

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

この達成基準は、WCAG 2.2 から新たに追加されました。サイト内に「お問い合わせ」や「よくある質問（FAQ）」「チャットサポート」といったヘルプの仕組みが存在する場合、利用者がどのページにいても迷わずにそのヘルプを見つけられるよう、常に同じ相対的な位置（順序）に配置することを目的としています。特に、サポートを探す手順の理解に時間がかかる利用者が、余計な負担を感じずに必要な導線へ進めるようにします。

実践すべきこと

ヘルプメカニズムの配置の一貫性

• ウェブページ一式（サイト内）において、以下のようないずれかの「ヘルプ」が複数のページで提供されている場合、ページ内で他のコンテンツに対して相対的に同じ順序（同じ場所）に出現させる。
  • 人間への連絡先（電話番号、メールアドレスなど）
  • 人間への連絡メカニズム（問い合わせフォーム、チャットクライアントなど）
  • 自己解決のためのオプション（FAQ、サポートページへのリンクなど）
  • 自動化された連絡メカニズム（チャットボットなど）

運用者への注意

配置のバラつきの防止

• あるページではヘッダーの右端に「お問い合わせ」があるのに、別のページではフッターにしかない、あるいはサイドバーに移動しているといった配置のバラつきをなくし、サイト全体で統一する。

開発者への注意

共通コンポーネントとしての一貫した実装

• ヘルプへのリンクやチャットボットの起動ボタンなどは、共通のテンプレートやコンポーネントとして実装し、ページごとにHTMLのソースコード上の順序が変わってしまうことをシステム的に防ぐ。

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

• ヘルプの有無は別の話： 本達成基準は、「サイトにヘルプを設けること」そのものを求めるものではありません。ヘルプや問い合わせ導線などを複数ページで出しているときに、その出現位置の相対順序をページ間でそろえることが対象になります。
• レスポンシブでの見え方の変化： 画面幅や向きが変わり、ブレークポイントをまたいでヘルプの見え方や置き場所が変わること自体は、レイアウトの都合として起こり得ます。確認の軸は、同じレイアウト条件のままページを移したときに、ヘルプが同じ相対位置に並ぶかどうかです。
• 固定表示のヘルプボタン： 右下に固定したチャットや「お問い合わせ」ボタンは、ページをまたいでも同じ隅に残るため、相対位置の一貫性を保ちやすい実装の一例です。一方で、他のコンテンツやフォーカスを覆い隠さないか（達成基準 2.4.11「隠されないフォーカス（最低限）」など）もあわせて確認するとよいです。

参考リンク

解説書 達成基準 3.2.6: 一貫したヘルプ

目次へ戻る