WCAG 達成基準 · Level AA

WCAG 2.4.5: 複数の方法

WCAG 2.4.5 は、ウェブページの集合内の任意のページを見つけるために、サイト検索、サイトマップ、ナビゲーションメニューなど、ユーザーに複数の方法を提供することをウェブサイトに求めています。これは、さまざまな能力や好みを持つユーザーが、自分にとって最も使いやすい方法でコンテンツを見つけられるようにするためです。

この規則が意味すること

WCAG 2.4.5「複数の手段」は、原則「操作可能」の下にあるレベルAAの達成基準です。これは、より大きなウェブページ集合の一部であるあらゆるウェブページが、少なくとも2つの異なるナビゲーション手段によって到達可能でなければならないと定めています。言い換えると、ユーザーがあるページを見つけるために、1つの経路だけに頼らざるを得ない状況を作ってはならないということです。

この基準を満たす一般的なナビゲーション手段には、サイト全体検索機能、サイトマップ(単独ページとしてでもインライン構造としてでも)、目次、一貫したナビゲーションメニューやサイドバー、パンくずリスト、関連ページ間のリンクなどがあります。これらのうち任意の2つ、または同等の手段を組み合わせて用いれば、この要件を満たします。

この達成基準は、特にウェブページの集合に適用されます。より大きなサイトやアプリケーションに属さない単独のウェブページは適用除外です。さらに、チェックアウトの確認ページ、フォーム送信成功画面、ウィザードのステップなど、処理の結果として表示されるページや処理の一段階であるページも明示的に適用除外です。これは、そのようなページが本質的に順序性を持っており、順序を無視して直接アクセスできるようにすることは不適切または有害になり得るためです。

適合(パス)には、少なくとも2つの独立したナビゲーション手段がサイト全体を通して存在し、機能し、アクセス可能であることが必要です。不適合(フェイル)は、1つの手段しか存在しない場合に発生します。例えば、検索もサイトマップもその他のナビゲーション支援もなく、トップナビゲーションメニューだけを提供しているサイトなどです。また、2つ目の手段が機能していない、あるいはアクセス不能な場合(例:結果を返さない検索ボックス、支援技術から隠されているサイトマップ)も不適合となります。

重要なのは、この達成基準が特定の手段の組み合わせを義務付けているわけではないという点です。この柔軟性は意図的なものです。コンテンツを探す際の戦略はユーザーによって根本的に異なり、この標準は特定の解決策を指定するのではなく冗長性を求めることで、この多様性を認めています。

なぜ重要か

ナビゲーションはあらゆるウェブ体験の基盤であり、ナビゲーション上の障壁は障害のある人々に不釣り合いな影響を与えます。ナビゲーション経路が1つしか存在しない場合、その経路を利用できないユーザーは実質的にコンテンツから締め出されてしまいます。

運動障害のあるユーザー—スイッチアクセス、視線入力装置、音声コントロールソフトウェア、キーボードのみのナビゲーションなどを利用する人を含む—にとって、複雑な階層型メニューは、効率的に移動することが疲れる、あるいは不可能な場合があります。サイト検索があれば、複数階層のメニューをたどることなく、コンテンツへ直接ジャンプできます。逆に、特定の認知障害や記憶障害のあるユーザーは、自由入力の検索フィールドを混乱しやすい、あるいは効果的に使いにくいと感じることがあります。そのようなユーザーにとっては、明確に構造化されたサイトマップや閲覧可能なカテゴリツリーの方がはるかに有用です。

スクリーンリーダーに依存する全盲のユーザーにとっては、スキップリンクがあっても、密度の高いナビゲーションメニューがページ訪問のたびに繰り返し現れる障害となり得ます。サイトマップや検索ショートカットは、その認知的・身体的負荷を大幅に軽減します。画面拡大を利用するロービジョンのユーザーにとっては、広いナビゲーションメニューは高倍率ズーム時に一部しか見えないことがあり、テキストベースの検索やサイトマップが重要な代替手段となります。

ディスレクシアや注意障害などの認知障害のあるユーザーにとっては、正確なメニュー階層を記憶したり認識したりする必要なく、おおよそや一部の用語で検索できることが、コンテンツを自力で見つけられるか、完全に諦めてしまうかの分かれ目になることがあります。

具体的な現実のシナリオとして、リウマチ性関節炎のあるユーザーが、キーボードのみのナビゲーションでトルコのECプラットフォームを利用している状況を想像してください。そのサイトのメガメニューは、サブカテゴリを表示するために精密なマウスホバー操作を必要とし、キーボードフォーカスの挙動も信頼できません。もしサイトが検索バーとサイトマップも提供していれば、そのユーザーは必要な商品ページを見つけることができます。これらの代替手段がなければ、そのサイトはそのユーザーにとって事実上利用不能であり、それは失われた顧客であると同時に、潜在的な法的リスクにもなります。

