ナビゲーション可能のガイドライン

2.4.1 ブロックスキップ (レベル A)

繰り返されるメニューなどをスキップして、メインコンテンツへ素早く移動できるようにする

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

この達成基準は、キーボードやスクリーンリーダーを使用してページを操作する利用者が、すべてのページで共通して表示されるナビゲーション(グローバルメニューなど)を何度も読み飛ばす手間を省き、目的のメインコンテンツに直接たどり着けるようにすることを目的としています。

実践すべきこと

スキップリンクの検討
  • ページの先頭付近に、メインコンテンツへ直接ジャンプできるリンク(例:「メインコンテンツへ移動」)の配置を検討する。
  • 達成基準が求めるのは繰り返しブロックのバイパスであり、スキップリンクという実装に限定されない。ただし、ランドマークや見出しなど、実際にバイパスできる手段を用意する。
ランドマークと見出しによる構造化
  • ランドマーク(HTML5の構造要素)と適切な見出しレベルを設定し、支援技術の機能を利用してセクション間を容易に移動できるようにする。

運用者への注意

定期的な構造チェック
  • 新規ページや更新されたコンテンツにおいて、ランドマーク要素や見出しが適切に設定されており、繰り返しブロックのバイパスが損なわれていないかを定期的に確認する。

開発者への注意

HTML5構造化要素(ランドマーク)の適切な使用
  • <header><nav><main><footer><aside> などのHTML要素を適切に使用して、ページの構造をプログラムが解釈可能な形で定義する。
見出しの階層(h1~h6)
  • コンテンツの構造に従って見出しタグを正しく使用する。スクリーンリーダー利用者は見出しリストを呼び出してジャンプできるため、視覚的な装飾目的で見出しレベルを飛ばしたり選んだりしない。
スキップリンクの視覚的な配慮
  • メインコンテンツへのリンクは、通常時は非表示でも構わないが、キーボード操作でフォーカスが当たった際(:focus 時)には画面上に表示されるようにCSSを設計する。

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

  • ランドマークへのラベル付け: 1つのページ内に複数の <nav> 要素(例:グローバルナビとサイドナビ)が存在する場合、aria-label 属性を使用して「グローバルナビゲーション」「サイドメニュー」のように名前を付けることで、利用者がそれぞれの役割を区別しやすくなる。
  • キーボード操作の効率: タブ操作だけでメインコンテンツに到達するのに何十回も打鍵が必要なサイトは、利用者の負担が大きくなります。メニュー項目が多い大規模サイトでは、スキップリンクのほか短いナビへの整理など、打鍵数を実質的に減らす手段を特に検討する。
  • 入れ子構造の注意: <header><footer> の中に別のランドマークを無意味に入れ子にすると、スクリーンリーダーでのナビゲーションが煩雑になる場合があるため、シンプルで論理的な構造を心がける。

参考リンク

解説書 達成基準 2.4.1: ブロックスキップ

2.4.2 ページタイトル (レベル A)

ページの内容が一目でわかるタイトルを設定する

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

この達成基準は、利用者がブラウザのタブや検索エンジンの結果、またはスクリーンリーダーの最初の読み上げを通じて、「今自分がどのページにいるのか」「そのページには何が書かれているのか」を瞬時に把握できるようにすることを目的としています。

実践すべきこと

明確で固有のタイトルの設定
  • 各ページの内容や目的を正確に表す、具体的でわかりやすいタイトルを設定する。
  • サイト内のどの位置にいるかがわかるように、ページ固有の名前とサイト全体(またはカテゴリ)の名前を組み合わせる。

運用者への注意

タイトルの重複と冗長性の回避
  • 「お知らせ」や「詳細」といった一般的な名称であっても、「製品Aのお知らせ」のように、サイト内で全く同じタイトルが複数ページに存在しないように工夫する。
  • ページタイトルはあくまで「名称」であるため、長文の説明や文章を詰め込まないようにする。

開発者への注意

<title>要素の確実な設定
  • HTMLの <head> 内にある <title> 要素に、ページの内容を適切に示すテキストを設定する。
