WCAG 2.4.8: 位置

このルールの意味

WCAG 2.4.8 Location は、Operable（操作可能）という原則の下にあるレベルAAAの達成基準です。そこでは次のように述べられています。「一連のウェブページの中で、ユーザーが現在どこにいるかに関する情報が利用できる。」 実務的には、これは「サイト全体の構造の中で、ユーザーが今どこにいるのか」を常に明確に示す、わかりやすく持続的な手がかりをウェブサイトが提供しなければならない、という意味です。

この達成基準は、ウェブサイトが意味のある階層や順序で構成された複数のページから成る場合に適用されます。たとえば、カテゴリ・サブカテゴリ・商品ページを持つECサイトや、部局や下位セクションを持つ政府ポータルなどです。ユーザーがあるページに到達したとき、「このサイトの中で自分はどこにいるのか？」という問いに、推測や記憶だけに頼らずに答えられる必要があります。

この達成基準を満たすために許容される手法には、次のようなものが含まれますが、これらに限定されるものではありません。

• パンくずリスト（Breadcrumb trail） — サイトのホームページから現在のページまでの経路を示すナビゲーション補助（例: Home > Products > Laptops > 15-inch Models）。
• サイトマップ — サイト全体の構造を表示し、現在位置を強調またはマークする専用ページまたはパネル。
• 強調表示された、または視覚的に区別されたナビゲーションリンク — アクティブなセクションやページを明確に示すナビゲーションメニュー。多くの場合、支援技術ユーザー向けに aria-current 属性を併用します。
• 複数ステップのプロセスにおける番号付きステップ — チェックアウトやフォームウィザードで「Step 2 of 5」のように、順序上の位置を伝えるインジケーター。

ページは、サイト構造の中でユーザーの現在位置を知らせる信頼できる仕組みが少なくとも1つ存在すれば、この達成基準に合格します。逆に、ナビゲーションバーに現在ページを示す視覚的・プログラム的な手がかりがなく、パンくずもステップインジケーターもない場合など、そうした仕組みが一切存在しなければ不合格となります。

WCAG 2.4.8 は特定の手法を義務付けているわけではなく、何らかの有効な位置インジケーターが存在することを求めています。ただし、そのインジケーターが真にアクセシブルであるためには、視覚的に見えるだけでなく、スクリーンリーダーなどの支援技術からも知覚できなければなりません。つまり、太字リンクのような純粋に視覚的なインジケーターで、アクセシブルネームの変化がなくプログラム的にも露出していない場合、それ単体では不十分となる可能性があります。

この達成基準について、WCAG が公式に設けている例外は、「関連するページの集合に適用される」という一般的な理解を超えるものはありません。より大きな集合の一部ではない単一の独立したウェブページについては、「集合の中での位置」を伝える必要がないため、この達成基準を満たす必要はありません。

なぜ重要か

デジタル環境の中で自分がどこにいるかを把握することは、ほとんどのユーザーが当たり前のように享受している基本的な「見当識」のニーズです。しかし、その手がかりが欠けた途端に問題が顕在化します。WCAG 2.4.8 は、いくつかの異なるユーザーグループが直面している、現実的で広く見られるバリアに対処するものです。

認知障害のあるユーザーは、その中でも特に大きな影響を受けるグループです。注意欠如障害、記憶障害、脳損傷などの状態があると、複雑なサイト内で自分のたどった経路を追跡することが難しくなります。パンくずや類似の手がかりがなければ、ユーザーは方向感覚を失い、親カテゴリに戻る方法がわからなくなったり、現在のページがすでに見たコンテンツとどう関係しているのか理解できなくなったりします。世界保健機関（WHO）によれば、世界で10億人以上が何らかの障害とともに生活しており、その中で認知障害は重要でありながらしばしば十分に支援されていない部分を占めています。