アクセシビリティにとどまらず、複数のナビゲーション手段は測定可能なSEOとユーザビリティの利点ももたらします。サイトマップは検索エンジンボットによるクロール性を向上させます。サイト内検索機能はユーザーエンゲージメントを高め、直帰率を下げます。構造化データとともに実装されたパンくずリストは、検索エンジン結果ページでのクリック率を改善します。これらの利点は、2.4.5への適合が単なるコンプライアンス対応ではなく、健全なウェブデザインの実践であることを意味します。

関連する axe-core のルール

WCAG 2.4.5は手動テストを必要とします。なぜなら、サイトが十分なナビゲーションの多様性を提供しているかどうかを、自動ツールが確実に判断することはできないからです。自動スキャナーは、特定の要素が存在し構文的に正しいかどうかは検証できますが、サイト全体のナビゲーション構造を評価したり、与えられた手段の組み合わせが実際に十分かどうかを判断したりすることはできません。以下の観点が手動評価の指針となります。

  • サイト検索の有無(手動チェック):自動ツールは、検索入力が機能しているか、有意義な結果を返すか、サイト全体で利用可能かを確認できません。テスターは、検索手段が存在し、キーボードで到達可能であり、代表的なクエリに対して関連性のある結果を返すことを手動で検証する必要があります。
  • サイトマップまたは代替ナビゲーション手段の有無(手動チェック):ツールは、サイトマップページが存在するか、すべてのページからリンクされているか、サイトコンテンツを包括的にカバーしているかを判断できません。人間のレビュアーが、主要ナビゲーション以外に少なくとも1つの追加手段が利用可能であり、アクセス可能であることを確認する必要があります。
  • ナビゲーションの一貫性(2.4.3および3.2.3に関連、手動チェック):自動ツールは、ページ間でコンポーネントの順序が不一致であることをフラグ付けできる場合がありますが、全体としてのナビゲーション戦略が、障害のあるユーザーにとって首尾一貫しており十分かどうかを判断することはできません。複数の代表的なページタイプにわたる手動レビューが必要です。
  • 二次的手段のアクセシビリティ(手動チェック):サイトマップや検索が存在していても、自動スキャンでは、それらの手段がキーボードでアクセスできない、スクリーンリーダー向けラベルが不十分である、あるいはユーザビリティに影響する形で視覚的に隠されているといった問題を検出できない場合があります。キーボードとスクリーンリーダーによる手動テストで、それぞれの手段がエンドツーエンドで機能することを確認しなければなりません。

テスト方法

  1. 自動スキャン — ベースラインの確立:サイトの代表的なページに対して axe DevTools または Lighthouse を実行します。どちらのツールも2.4.5の違反を直接フラグ付けすることはありませんが、監査結果を利用して、ラベル欠如、不適切なARIAロール、フォーカス管理の問題など、基盤となるアクセシビリティ問題を抱えたナビゲーションコンポーネント(メニュー、検索入力、パンくずリスト)を特定します。壊れたナビゲーション手段は2.4.5における有効な「手段」とは見なせないため、まずこれらを修正します。
  2. ナビゲーション手段のカタログ化:サイトを手動でレビューし、ユーザーが特定のページに到達するために利用できるあらゆる異なる手段を列挙します。トップナビゲーションメニュー、フッターリンク、サイト検索、サイトマップページ、パンくずリスト、関連コンテンツへのリンク、カテゴリインデックスなどです。逐次的なプロセスに属さないすべてのページで、これらのうち少なくとも2つの手段が存在し、機能し、利用可能であることを確認します。
  3. キーボードのみのナビゲーションテスト:Tab、Enter、矢印キー、Escキーのみを使用し(マウスは使用しない)、2つの異なる手段を使って特定の非ホームページに到達してみます。例えば、検索バーを使って商品ページを見つけ、その後サイトマップまたはナビゲーションメニューを使って同じページに到達します。どちらの経路もマウスなしで完全に操作可能であることを確認します。
  4. NVDA + Firefox によるスクリーンリーダーテスト:NVDAを起動し、Firefoxを立ち上げてホームページに移動します。NVDAのブラウズモード(ランドマーク用のF6、見出し用のH)を使って、検索ランドマークおよびサイトマップやナビゲーションリンクを探します。両方の手段が正しく読み上げられること、フォームフィールドにアクセシブルなラベルがあること、結果ページや遷移先ページが読み込まれ、読み取れることを確認します。
  5. VoiceOver + Safari(macOS/iOS)によるスクリーンリーダーテスト:VoiceOver(Cmd+F5)を有効にし、ローター(VO+U)を使ってページのフォームコントロールとリンクを確認します。検索フィールドが一覧に表示されラベル付けされていること、サイトマップや代替インデックスへ導くナビゲーションリンクが存在し、操作可能であることを確認します。
  6. JAWS + Chrome によるスクリーンリーダーテスト:JAWSのナビゲーションキー(フォームにジャンプするF、リンクリスト用のInsert+F7)を使って、検索入力およびサイトマップリンクが、キーボードと仮想カーソルの両方から見つけられ、利用できることを検証します。
  7. 逐次的プロセスの適用除外チェック:チェックアウト、多段階フォーム、ログインフローなど、プロセスのステップとなっているページを特定します。これらのページが複数手段要件を満たす必要がないことを確認します。誤った不適合判定を避けるため、アクセシビリティ監査にこの点を記録します。
  8. 検索結果の機能検証:商品名、記事タイトル、サポートトピックなど、いくつかの代表的な検索を実行します。結果が表示され、関連性があり、結果ページがキーボードとスクリーンリーダーでアクセス可能かつナビゲート可能であることを確認します。