SPA(シングルページアプリケーション)でのルーティング制御
  • ReactやVueなどで構築されたSPAでは、画面遷移時に自動で <title> が切り替わらないケースがあるため、ルーティングのフック等を利用してプログラム側で動的にタイトルを更新する処理を実装する。

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

  • 並び順(ページ名を先に): スクリーンリーダーは <title> を先頭から読み上げる。「サイト名 | ページ名」とすると、遷移のたびに長いサイト名を最後まで聞いて初めて現在位置がわかる場合があり、負荷が大きくなる。WCAGの条文が順序を固定しているわけではないが、多くの解説や実務では「ページ名 | サイト名」のように固有部分を先に置くことが推奨される。
  • SEO(検索エンジン)との関係: ページタイトルは検索結果でも目立つ要素です。内容を端的に表すタイトルにすると、利用者がタブや一覧で識別しやすくなるだけでなく、検索での理解の手がかりにもなります。

参考リンク

解説書 達成基準 2.4.2: ページタイトル

2.4.3 フォーカス順序 (レベル A)

キーボード操作の順番(フォーカスの移動順)を論理的で予測可能にする

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

この達成基準は、キーボード(主にTabキー)のみでウェブページを操作する利用者が、コンテンツ内を「上から下へ、左から右へ」といった自然な順番で、迷うことなく移動できるようにすることを目的としています。画面上の見た目と、実際のキーボードの移動順序がバラバラだと、利用者は自分がどこを操作しているのか見失ってしまいます。

実践すべきこと

論理的なフォーカス順序の確保
  • ページ上のフォーカス可能な要素(リンク、ボタン、フォーム入力欄など)を、コンテンツの構造や視覚的なレイアウトと一致した自然な読み取り順序にする。
予測可能な順序の設計
  • 「次へ」進むためのキー(Tabキー)を押したときに、画面のあちこちにフォーカスが飛ぶことなく、直感的に次の要素へ移動するように設計する。

運用者への注意

キーボードによる実際の確認
  • 新規ページを作成したりレイアウトを変更したりした後は、キーボード操作でTabキーを繰り返し押し、フォーカスが意図した通り(見た目の順番通り)に移動するかを定期的にチェックする。

開発者への注意

DOM構造と視覚的配置の一致
  • フォーカスの順序はHTMLの記述順(DOMツリーの順序)に依存するため、マークアップは論理的な情報の流れに基づいて行う。
tabindexの慎重な使用(正の値の回避)
  • tabindex="1"tabindex="2" のような「正の値」でフォーカス順を強制すると、DOM の順序とは別に番号を管理することになり、ページの更新のたびに順序のずれや想定外の挙動が起きやすい。特別な理由がない限り用いず、フォーカス順は DOM の並びやスタイルの調整でそろえる。要素をフォーカス可能にする目的であれば、tabindex="0" を使用する。

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

  • CSSレイアウトの注意: Flexboxの order プロパティや flex-direction: row-reverse;、または CSS Grid を使用して「見た目の順番」をHTMLの記述順から入れ替えた場合、キーボードのフォーカスは「見た目」ではなく「HTMLの順番」で移動します。視覚的な順序とフォーカス順序が逆転しないよう注意が必要です。
  • モーダルやドロワーの展開時: 「メニューを開く」ボタンを押して画面にメニューが現れた際、次にTabキーを押したときにフォーカスが「開いたメニューの中」に移動するよう、フォーカスを移動させる実装が必要となります。

参考リンク

解説書 達成基準 2.4.3: フォーカス順序

2.4.4 リンクの目的 (周囲の文脈・コンテキスト内) (レベル A)

テキストリンクは、どこへ遷移するのかを明確にする

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

この達成基準は、利用者がリンクを選択する前に、「そのリンクがどこへ繋がっているのか」「実行すると何が起きるのか」を、リンクテキスト自体、またはその周囲の文脈から正しく推測できるようにすることを目的としています。

実践すべきこと

明瞭なリンクテキストの作成
  • リンクテキストを見ただけで、リンク先のページ内容や目的が理解できる具体的な言葉を選ぶ。