スクリーンリーダーユーザー — 通常は全盲またはロービジョンのユーザー — は、ページの文脈を理解するためにプログラム的な構造に大きく依存しています。視覚ユーザーは、強調表示されたナビゲーションリンクや太字のパンくず項目を一目見れば、瞬時に自分の位置を把握できます。これに対しスクリーンリーダーユーザーは、ページを逐次的な音声出力として解釈しなければなりません。アクティブなナビゲーションリンクに aria-current="page" 属性が付与されていなかったり、適切に構造化されラベル付けされたパンくずが存在しなかったりすると、同等の見当識の手がかりを得られず、自分の位置を把握するためだけに広範なナビゲーションを強いられることがあります。

運動障害のあるユーザーで、キーボード、スイッチアクセス、視線入力デバイスなどで操作する人々も、位置インジケーターによって恩恵を受けます。これにより、重複した負担の大きいナビゲーションを減らせるからです。たとえば、ユーザーがすでに企業サイトの「Support」セクションにいることがわかっていれば、新しいページを読み込むたびにナビゲーション全体を再度スキャンする必要はありません。

具体的なシナリオを考えてみましょう。初期の認知症があるユーザーが、住宅ローン金利の情報を探すためにトルコの銀行のオンラインポータルを閲覧しています。いくつかのページをクリックしていくうちに、自分がまだ個人向けバンキングのセクションにいるのか、それとも法人向けバンキングのエリアに迷い込んでしまったのか、わからなくなってしまいます。現在のセクションを明確に示すパンくずやハイライトされたナビゲーション項目がなければ、そのユーザーは苛立ってブラウザを閉じてしまったり、誤った商品に申し込むといった高くつくミスを犯したりするかもしれません。シンプルで適切に実装されたパンくず（例: Ana Sayfa > Bireysel Bankacılık > Krediler > Konut Kredisi）があれば、この混乱はすぐに解消されます。

アクセシビリティの観点を超えても、位置インジケーターは測定可能なユーザビリティとSEOのメリットをもたらします。Schema.org の BreadcrumbList を用いたパンくずの構造化データは、Google の検索結果にリッチスニペットとして直接表示され、クリック率の向上につながります。また、明確なサイト構造は直帰率の低下にも寄与します。自分の位置を理解しているユーザーは、サイトを離脱するのではなく、関連コンテンツを探索しやすくなるからです。

関連する Axe-core のルール

WCAG 2.4.8 は、ロケーションの仕組みが存在し、意味があり、あらゆる文脈でアクセシブルかどうかを自動ツールが確実に判断できないため、手動テストが必要です。この達成基準に直接対応する axe-core のルールは存在しません。ここでは、自動化が不十分となる理由と、手動評価でカバーすべき点を示します。

• ロケーションの仕組みの有無（手動） — 自動スキャナーは、DOM 内にパンくず要素が存在するかどうかを検出できますが、そのパンくずがサイトの実際の情報アーキテクチャを正しく反映しているか、集合内のすべてのページに配置されているか、そのサイトのナビゲーションモデルにとって適切な種類の位置インジケーターであるかまでは判断できません。ツールは <nav aria-label="breadcrumb"> 要素を見つけて問題なしと報告するかもしれませんが、そのパンくずが一部のページにしか表示されていなかったり、誤った階層情報を含んでいたりする可能性があります。
• 正確性と完全性（手動） — 自動ツールは、位置情報が正確かどうかを検証できません。実際の階層に関係なく常に「Home > Current Page」とだけ表示するパンくずは、自動スキャンでは合格してしまうかもしれませんが、ページ集合内でのユーザーの位置を正しく表していないため、この達成基準には不合格となります。
• プログラム的な露出（部分的に自動） — axe-core は、設定によってはナビゲーションリンクに aria-current 属性が欠けていることを指摘できますが、サイト全体の構造や各ナビゲーション要素の役割を理解しない限り、aria-current の欠如が 2.4.8 の違反に当たるかどうかを最終的に判断することはできません。
• ページ集合全体での一貫性（手動） — ロケーションの仕組みは、関連するページ集合全体で利用可能でなければならず、一部のページだけに存在していればよいわけではありません。自動スキャンは通常1ページずつ評価するため、サイト全体やセクション全体で仕組みが一貫して存在するかどうかを評価することはできません。