修正方法

サイト検索がない — 不適切な例

<!-- Site only has a navigation menu; no search or sitemap provided -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>
<!-- No search, no sitemap link, no other navigation mechanism -->

サイト検索がない — 適切な例

<!-- Navigation menu retained, and a site search is added as a second mechanism -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>

<!-- Second navigation mechanism: accessible site search -->
<form role='search' action='/arama' method='get'>
  <label for='site-search'>Sitede Ara</label>
  <input
    type='search'
    id='site-search'
    name='q'
    placeholder='Ürün veya konu arayın...'
    aria-label='Site genelinde arama'
  />
  <button type='submit'>Ara</button>
</form>

アクセシブルでないサイトマップ — 不適切な例

<!-- Sitemap link is present but visually hidden and unreachable by keyboard -->
<footer>
  <a href='/site-haritasi' style='display:none;'>Site Haritası</a>
</footer>
<!-- display:none removes the element from both visual display AND
     the accessibility tree, so screen reader users cannot reach it.
     This sitemap cannot count as a valid second navigation mechanism. -->

アクセシブルでないサイトマップ — 適切な例

<!-- Sitemap link is visible and accessible to all users -->
<footer>
  <nav aria-label='Footer navigation'>
    <ul>
      <li><a href='/site-haritasi'>Site Haritası</a></li>
      <li><a href='/gizlilik'>Gizlilik Politikası</a></li>
      <li><a href='/iletisim'>İletişim</a></li>
    </ul>
  </nav>
</footer>
<!-- The sitemap page itself should list all major sections and pages
     of the site using <nav>, <ul>, and <a> elements. -->

アクセシブルなラベルのない検索フォーム — 不適切な例

<!-- Search input has no label; screen readers announce only 'edit text' -->
<form action='/search'>
  <input type='text' name='q' placeholder='Search...' />
  <button type='submit'><img src='search-icon.png' /></button>
</form>

アクセシブルなラベルのない検索フォーム — 適切な例

<!-- role='search' identifies the landmark; label associates text with input;
     submit button has an accessible name via aria-label -->
<form role='search' action='/arama' method='get'>
  <label for='global-search'>Arama</label>
  <input
    type='search'
    id='global-search'
    name='q'
    autocomplete='off'
  />
  <button type='submit' aria-label='Aramayı başlat'>
    <img src='search-icon.png' alt='' aria-hidden='true' />
  </button>
</form>