周囲の文脈の提供
  • デザインの都合でリンクテキストを短くせざるを得ない場合でも、同じ段落やリスト項目など、直前・直後のテキストと合わせることでリンク先が理解できるようにする。

運用者への注意

「こちら」や「ここを選択」だけにしない
  • 「詳細についてはこちら」のような曖昧なリンクテキストは避ける。「〇〇サービスの詳細について」のように、リンクテキスト自体に意味を持たせる。リンク先の名称に迷った場合は、遷移先のページタイトルを使用するのが最も確実である。
別ウィンドウ(新しいタブ)で開く場合の事前告知
  • 外部リンクやPDFファイルなどが別ウィンドウで開く場合、利用者が混乱しないよう、リンクテキスト内に「(別ウィンドウで開く)」と記載するか、専用のアイコンを配置して視覚的にも明示する。
  • 現在のページ自身(カレントページ)へのリンクは、利用者を混乱させるためなるべく配置しない。

開発者への注意

スクリーンリーダーへの配慮
  • 画面上のデザインとして、どうしてもボタンのテキストを「詳細を見る」に統一したい場合は、aria-labelaria-describedby 属性を活用して、スクリーンリーダーには「〇〇サービスの詳細を見る」と読み上げられるように周囲の文脈を補足する。

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

  • リンク一覧での判別: スクリーンリーダーではリンクだけを一覧表示する機能があり、周囲の文脈が見えません。「詳細」「こちら」だけが並ぶと区別しにくくなります。リンクテキスト単体でも目的がわかるようにすると、関連する 2.4.9(レベル AAA)の考え方とも整合しやすくなります。
  • 一覧などで分割されたリンク: 記事のサムネイル画像、タイトル、日付、「もっと見る」ボタンがそれぞれ別の <a> タグでリンクされていると、キーボード操作や音声読み上げの際に「同じリンク先に何度もフォーカスが当たる」という煩わしさが発生します。カード全体を一つの <a> 要素で囲むか、不要なリンクは tabindex="-1"aria-hidden="true" でキーボードとスクリーンリーダーから隠す配慮が求められます。

参考リンク

解説書 達成基準 2.4.4: リンクの目的 (周囲の文脈・コンテキスト内)

2.4.5 複数の手段 (レベル AA)

目的のページを探すためのアプローチを複数(検索やサイトマップなど)用意する

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

この達成基準は、利用者が自分に一番合った方法で目的のページを見つけられるように、ナビゲーション手段を「2つ以上」提供することを目的としています。メニューから階層を順にたどるのが得意な人もいれば、キーワード検索で直接探したい人、サイトマップで全体の構造を見渡したい人もいるため、利用者に選択肢を用意することが重要です。

実践すべきこと

複数のナビゲーション手段の提供
  • ウェブページを見つけるための手段として、以下のうち少なくとも2つ以上をサイト内に提供する。
    • グローバルナビゲーションなどの階層的なリンクメニュー
    • サイトマップ(サイト全体の目次ページ)
    • サイト内検索機能
    • トップページからサイト内のすべてのページへのリンク一覧(小規模なサイトの場合)

運用者への注意

孤立したページの防止とリンクの維持
  • 新しいページやコンテンツを追加した際、サイト内のどこからもリンクされていない「孤立したページ」にならないように注意する。
  • サイトマップが最新の状態に更新されているか、または検索機能に適切にインデックスされているかを定期的に確認する。

開発者への注意

手段自体のアクセシビリティ確保
  • ナビゲーション手段として「サイト内検索機能」を実装する場合、その検索窓(<input>)や検索ボタン自体が、キーボード操作やスクリーンリーダーで利用できるように適切にマークアップする。

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

  • プロセスの途中は例外: 「カートに入れる → 配送先入力 → 決済確認 → 完了画面」のような、特定の順序でステップを踏んで進むことが前提の手続きの中にあるページは、複数の手段で直接アクセスできる必要はありません(この基準の例外として扱われます)。
  • 狭い画面でのサイトマップリンク: 画面が狭いと、多段のアコーディオンやドロップダウンは一度に見える情報が少なく、目的のページを探す負荷が大きくなりがちです。フッターなどにサイトマップへのリンクを置いておくと、ナビの階層をたどらずにページを選べる別の経路となり、迷ったときの補助になります。