テスト方法

1. ページ集合を特定する: テスト対象のページが、定義された階層（例: 多階層ナビゲーション構造、ステップバイステップのウィザード、カテゴリ分けされたコンテンツライブラリなど）を持つ関連ページの集合に属しているかどうかを判断します。ページが単独のドキュメントである場合、この達成基準は適用されない可能性があります。
2. 自動スキャンをベースラインとして実行する: axe DevTools（ブラウザ拡張）や Chrome DevTools の Lighthouse を使ってアクセシビリティ監査を実行します。どちらのツールも 2.4.8 を直接監査するわけではありませんが、ナビゲーションリンクの aria-current 属性の欠如、ラベル付けされていない <nav> ランドマーク、パンくず構造の欠如など、関連する問題を確認します。これらの結果は手動レビューを補完するものであり、代替するものではありません。
3. ロケーションの仕組みを目視で確認する: パンくずリスト、ハイライトされたまたは視覚的に区別されたアクティブリンク、ステップカウンター、サイトマップへのリンクなどを探します。その仕組みが、現在のページのサイト階層における位置を正確に反映しているか確認します。
4. スクリーンリーダーでテストする — NVDA + Firefox: NVDA を起動し、ページに移動してから D キーを押してランドマークを順にたどります。ナビゲーションランドマークを見つけ、現在のページまたはセクションを示す情報が読み上げられるか確認します。アクティブなナビゲーション項目が（通常は aria-current="page" によって）「current page」などと異なる形でアナウンスされるかどうかをチェックします。パンくずがある場合はそれをたどり、各レベルがリンクテキストとともに読み上げられ、現在位置が明確に識別されるか確認します。
5. VoiceOver + Safari（macOS/iOS）でテストする: VoiceOver（Command + F5）を有効にし、VO + U でローターを開いて「Links」または「Landmarks」を選択し、パンくずまたはメインナビゲーションに移動します。アクティブなナビゲーション項目やパンくずの現在項目がどのように読み上げられるかを確認します。現在位置が他のナビゲーション項目と区別できるか検証します。
6. JAWS + Chrome でテストする: Insert + F7 でリンクリストを、Insert + F6 で見出しリストを開きます。パンくずまたはナビゲーション領域に移動し、現在のページまたはセクションがプログラム的に識別可能か確認します。aria-current が読み上げられるか（JAWS は該当要素について「current」とアナウンスします）をチェックします。
7. 集合内の複数ページでテストする: 同じセクションまたは階層内の少なくとも3〜5ページを移動し、ロケーションの仕組みが各ページで正しく更新され、集合全体を通じて一貫して存在することを確認します。
8. DOM を検査する: ブラウザの DevTools を使って、パンくずリンクにわかりやすいアクセシブルネームが付いているか、現在項目に（現在のページには aria-current="page"、プロセスの現在ステップには aria-current="true"）が使われているか、パンくずが aria-label="Breadcrumb" のようなアクセシブルラベルを持つ <nav> 要素でラップされているかを確認します。

修正方法

パンくずナビゲーションがない — 不適切な例

<!-- No breadcrumb or location indicator present.
     Users have no way to determine their location in the site hierarchy. -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/products/laptops'>Laptops</a></li>
  </ul>
</nav>
<h1>15-inch Laptops</h1>

パンくずナビゲーションがない — 適切な例

<!-- A breadcrumb nav is added above the main content.
     aria-label distinguishes it from main navigation.
     aria-current="page" marks the current location for screen readers.
     The list structure communicates hierarchy. -->
<nav aria-label='Breadcrumb'>
  <ol>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/products/laptops'>Laptops</a></li>
    <li><a href='/products/laptops/15-inch' aria-current='page'>15-inch Laptops</a></li>
  </ol>
</nav>
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/products/laptops'>Laptops</a></li>
  </ul>