よくある間違い

  • XMLサイトマップをユーザー向けナビゲーション手段として数える:検索エンジンに送信されるXMLサイトマップ(例:/sitemap.xml)は機械可読ファイルであり、一般の訪問者は利用できません。人間が閲覧可能なHTMLサイトマップページだけが、有効な2つ目のナビゲーション手段として認められます。
  • 装飾的または壊れた検索フォームを提供する:常に空の結果しか返さない、送信時にエラーになる、404ページにリダイレクトされるといった検索入力は、2.4.5を満たしません。この手段は、基準をパスするために実際に機能していなければなりません。
  • JavaScriptの背後にサイトマップリンクを隠し、そのJavaScriptが失敗または無効化される:サイトマップへの唯一のリンクが、動的に挿入されるモーダル内や、特定の環境で動作しないJavaScript依存のドロップダウン内にある場合、そのJavaScriptを実行できないユーザー(特定の支援技術構成を含む)は、そのナビゲーション手段へのアクセスを失います。
  • モバイルビューポートでナビゲーション手段にdisplay:nonevisibility:hiddenを適用する:モバイルレイアウトで検索バーやサイトマップリンクを完全に隠すと、モバイルユーザーにとってその手段が完全に失われるため、不適合となります。デスクトップレイアウトが適合していても同様です。アクセシブルなトグルボタンの背後に折りたたむことは許容されますが、DOMやアクセシビリティツリーから削除することは許されません。
  • パンくずリストを追加の支援なしに単独で2つ目の手段として扱う:パンくずリストは現在のページへの経路だけを示すものであり、サイト上の任意のページを発見・ナビゲートするのに十分な手段とは言えません。他の手段を補完することはできますが、通常、それ単独で必要な2つの手段の1つとして扱うことはできません。
  • ページを誤って要件の適用除外とみなす:逐次的プロセスの適用除外は、チェックアウトの4ステップ中のステップ2のように、文字通りプロセスのステップであるページにのみ適用されます。カテゴリページ、商品詳細ページ、ブログ記事は、ユーザーがファネルを通じてそこに到達したとしても、適用除外にはなりません
  • type='text'の検索入力を使い、フォームにrole='search'を付けない:これは直接的な2.4.5違反ではありませんが、ランドマークをたどるスクリーンリーダーユーザーが検索領域を見つけられなくなります。この手段は技術的には存在していても、実質的には発見しにくくなり、達成基準の意図を損ないます。
  • 実質的に同一の2つの手段を提供する:まったく同じリンクをまったく同じ構造で含むトップナビゲーションメニューとフッターナビゲーションメニューは、意味のある異なる2つのナビゲーション手段とは見なされません。この意図は、異なるニーズを持つユーザーが代替戦略を見つけられるようにすることであり、同じ戦略をページ上に2回表示することではありません。
  • 特定のページタイプをナビゲーションシステムから除外する:一部のCMS構成では、ブログ記事、法的文書ページ、ユーザーアカウントページが、メインのサイトマップや検索インデックスの外に置かれることがあります。ユーザーがこれらのページを少なくとも2つの手段で見つけられない場合、サイトの他の部分がどれほどよく構造化されていても、それらのページは2.4.5に不適合となります。
  • 支援技術で手段をテストしない:2.4.5は手動テストを要求しているため、自動ツールのみに依存するチームは、検索フォーム内のキーボードトラップ、ラベルのない入力、DOM内には存在するがスクリーンリーダーのランドマークナビゲーションから到達できないサイトマップなどによる不適合を見逃すことになります。

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

2025年6月21日付官報(Resmî Gazete)第32933号で公布されたトルコ大統領通達第2025/10号は、幅広い公的・民間主体に対して拘束力のあるウェブアクセシビリティ義務を定めています。この通達は、国際的に認められたアクセシビリティ標準への適合を義務付け、トルコの法的要件をWCAG 2.1およびWCAG 2.2レベルAAと整合させ、これをベースラインの期待値としています。

WCAG 2.4.5「複数の手段」はレベルAAの達成基準であり、したがって通達が要求する適合レベルのど真ん中に位置します。規制の対象となる主体は、この達成基準で説明されているとおり、集合に属するすべてのウェブページが少なくとも2つのナビゲーション手段を提供していることを確保しなければなりません。この要件を満たさないことは、規制上の義務に直接反する不適合となります。

大統領通達2025/10号の対象となる主体には、あらゆるレベルの公的機関・政府機関、銀行・金融機関、病院・医療提供者、電子商取引プラットフォーム、20万以上の加入者を持つ通信事業者、旅行代理店、民間輸送会社、国民教育省(Millî Eğitim Bakanlığı, MEB)の認可を受けて運営される私立学校が含まれます。これらの各主体は、それぞれのウェブ資産において、アクセシブルで複数経路のナビゲーションを維持することが求められます。

必須の適合要件に加え、家族・社会サービス省(Aile ve Sosyal Hizmetler Bakanlığı)は、優れたアクセシビリティ実践を示す組織にErişilebilirlik Logosu(アクセシビリティロゴ)を付与しています。このロゴを取得するには、2.4.5への適合を含むレベルAAへの完全な適合が必要です。トルコの競争の激しいデジタル市場で事業を行う企業、特にECプラットフォーム、銀行、医療提供者にとって、このアクセシビリティロゴは、障害のあるユーザーへの信頼の証であると同時に、規制遵守への誠実な取り組みを示す証拠にもなります。

実務的に言えば、多様なユーザー層にサービスを提供するトルコのウェブサイトは、複数のナビゲーション手段を実装することで大きな恩恵を受けます。トルコには高齢のインターネットユーザーやデジタルリテラシーの低い地域のユーザーが多く、両者とも2.4.5が義務付ける冗長性の恩恵を受けます。トルコ語特有の文字(ı, İ, ş, ğ, ü, ö, ç など)を正しく扱うトルコ語対応のサイト検索と、明確に構造化されたHTMLサイトマップを組み合わせることは、このユーザー層にとって有用で、かつ規制に適合したアクセシブルな実装となります。Erişilebilirlik Logosuの取得または維持を目指す組織は、2.4.5への適合を任意の改善ではなく、アクセシビリティプログラムの基盤となる要件として扱うべきです。