参考リンク

解説書 達成基準 2.4.5: 複数の手段

2.4.6 見出し及びラベル (レベル AA)

見出しや入力欄のラベルを、その目的が明確に伝わる簡潔な言葉にする

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

この達成基準は、利用者がページ内の情報を拾い読みしたり、フォームに入力したりする際に、迷わず目的の場所を見つけられるようにすることを目的としています。何について書かれているセクションなのか(見出し)、何を入力すべき項目なのか(ラベル)がひと目で分かる明確な言葉を選ぶことで、すべての利用者の理解や判断の負担を大きく下げることができます。

実践すべきこと

内容を正確に表す言葉の選択
  • 見出しのテキストは、そのセクションやコンテンツのトピックを明確かつ簡潔に表す言葉にする。
  • フォームのコントロール(入力欄、チェックボックスなど)に付与するラベルは、利用者が何を入力・選択すべきかを容易に理解できる具体的な言葉にする。

運用者への注意

曖昧で長すぎる表現の回避
  • 見出しに文章のような長々とした説明を含めず、関連する内容を端的に伝えるキーワードを用いるようにする。
  • フォームのラベルに「ここに入力」「テキスト」といった意味を持たない言葉ではなく、「お名前(漢字)」「検索キーワード」といった具体的な用途を設定する。

開発者への注意

見出しタグの適切な活用
  • ページ内のトピックの区切りには、<h1> から <h6> までの見出しタグを適切な階層で使用し、コンテンツの構造を明確にする。
フォームとラベルの明確な紐付け
  • フォームコントロールに対して、視覚的に分かりやすいラベルを配置するだけでなく、HTMLの <label for="...">id を用いてプログラム的にも紐付けを行う。

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

  • 「ある」ことより「伝わる」こと: 2.4.6 は、見出しやラベルを「ページに用意すること」そのものを定める基準ではありません。配置やプログラム的な紐付けなどは、1.3.1 や 3.3.2 など別の達成基準で扱われます。見出し・ラベルが置かれているときに、その文言が目的を簡潔に示しているかが問われます。
  • 検索との両立: 内容を端的に表す見出しは、スクリーンリーダーの見出し一覧から目的の箇所へ移動しやすくなると同時に、検索エンジンがページの主題を把握する手がかりにもなります。

参考リンク

解説書 達成基準 2.4.6: 見出し及びラベル

2.4.7 フォーカスの可視化 (レベル AA)

キーボード操作時に、現在どこを選択しているかを視覚的にわかるようにする

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

この達成基準は、キーボード(Tabキーなど)でページ内を移動する利用者が、「今、画面のどこを操作しているのか(どこにフォーカスが当たっているか)」を視覚的に見失わないようにすることを目的としています。フォーカスの位置がわからないと、意図したリンクを開いたり、フォームに正しく入力したりしにくくなり、現在位置を把握しづらくなります。

実践すべきこと

フォーカス位置の明確な視覚化
  • キーボード操作でリンクやボタン、入力フォームなどにフォーカスが移動した際、枠線が表示されたり背景色が変わったりするなど、その要素が現在選択されていることが視覚的にはっきりとわかるようにする。

運用者への注意

キーボードによる目視確認
  • 新規ページを作成した際やデザインをリニューアルした際は、キーボード操作でTabキーを使ってページ内を一周し、すべての操作可能な要素でフォーカスの枠線(または色の変化)が消えずに表示されるかを定期的にチェックする。

開発者への注意