</nav>
<h1>15-inch Laptops</h1>

プログラム的インジケーターのないアクティブナビゲーションリンク — 不適切な例

<!-- The active link is styled differently in CSS, but there is no
     programmatic signal. Screen reader users cannot distinguish it
     from the other navigation links. -->
<nav aria-label='Site navigation'>
  <ul>
    <li><a href='/about'>About</a></li>
    <li><a href='/services' class='active'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

プログラム的インジケーターのないアクティブナビゲーションリンク — 適切な例

<!-- aria-current="page" is added to the active link.
     Screen readers will announce this link as "current" or "current page"
     depending on the assistive technology, giving users a clear
     programmatic location signal in addition to the visual styling. -->
<nav aria-label='Site navigation'>
  <ul>
    <li><a href='/about'>About</a></li>
    <li><a href='/services' class='active' aria-current='page'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

ステップインジケーターのない複数ステップフォーム — 不適切な例

<!-- A multi-step checkout form with no indication of current step.
     Users cannot determine how far they are through the process
     or how many steps remain. -->
<form>
  <h1>Shipping Information</h1>
  <!-- form fields -->
  <button type='submit'>Next</button>
</form>

ステップインジケーターのない複数ステップフォーム — 適切な例

<!-- A progress indicator communicates the user's position in the sequence.
     aria-label on the nav provides context.
     aria-current="step" marks the active step for assistive technologies.
     The visible text "Step 2 of 4" is also available for all users. -->
<nav aria-label='Checkout progress'>
  <ol>
    <li><a href='/checkout/cart'>Cart</a></li>
    <li aria-current='step'><strong>Shipping</strong></li>
    <li>Payment</li>
    <li>Confirmation</li>
  </ol>
</nav>
<form>
  <h1>Shipping Information <span>(Step 2 of 4)</span></h1>
  <!-- form fields -->
  <button type='submit'>Next: Payment</button>
</form>

よくある間違い

• ホームページだけ、または末端ページだけにパンくずを提供する: パンくずは集合内のすべてのページで一貫して表示されなければなりません。商品詳細ページにだけ表示し、カテゴリページには表示しないといった実装は、見当識情報に抜けを生じさせます。
• 視覚的にスタイルされたアクティブリンクを使いながら aria-current="page" を追加しない: 太字や下線付きのアクティブナビゲーションリンクは視覚的には位置を伝えますが、aria-current="page" がその要素に付与されていない限り、スクリーンリーダーユーザーには何のメリットもありません。
• パンくずを <nav> 要素ではなく <div> でラップする: 非セマンティックなコンテナを使うと、パンくずがナビゲーションランドマークとして露出されず、スクリーンリーダーユーザーが見つけて解釈するのが難しくなります。
• メインナビゲーションランドマークも存在するのに、パンくずの <nav> に aria-label を付けない: 同じページにラベルのない <nav> ランドマークが2つあると曖昧さが生じます。スクリーンリーダーはどちらも単に「navigation」とアナウンスする可能性があり、ユーザーはそれらを区別できません。
• ページリンクに aria-current="page" ではなく aria-current="true" を使う: ナビゲーションの文脈で現在のページを識別するには、値 page がセマンティックに正しい値です。true を使うと意味が曖昧になり、支援技術によっては異なる、あるいは不明瞭な形でアナウンスされる可能性があります。
• 位置を示す手段としてページタイトルだけに頼る: 「Laptops — 15-inch Models | Acme Store」のような説明的な <title> 要素は有用であり、WCAG 2.4.2 によっても求められていますが、それだけでは 2.4.8 を満たしません。2.4.8 は、現在のページ名だけでなく、ページ集合の構造の中での位置を伝える仕組みを要求しています。
• URL 構造を反映したパンくずを作り、ナビゲーション階層を反映しない: URL とナビゲーション構造は必ずしも一致しません。パンくずは、ユーザーが理解できる論理的な情報アーキテクチャを反映すべきであり、技術的でわかりにくい場合もある基盤の URL パスをそのまま反映すべきではありません。
• 祖先レベルをリンクにせず、パンくずをプレーンテキストとして表示する: 現在ページだけが表示されていたり、祖先レベルがリンクになっていなかったりすると、パンくずは位置インジケーターとしてだけでなくナビゲーション補助としての有用性も失います。祖先項目にはリンクを付け、ユーザーが階層をさかのぼれるようにすべきです。
• パンくずの現在項目を aria-current ではなく視覚的な区切りの変更だけで示す: 最後のパンくず項目の色を変えたり下線を外したりしても、それが現在ページを表していることはスクリーンリーダーには伝わりません。aria-current="page" を明示的に追加する必要があります。
• シングルページアプリケーション（SPA）でクライアントサイドナビゲーション後に位置インジケーターを更新し忘れる: React や Vue などのフレームワークで構築された SPA では、ページ遷移がブラウザの完全なリロードなしに行われます。ルート変更時にパンくずやアクティブナビゲーションインジケーターがプログラム的に更新されないと、位置情報が古いまま表示されてしまい、インジケーターがない場合よりも状況が悪化します。

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

