WCAG 3.2.3: 一貫したナビゲーション

WCAG 3.2.3 は、ウェブページの集合内で複数のページに表示されるナビゲーション機構について、ユーザーが変更を開始しない限り、毎回同じ相対的な順序で配置されることを求めています。この予測可能性により、認知障害、視覚障害、運動障害のあるユーザーはサイトのメンタルモデルを構築し、効率的にナビゲーションできるようになります。

このルールの意味

WCAG 達成基準 3.2.3 — 一貫したナビゲーション（レベル AA）は、ウェブサイトの複数ページに繰り返し表示されるナビゲーションコンポーネントについて、ユーザー自身がその順序の変更を引き起こした場合を除き、毎回同じ相対的な順序で現れなければならないと定めています。この達成基準は、共通の目的を共有する、または同一サイトやアプリケーションの一部である一連のウェブページすべてに適用されます。

「同じ相対的な順序」という表現が重要です。WCAG は、ナビゲーションが常に同じ数の項目を含むことや、ナビゲーション項目の間に他の要素が挟まれないことを要求しているわけではありません。要求しているのは、インターフェイスを移動するユーザーにとってのナビゲーションリンクの並び順が、ページごとに一貫していることです。たとえば、ホームページのメインナビゲーションが「Home」「Products」「About」「Contact」という順序で並んでいる場合、そのナビゲーションブロックが存在する他のすべてのページでも、同じ項目が同じ順序で表示されなければなりません。

この達成基準は、繰り返し表示されるすべてのナビゲーションメカニズムを対象とします。サイトのメインナビゲーションメニュー、パンくずリスト、フッターのリンクグループ、サイドバーのメニュー、スキップナビゲーションリンク、検索バー、その他サイト内を移動するのに役立つあらゆるインタラクティブコンポーネントが含まれます。これらのコンポーネントが <nav> ランドマーク、<ul> のリンクリスト、ARIA で拡張されたカスタムメニュー、その他どのようなマークアップパターンで実装されているかは問いません。

適合とみなされるケース: ナビゲーションブロックが、繰り返し表示されるすべてのページで同じ相対的な順序で現れていること。項目を追加したり、ハイライトしたり、アクティブ（例: 現在のページのリンクを視覚的に区別する）としてマークしたりしても構いませんが、全体の並び順が変わらないことが条件です。ユーザーが自ら並び替えを行うケース — たとえば、ユーザーがパネルをドラッグして位置を変えられるカスタマイズ可能なダッシュボード — も適合とみなされます。なぜなら、その変更はユーザーが起点だからです。

不適合とみなされるケース: ホームページのメインナビゲーションが「Home → Products → Contact → About」となっている一方で、商品詳細ページでは「Home → About → Products → Contact」となっている場合、3.2.3 に不適合です。同様に、ユーザーの操作なしに内部ロジックに基づいてナビゲーション内の任意の位置に追加リンクを挿入するサイトも不適合となります。

公式な例外: 仕様では、ユーザーが順序の変更を開始した場合にはこの要件は適用されないと明示しています。これは唯一の規範的な例外です。システム、サーバーロジック、パーソナライゼーションアルゴリズムによって駆動される変更 — ユーザーによって直接トリガーされていない変更 — は、この例外の対象にはなりません。

なぜ重要か

一貫したナビゲーションは、認知アクセシビリティの基盤です。空間的な記憶や予測可能なパターンに頼って自分の位置を把握するユーザー — 認知障害、注意障害、外傷性脳損傷、加齢に伴う認知機能低下などのある人を含む — は、サイトのナビゲーションが毎回同じ場所・同じ順序にあるという前提に大きく依存しています。ナビゲーションが予期せず変化すると、これらのユーザーはページごとにレイアウトを再学習しなければならず、認知負荷とエラーや離脱の可能性が大幅に高まります。

スクリーンリーダー（NVDA、JAWS、VoiceOver）で操作する視覚障害・ロービジョンのユーザーにとって、一貫したナビゲーションは既知のランドマークを探す時間を短縮します。「Contact」リンクがメインナビゲーションの 4 番目の項目だと記憶しているスクリーンリーダーユーザーは、どのページでも Tab キーを 4 回押せばそこに到達できます — ただし、その順序が常に同じであることが保証されている場合に限ります。順序が一貫していないと、この効率性は失われ、ユーザーはページを読み込むたびにナビゲーション全体を聞き直さなければなりません。

キーボードのみの操作、スイッチアクセス、視線入力に頼る運動障害のあるユーザーにとっては、キー操作や頭の動きが 1 回増えるごとに実際の負担が生じます。予測可能なナビゲーションは、よく利用する目的地に到達するために必要な操作回数を減らします。世界保健機関によると、世界で 13 億人以上が何らかの障害とともに生活しており、その多くが、一貫性と予測可能性の高いインターフェイスから直接恩恵を受ける支援技術に依存しています。