outline: none; を使う場合の注意
  • ブラウザがデフォルトで提供しているフォーカスの枠線を、CSSの初期化などで outline: none;outline: 0; を指定して消す場合は、代わりの表示を用意する。
  • デザイン上の理由でデフォルトの枠線を消す必要がある場合は、それに代わる明確な視覚的変化(太い下線の追加、背景色の反転など)を :focus 疑似クラスを用いて実装する。

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

  • :focus-visible によるデザインとの両立: 以前は、ポインタ操作で選択したときにも枠線が出るのがデザインと合わないとして、フォーカス表示をまとめて消してしまう実装が多く、達成基準を満たさない例が見られました。現在は :focus-visible 疑似クラスにより、キーボード操作のときだけ枠線を出し、ポインタ操作のときは出さない、といった制御がしやすくなり、アクセシビリティとデザインを両立しやすくなっています。
  • コントラスト不足に注意: オリジナルのフォーカス枠を設定しても、枠線の色が背景色に近いと判別しづらくなります。たとえば青い背景のボタンに青い枠だけでは視認しづらいため、背景と十分に差のつく色を選びます(WCAG 2.2 の達成基準 2.4.13「フォーカスの外観」でも、より具体的な要件が示されています)。

参考リンク

解説書 達成基準 2.4.7: フォーカスの可視化

2.4.8 現在位置 (レベル AAA)

利用者が、今サイト内のどこにいるか分かる手がかりを用意する

この達成基準は、サイト内を移動している利用者が、現在のページや現在のステップを把握できるようにするための基準です。パンくずリスト、現在位置を示すナビゲーション、フォームのステップ表示などがあると、前後関係を見失いにくくなります。

  • 階層が深いサイトでは、パンくずリストや現在選択中のメニュー表示を用意する。
  • 申し込みフォームなど複数ステップの手続きでは、「入力」「確認」「完了」など現在の段階を示す。
  • レベルAAAの基準であるため、まずはページタイトルや見出し、ナビゲーションの整理を優先し、複雑なサイトでは追加の手がかりとして検討する。

解説書 達成基準 2.4.8: 現在位置

2.4.9 リンクの目的 (リンクのみ) (レベル AAA)

リンクテキストだけを読んでも、移動先や実行内容が分かるようにする

2.4.4 では周囲の文脈を含めてリンクの目的が分かればよいとされていますが、このレベルAAAではリンクテキスト単体で目的が分かることを求めています。リンク一覧や音声読み上げでリンクだけを確認する利用者にとって、目的を判断しやすくなります。

  • 「こちら」「詳細」だけでなく、「採用情報を見る」「料金プランの詳細を見る」のように具体的に書く。
  • 同じ文言のリンクが複数ある場合は、対象名を含めて区別できるようにする。
  • 一覧画面などで表示が長くなりすぎる場合は、2.4.4 を満たしたうえで、必要に応じて aria-label や周囲の見出しとの関係も検討する。

解説書 達成基準 2.4.9: リンクの目的 (リンクのみ)

2.4.10 セクション見出し (レベル AAA)

長いページでは、内容のまとまりごとに見出しを用意する

この達成基準は、利用者が長いページの中から必要な情報を見つけやすくするための基準です。見出しがあると、画面を見て拾い読みする人も、見出し一覧で移動する人も、ページ全体の構造を把握しやすくなります。

  • 1つのページに複数の話題がある場合は、話題ごとに見出しを付ける。
  • 見出しは装飾目的ではなく、そのセクションの内容を表す言葉にする。
  • 短いページや単一の内容だけのページでは、過剰に見出しを増やさず、読みやすさとのバランスを取る。

解説書 達成基準 2.4.10: セクション見出し

2.4.11 隠されないフォーカス (最低限) (レベル AA)

キーボードで選択した要素が、固定ヘッダーやポップアップの裏に隠れて見失われないようにする

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

この達成基準は、WCAG 2.2 から新たに追加されました。キーボードのTabキーでページ内を移動している際、フォーカスが当たった要素(リンクやボタン)が、画面の上部に固定されたヘッダーや、画面下部に追従するバナーの裏側に隠れて見えなくなってしまう状態を防ぐことを目的としています。フォーカス位置が見えないと、利用者は「今どこを操作しているのか」を把握しづらくなります。

実践すべきこと

フォーカスされた要素の視認性の確保
  • キーボードフォーカスを受け取るすべてのUIコンポーネントは、他のコンテンツ(著者作成のコンテンツ)によってその「全体」が隠されることがないようにする。
  • ※この「最低限(レベルAA)」の基準では、要素の「一部」が隠れることは許容されますが、ボタンやリンクのすべてが覆い隠されてしまうと基準を満たしにくくなります。(隠れをさらに減らす基準が、レベルAAAの 2.4.12 です)