トルコの大統領通達 2025/10 は、2025年6月21日付官報第32933号で公布され、トルコで事業を行う幅広い組織に対して、ウェブおよびモバイルのアクセシビリティ要件を法的拘束力のある形で定めています。この通達は、国際的に認められたアクセシビリティ標準への準拠を義務付けており、事実上 WCAG フレームワークを採用しています。また、対象となる主体として、公的機関・行政機関、ECプラットフォーム、銀行・金融機関、病院・医療提供者、20万件以上の加入者を持つ通信会社、認可旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された私立学校などを定義しています。

WCAG 2.4.8 Location はレベルAAAの達成基準として分類されており、通達が最低限の基準として参照しているレベルAおよびレベルAAの達成基準には含まれていません。しかし、この区別は、規制の対象となる組織にとっていくつかの重要な点で意味を持ちます。

第一に、特に高齢者向け医療ポータルや学習障害のある学生向け教育プラットフォームなど、認知面やナビゲーション面で大きな課題を抱えるユーザーにサービスを提供する特定の専門サービスでは、トルコ法および障害者法第5378号など関連法令に基づくアクセシビリティ義務の趣旨を真に満たすために、AAのベースラインを超えることが期待される場合があります。こうした文脈で 2.4.8 を実装することは、形式的な対応にとどまらない、実質的なインクルージョンへのコミットメントを示すものです。

第二に、トルコの公的機関および規制対象の民間事業者は、監査や苦情処理の仕組みにさらされる機会が増えています。WCAG 2.4.8 を含むレベルAAAの準拠を示すことは、ベストプラクティスを実装しているという防御可能な記録となり、正式なアクセシビリティ苦情があった場合の規制リスクを軽減します。

第三に、特にECプラットフォームや銀行にとって、パンくずなどの位置インジケーターはアクセシビリティ機能であると同時に、直接的な商業的価値を持ちます。明確なステップインジケーターとパンくずナビゲーションを備えたトルコの銀行のオンライン住宅ローン申込プロセスは、認知障害のあるユーザーにとってより利用しやすくなるだけでなく、離脱率を下げ、コンバージョンを支援します。これは、アクセシビリティへの投資を測定可能なビジネス成果と結びつけるものです。

Accsible overlay SDK を利用している組織は、組み込みのパンくず強化機能や aria-current 付与機能を活用することで、既存サイトを全面的なコードベースのリファクタリングなしに 2.4.8 への準拠に近づけることができます。しかし、完全かつ堅牢な準拠 — 特に大統領通達 2025/10 の対象となる主体にとっては — を実現するには、セマンティックなパンくずマークアップやナビゲーションインジケーターをサーバーサイドまたはビルド時に実装することが推奨されます。オーバーレイソリューションは基盤となるアクセシブルなマークアップを補完するものであり、それに取って代わるものではないからです。