ディスレクシアなどの読字障害のあるユーザーにとって、ナビゲーションバーを視線で追うこと自体がすでに負荷の高い作業です。位置、形、色といった視覚的なアンカーに頼れるよう、配置と順序が一貫していることが重要であり、そのおかげで毎回ラベルを読み直さずに済みます。

具体的な実例として、病院のウェブサイトで再診予約をしようとしている患者を想像してください。ホームページのナビゲーションには「Services」「Appointments」「Doctors」「Contact」の順で並んでいます。患者は医師のプロフィールページに移動し、2 番目の位置にあるはずの「Appointments」を探します — しかしそのページでは、ナビゲーションが「Doctors」「Appointments」の順に並び替えられています。すでにストレスを抱えている患者は、メニュー全体を再度スキャンしなければなりません。認知障害や識字能力が限られているユーザーにとって、この摩擦はタスクを完了できるか、途中で諦めてしまうかを分ける決定的な要因になり得ます。

アクセシビリティにとどまらず、一貫したナビゲーションには測定可能なSEO とユーザビリティのメリットもあります。検索エンジンのクローラーは、コンテンツを発見・インデックスするためにナビゲーションリンクをたどります。安定したリンク構造はクロール効率と内部リンクの評価を高めます。ユーザビリティテストでも一貫して、予測可能なナビゲーションは、障害の有無にかかわらずすべてのユーザーにおいて、タスク完了時間とエラー率を低減することが示されています。

テスト方法

自動スキャンを実行してベースラインのコンテキストを把握する: 代表的なページで axe DevTools、Lighthouse、またはブラウザ拡張機能を使用し、ナビゲーション要素が <nav> ランドマークや role='navigation' で正しくマークアップされていることを確認します。これらのツールは順序の不整合を検出しませんが、ページ間で何がナビゲーションとして扱われているかを特定するのに役立ちます。手動チェックに進む前に、ランドマーク構造に関する問題を記録しておきます。
代表的なページサンプルを選定する: サイト内の異なるセクションから少なくとも 5〜10 ページを選びます — ホームページ、カテゴリーページ、商品または記事の詳細ページ、フォームページ、問い合わせページなどです。サイトに数千ページある場合は、主要なテンプレートをすべてカバーする層化サンプルを用います。各ページについて URL とページタイプを記録します。
ナビゲーションの順序を手動でマッピングする: 各サンプルページでブラウザのアクセシビリティツリー（Chrome DevTools → Accessibility パネル、または Firefox Accessibility Inspector）を開き、DOM に現れる順序でメインナビゲーション内のすべてのリンクを列挙します。また、視覚的にどの順序で表示されているかも記録します。CSS が flex-direction: row-reverse や order プロパティなどを使って視覚的に項目を並び替えている場合、視覚順序と DOM 順序が異なることがあります — 両方とも一貫している必要があります。
ページ間で比較する: ナビゲーション順序のリストを並べて配置します。ホームページで確立したベースラインと比べて、共有されているナビゲーション項目の並びが異なるページを特定します。どの項目がどの方向に移動したかを記録します。
キーボードナビゲーションテスト（NVDA + Firefox）: NVDA を起動し、Firefox を開いてホームページに移動します。D キーを押して次のランドマークリージョンにジャンプし、メインナビゲーションを見つけます。Tab キーでナビゲーションリンクを移動しながら、順序を声に出して読み上げるかメモします。その後、2 ページ目（例: 内部の記事ページ）に移動して同じ操作を繰り返します。リンクが読み上げられる順序に変化がないかを確認します。
スクリーンリーダーテスト（macOS の VoiceOver + Safari）: VoiceOver（Command + F5）を有効にし、Safari を開いて Web Rotor（Control + Option + U）を使い、リンクまたはランドマークメニューを開きます。メインナビゲーションに移動し、項目の順序を記録します。少なくとも 3 種類のページタイプで同じ操作を繰り返し、比較します。
JAWS + Chrome テスト: JAWS を起動し、Chrome を開いて R キーを押し、メインナビゲーションに到達するまでリージョンを順に移動します。Tab キーでリンクをたどり、順序を記録します。ページタイプごとに繰り返します。
ユーザー起点の例外を確認する: サイトにパーソナライゼーションやナビゲーションのカスタマイズ機能がある場合、並び替えが明示的なユーザー操作（例: ユーザーが「Customize Menu」をクリックして項目をドラッグする）後にのみ発生していることを確認します。また、並び替え後の状態が一貫して保持されていること — ユーザーが設定した新しい順序自体が、その後すべてのページで一貫していること — も確認します。