運用者への注意

追従バナーやCookie同意パネルの配置確認
  • 画面下部に「常に表示されるチャットボタン」や「Cookie同意バナー」を設置した際、Tabキーでページ最下部のフッターリンクまで移動したときに、それらのバナーの裏側にフッターのリンクが隠れてしまわないかを確認する。

開発者への注意

scroll-padding の積極的な活用
  • position: fixed;position: sticky; を用いて追従ヘッダーを実装した場合、ブラウザの標準のスクロール挙動ではフォーカスした要素がヘッダーの裏に潜り込んでしまうことが多い。CSSの scroll-padding-top にヘッダーの高さ分を指定することで、フォーカスした際に要素がヘッダーの下に隠れない位置まで正しくスクロールさせることができる。
重なり(z-index)とフォーカスの管理
  • モーダルウィンドウやドロワーメニューを開いた際、背面のコンテンツが見えたままになっていても、背面側へのTabキーでの移動(フォーカス)を防ぐ(あるいは非活性にする)処理を実装しないと、見えないところでフォーカスが移動してしまい基準を満たしにくくなる。

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

  • 追従ヘッダーとフォーカス: 画面上部に固定されるヘッダーは一般的ですが、Tab 移動でフォーカスがヘッダーの背後に回り込み、操作位置が分かりにくくなることがあります。こうした UI での不都合が指摘されてきた背景の一つとして、WCAG 2.2 で本達成基準が追加されました。実装後は、キーボードで Tab 移動しながらスクロールしてもフォーカスが判読できるか確認するとよいです。
  • 「一部が隠れる」場合: レベルAAの最低限では、著者作成のコンテンツによって要素全体が隠れることが問題になります。たとえばボタンの半分だけがヘッダーにかかり、全体は見えている状態は許容されます。ただし視認性は下がるため、可能であれば scroll-padding などで隠れを減らし、より厳しいレベルAAAの 2.4.12(隠されないフォーカス(高度))に近い状態を目指すとよいです。

参考リンク

解説書 達成基準 2.4.11: 隠されないフォーカス (最低限)

2.4.12 隠されないフォーカス (高度) (レベル AAA)

フォーカスされた要素が、ほかの表示に少しでも隠れないようにする

この達成基準は、2.4.11 よりもさらに厳しく、フォーカスされた要素が固定ヘッダーやバナー、モーダルなどによって一部でも隠れない状態を目指します。業務システムや複雑なフォームなど、キーボード操作で迷うと作業に大きく影響する画面では特に有効です。

  • scroll-padding や余白設計で、固定ヘッダーの下にフォーカス要素が潜り込まないようにする。
  • 追従バナーやチャットボタンが、ページ下部のリンクやボタンを覆わないか確認する。

解説書 達成基準 2.4.12: 隠されないフォーカス (高度)

2.4.13 フォーカスの外観 (レベル AAA)

キーボードで選択している場所が、十分な大きさと明暗差で分かるようにする

この達成基準は、フォーカス表示が「見える」だけでなく、見落としにくい大きさとコントラストを持つことを求める基準です。細い枠線だけでは見つけにくい場合があるため、背景色の変化、太めの枠線、下線などを組み合わせると確認しやすくなります。

  • フォーカス枠は背景と十分に区別できる色にする。
  • ボタンやリンクの位置が分かるよう、枠線・下線・背景色などの変化をはっきり出す。
  • デザインシステム側でフォーカス表示のルールを決め、部品ごとにばらつかないようにする。

解説書 達成基準 2.4.13: フォーカスの外観

目次へ戻る

公開・販売・運用のことで困ったら、まずは「ましじめ」へ

ウェブサイトの制作や改善、AI活用、アクセシビリティ、
商品やサービスの見せ方まで、何から手をつければよいか分からない段階でもご相談ください。
自社事業の経験と専門的な技術力を活かし、無理なく続けられる形をご提案します。