修正方法

サーバーサイドレンダリングの不整合 — 不適切な例

<!-- Homepage navigation -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<!-- Product detail page navigation — order changed by CMS template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/products'>Products</a></li>
  </ul>
</nav>

サーバーサイドレンダリングの不整合 — 適切な例

<!-- Shared navigation partial (e.g., _nav.html or a component) used on every page -->
<!-- The active page is indicated with aria-current, not by reordering -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/' aria-current='page'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- On the Products page, only aria-current moves — the order stays identical -->

CSS による視覚的な並び替えが不整合を生むケース — 不適切な例

<!-- DOM order: Home, Products, About, Contact -->
<!-- CSS on interior pages uses flex order to visually move Contact first -->
<style>
  /* Applied only on interior page templates */
  nav ul li:last-child { order: -1; }
</style>
<nav aria-label='Main navigation'>
  <ul style='display:flex'>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Visual order becomes Contact, Home, Products, About — inconsistent with homepage -->

CSS による視覚的な並び替えが不整合を生むケース — 適切な例

<!-- Use consistent DOM order and consistent CSS across all templates -->
<!-- Do not use CSS 'order' property to rearrange navigation items differently per template -->
<nav aria-label='Main navigation'>
  <ul style='display:flex'>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Same DOM order and same CSS flex order on every page template -->

アルゴリズムによって動的に並び替えられるナビゲーション — 不適切な例

<!-- JavaScript reorders nav links based on most-visited analytics without user action -->
<script>
  // Anti-pattern: fetches user behaviour data and reorders nav items automatically
  fetch('/api/user-nav-preferences').then(r => r.json()).then(order => {
    const nav = document.querySelector('nav ul');
    order.forEach(id => nav.appendChild(document.getElementById(id)));
  });
</script>
<nav aria-label='Main navigation'>
  <ul>
    <li id='nav-home'><a href='/'>Home</a></li>
    <li id='nav-products'><a href='/products'>Products</a></li>
    <li id='nav-about'><a href='/about'>About</a></li>
    <li id='nav-contact'><a href='/contact'>Contact</a></li>
  </ul>
</nav>

アルゴリズムによって動的に並び替えられるナビゲーション — 適切な例

<!-- If personalisation is desired, require an explicit user action and keep order stable otherwise -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Personalisation button lets user reorder — change only applies after they interact -->
<button type='button' aria-controls='main-nav-list' id='customize-nav'>Customize Navigation Order</button>
<!-- The user-chosen order is then persisted consistently across all pages -->

よくある間違い

ナビゲーションをそれぞれ独立して定義している異なる CMS テンプレートを使用することにより、単一の共有コンポーネントやパーシャルではなくテンプレートごとに別々に更新される結果、時間の経過とともに微妙な順序の違いが紛れ込んでしまう。
マーケティングキャンペーンに基づいて「特集」や「季節限定」のナビゲーション項目を別の位置に昇格させることにより、他のナビゲーションの順序が変わってしまう — たとえば、「Sale」を一部のページでは 2 番目、別のページでは 5 番目に一時的に移動させるなど。
CSS の order、flex-direction: row-reverse、CSS Grid の配置などを使って、ページテンプレートごとにナビゲーション項目を視覚的に並び替えることにより、視覚順序（視覚ユーザーが見る順序）と DOM 順序（キーボードやスクリーンリーダーユーザーがたどる順序）の不一致を生む。
コンテキストに応じたナビゲーション項目を任意の位置に挿入すること — たとえば、商品ページでのみ 2 番目の項目として「Back to Category」リンクを追加し、他のページには追加しないことで、それ以降の項目が 1 つずつ後ろにずれ、期待される順序が崩れてしまう。
A/B テストやアナリティクスプラットフォームにナビゲーションリンクの並び替えを任せることにより、ページやセッションごとに不一致な並び替えが行われることを考慮しない。
パンくずリストをこの達成基準の対象外とみなしてしまうこと。実際にはパンくずも繰り返し表示されるナビゲーションメカニズムであり、テンプレートごとに他のページ要素との相対的な位置が変わるパンくずは 3.2.3 に違反します。
フッターナビゲーションの並びをメインナビゲーションと異なる形で並び替えること。フッターリンクがメインナビゲーションを複製している場合、両方がすべてのページに表示されるなら、それぞれが独立して一貫した順序を保つとともに、互いの関係性も一貫していなければなりません。
スクロール位置、ビューポートサイズ、セッションデータに基づいて項目を並び替える JavaScript 駆動のナビゲーション拡張を、ユーザーの操作なしに適用すること — たとえば、ユーザーがサイト内のどのセクションにいるかによって、異なるトップレベルカテゴリを動的に前面に出すメガメニューなど。
サイトのリデザインや CMS 移行後にナビゲーションの一貫性を監査しないこと。開発者が元の順序を自然に再現してくれると想定してしまう一方で、実際には異なるページタイプが別々のチームメンバーによってゼロから作り直されている場合がある。
「一貫したナビゲーション」と「すべてのページで同じナビゲーション」を混同すること。チームが、特定のユーザーロール（例: ログインユーザーとゲスト）に応じてナビゲーション項目を追加・削除することが 3.2.3 に違反すると誤って結論づけてしまうことがあります。共有されている項目の相対的な順序が変わらない限り、これは違反にはなりません。

トルコのアクセシビリティ規制との関係

トルコの大統領通達第 2025/10 号は、2025 年 6 月 21 日付官報（第 32933 号）で公布され、トルコでデジタルサービスを提供する幅広い公的・民間主体に対して拘束力のあるアクセシビリティ義務を定めています。この通達は、国際的に認められたアクセシビリティ標準への適合を義務付けており、その主な技術的ベンチマークとして WCAG 2.2 レベル AA を採用しています。また、所定のアクセシビリティ水準を満たした主体に対して家族・社会サービス省が付与する認証マークであるErişilebilirlik Logosu（アクセシビリティロゴ）と適合性を結び付けています。

WCAG 3.2.3 一貫したナビゲーションはレベル AA の達成基準であり、Erişilebilirlik Logosu を取得しようとする主体にとっては必須要件です。デジタルサービス全体で一貫したナビゲーションを提供できていない組織は、他の達成基準でどれだけ優れたパフォーマンスを示していても、認証に必要な完全な AA 適合プロファイルを満たすことはできません。

大統領通達 2025/10 号の対象となり、そのため 3.2.3 への適合をベストプラクティスではなく法的義務として扱わなければならない主体の種類は次のとおりです。

あらゆるレベルの公的機関・政府機関（省庁、自治体、政府系機関を含む）。これらの機関のウェブサイトやデジタルポータルは、すべてのセクションで一貫したナビゲーションを提供しなければなりません。
トルコで事業を行う E コマースプラットフォーム。ユーザーはホームページ、カテゴリーページ、商品ページ、カート、チェックアウトページなどを行き来しますが、これらは通常同じナビゲーションバーを共有しているため、ナビゲーションの一貫性が特に重要です。
トルコの銀行法に基づき規制される銀行・金融機関。オンラインバンキングポータルや情報提供サイトは、認知障害や運動障害のある人を含むすべての顧客に対して予測可能なナビゲーションを提供しなければなりません。
病院や医療提供者。患者はしばしばストレスの高い状況にあり、予約、検査結果、緊急連絡先情報などを認知的な負担なく見つけるために、一貫したナビゲーションに頼っています。
20 万人以上の加入者を有する通信会社。これらの企業のカスタマーポータル、サポートサイト、アカウント管理インターフェイスは、数千に及ぶページやユーザー向けテンプレート全体でナビゲーションの一貫性を維持しなければなりません。
旅行代理店および民間輸送会社。検索、選択、搭乗者情報、支払いページにまたがる複数ステップの予約フローでは、旅程全体を通じてナビゲーションが一貫した順序で提示されなければなりません。
国民教育省（MoNE）に認可された私立学校。これらの学校のウェブサイトは、学生、保護者、教職員を対象としており、学習障害のある人を含め、教育リソースへのアクセスにおいて予測可能なナビゲーションに大きく依存するユーザーを支援しなければなりません。

トルコでデジタルサービスを構築または監査する組織にとって、3.2.3 はテンプレートおよびコンポーネント設計段階の品質保証プロセスに組み込むべき項目です。サーバーサイドインクルード、フロントエンドフレームワークのコンポーネント、ヘッドレス CMS のグローバル要素など、単一のソース・オブ・トゥルースからレンダリングされる共有ナビゲーションコンポーネントを使用することは、技術的に最も信頼性が高いだけでなく、この通達の要件の下で最も防御可能なコンプライアンス姿勢でもあります。Erişilebilirlik Logosu の申請プロセスの一環として提出されるアクセシビリティ監査には、ページ間のナビゲーション順序の検証を文書化されたテスト手順として含める必要があります。

出典と参考資料

AWCAG 1.1.1: 非テキストコンテンツ AWCAG 1.2.1: 音声のみおよび映像のみ（事前録画）AWCAG 1.2.2: キャプション（事前録画）