WCAG 3.2.6: 一貫したヘルプ

この規定が意味すること

WCAG 達成基準 3.2.6 一貫したヘルプ（レベル AA、WCAG 2.2 で追加）は次のように定めています。「ウェブページに以下のヘルプメカニズムのいずれかが含まれ、そのメカニズムが複数のウェブページで繰り返し使用されている場合、利用者によって変更が開始されない限り、それらは他のページコンテンツに対して同じ相対的な順序で配置される。」 この達成基準が対象とするヘルプメカニズムは、人的な連絡先情報（電話番号、メールアドレス、営業時間など）、人的な連絡手段（ライブチャットウィジェットや問い合わせフォームなど）、セルフヘルプの選択肢（FAQ ページ、ヘルプセンター、ナレッジベースなど）、そして完全に自動化された連絡手段（チャットボットやバーチャルアシスタントなど）です。

重要なのは、相対的な順序の一貫性であり、ピクセル単位で同じ位置にあることではありません。たとえば、ライブチャットボタンがホームページの右下に表示されている場合、それを表示する他のすべてのページでも同じ右下の位置に表示されなければなりません。「ヘルプ」リンクがあるページのトップナビゲーションバーで 3 番目の項目であるなら、そのナビゲーションバーが表示される他のすべてのページでも 3 番目の項目のままであるか、少なくとも周囲のコンテンツとの相対的な関係を維持しなければなりません。

ページがこの達成基準に適合するのは、(a) サイトにヘルプメカニズムが存在しない場合、または (b) ヘルプメカニズムが 1 ページのみに存在する場合、または (c) ヘルプメカニズムが複数ページに繰り返し表示される場合には、ページレイアウト内で同じ相対的な順序で表示される場合です。ページが不適合となるのは、複数ページに存在するヘルプメカニズムが、利用者による変更の開始なしに、ページごとにページ内の順序が変わってしまう場合です。たとえば、商品一覧ページでは右下に浮遊しているチャットウィジェットが、チェックアウトページでは左下に移動しているようなケースです。

この達成基準には明示的な例外が含まれています。利用者が変更を開始した場合は順序を変更してもよい、というものです。たとえば、利用者が浮遊するヘルプウィジェットをドラッグして位置を変えた場合や、利用者の設定でヘルプパネルを片側から反対側に切り替えた場合、その再配置は利用者が開始したものであり、不適合にはなりません。この例外は、SC 3.2.2（入力時）に見られる「利用者が開始した変更」という同じ考え方を反映しています。

この達成基準は、すべてのページにヘルプメカニズムを設置することを要求しているわけではなく、またヘルプメカニズムが有効であることや使いやすいことを求めているわけでもありません。複数ページにヘルプメカニズムが存在する場合に、その位置の一貫性を管理することだけを求めています。

なぜ重要なのか

ヘルプの一貫した配置は、主に認知障害のある利用者のために設計されています。ここには、記憶障害、注意力の問題、ディスレクシアのような学習障害、ADHD や初期の認知症などの状態を持つ人々が含まれます。これらの利用者にとって、見慣れたインターフェース要素を見つけることは意識的な認知的努力を要します。ヘルプボタンや連絡リンクがページごとに異なる場所に現れると、そのたびに同じ努力を繰り返さなければならず、認知負荷やフラストレーション、混乱、タスク放棄のリスクが高まります。

ウェブに不慣れな利用者やデジタルリテラシーが限られている利用者 — これはトルコおよび世界全体で重要な人口集団です — も、予測可能な配置に大きく依存しています。世界保健機関によると、世界で 13 億人以上が何らかの障害とともに生活しており、その中で認知・神経系の状態が大きな割合を占めています。したがって、位置の一貫性を考慮した設計は、臨床的に診断された障害のある人々をはるかに超えた幅広い利用者層に役立ちます。

具体的なシナリオを考えてみましょう。初期のアルツハイマー病のある利用者が、オンラインで航空券の予約を完了しようとしています。彼女は、混乱したときに利用できるライブチャットオプションが航空会社のサイトにあることを覚えています。検索結果ページでは、チャットアイコンは右下に表示されています。しかし座席選択ページに移動すると、チャットウィジェットは折りたたみ式のヘルプドロワー内の右上に移動しています。彼女はそれを見つけられず、圧倒されて予約を完全に諦めてしまいます。これは SC 3.2.6 の直接的で防ぎ得た不適合です。

運動障害のある利用者で、スイッチアクセス、視線入力ソフトウェア、ヘッドポインタなどで操作している人にとって、ヘルプメカニズムの位置が変わることは、画面上の新しい領域を再スキャンし、再度ターゲットにすることを意味します。これは負担が大きく時間のかかるプロセスであり、一貫した配置によってその負担を取り除くことができます。

スクリーンリーダー利用者で、ヘルプセクションに素早く到達するためにサイトのタブ順序や見出し構造を記憶している人も、ヘルプメカニズムの DOM 順序がページごとに変わると同様に影響を受けます。たとえ視覚的な位置が似て見えたとしても同じです。

アクセシビリティを超えて、ここには明確なユーザビリティおよびビジネス上の利点もあります。利用者がヘルプをすばやく見つけられれば、取引を途中で放棄する可能性が低くなり、離脱率やサポートコストの削減につながります。一貫した UI パターンは、ブランドへの信頼やプロフェッショナリズムの印象も強化します。

関連する Axe-core のルール

WCAG 3.2.6 は、手動テストのみが必要と分類されており、違反をプログラム的に検出できる対応する自動 axe-core ルールは存在しません。これは意図的なものであり、その理由を理解することで、テスターはこの達成基準の性質をよりよく把握できます。

• 手動確認が必須 — axe ルールは存在しない: axe-core、Lighthouse、IBM Equal Access Checker のような自動ツールは、単一ページを個別に解析します。これらには「ヘルプメカニズム」とは何かについての固有の理解がなく、要素の相対的な DOM 位置を複数のページ読み込みや URL をまたいで比較する能力もなく、特定の要素がヘルプを提供する機能的役割を担っているかどうかを判断する手段もありません。たとえばチャットウィジェットは、単なる <div>、shadow DOM コンポーネント、<iframe>、あるいはサードパーティのインジェクトスクリプトとして実装されているかもしれませんが、これらはいずれも、人間の判断なしにルールエンジンが確実に「ヘルプメカニズム」と特定できるものではありません。これを検出するには、axe-core はページをまたいだ状態の把握と意味的な意図の認識が必要になりますが、これは単一ページの静的解析の範囲を超える能力です。このため WCAG 2.2 自体が 3.2.6 を、人間による構造化された手動監査とページ間比較を必要とする達成基準として位置づけています。

テスト方法

1. ヘルプメカニズムの棚卸し: 個々のページをテストする前に、サイト上に存在するすべてのヘルプメカニズム — ライブチャットウィジェット、連絡用電話番号、メールリンク、FAQ リンク、チャットボットのランチャー、問い合わせフォーム、ヘルプセンターへのリンクなど — の一覧を作成します。それぞれのメカニズムがどのページに表示されるかを記録します。あるメカニズムが 1 ページのみに表示される場合、そのメカニズムはこの達成基準の対象外です。
2. 自動スキャンでベースラインの文脈を取得: axe DevTools（ブラウザ拡張）や Lighthouse を代表的なページで使用し、DOM 順序のスナップショットを取得して、ヘルプ関連要素の構造上の位置を特定します。SC 3.2.6 を直接対象とする axe ルールはありませんが、これらのツールが報告する DOM 順序はページ間で手動比較できます。ヘルプメカニズムを含む各ページについて、アクセシビリティツリーをエクスポートするかスクリーンショットを取得します。
3. ページ間で相対位置を比較: 同じヘルプメカニズムを共有する 2 ページ以上を並べて（または順番に）開きます。各メカニズムについて、周囲のランドマーク領域（<header>、<main>、<footer>、<nav>）との関係における位置を特定します。すべてのページで、そのメカニズムが同じランドマーク領域内にあり、同じ相対的な順序（隣接要素の前後関係）で現れているかを記録します。位置の変化は潜在的な不適合を意味します。
4. キーボード操作でテスト（全ブラウザ）: ヘルプメカニズムを含む各ページで Tab キーを使ってフォーカスを移動します。ページの先頭からヘルプメカニズムに到達するまでに必要なタブストップの数を数えます。この数をページ間で比較します。たとえば、ホームページでは 5 回の Tab で到達できるのに、チェックアウトページでは 47 回必要な場合、視覚的な位置が似て見えても DOM 順序が変化していることを示します。
5. NVDA + Firefox でテスト: NVDA の要素リスト（NVDA キー + F7）を開き、リンクまたはボタンのビューに切り替えます。リスト内でヘルプメカニズムを探し、その位置を他の要素との相対関係として記録します。そのメカニズムが表示される各ページで同じ操作を繰り返し、位置を比較します。
6. VoiceOver + Safari（macOS/iOS）でテスト: VoiceOver ローター（VO + U）を使ってリンクまたはフォームコントロールのリストを開きます。ヘルプメカニズムまで移動し、リスト内での位置を記録します。ページ間で比較します。
7. JAWS + Chrome でテスト: JAWS のリンクリスト（Insert + F7）を使ってヘルプメカニズムを探します。その序数上の位置と隣接要素を記録します。メカニズムが表示される各ページで繰り返し、位置を比較します。
8. 利用者が開始した例外を確認: サイトがヘルプメカニズムの再配置や非表示を利用者に許可している場合（例: ドラッグ可能なチャットウィジェット）、その再配置が明示的な利用者操作によって開始されていること、またその設定が論理的に保持されていることを確認します。これはこの達成基準における有効な例外として文書化します。
9. モバイルビューポートで確認: レスポンシブレイアウトでは、ブレークポイントによって DOM 要素の順序が変わることがあります。デスクトップとモバイルの両方のビューポート（最低でも幅 375px と 1440px）でテストし、一般的な画面サイズすべてでヘルプメカニズムの相対的な配置が一貫していることを確認します。

修正方法

浮遊チャットウィジェット — 不適切な例

<!-- Page A (homepage): chat button in bottom-right -->
<div class='chat-widget' style='position:fixed; bottom:20px; right:20px;'>
  <button>Chat with Us</button>
</div>

<!-- Page B (checkout): chat button moved to bottom-left -->
<div class='chat-widget' style='position:fixed; bottom:20px; left:20px;'>
  <button>Chat with Us</button>
</div>
<!-- FAIL: The widget changes its fixed position between pages,
     breaking consistent help placement. -->

浮遊チャットウィジェット — 適切な例

<!-- Both Page A and Page B: chat button consistently in bottom-right -->
<div class='chat-widget chat-widget--bottom-right'>
  <button type='button' aria-label='Open live chat support'>
    Chat with Us
  </button>
</div>
<!-- PASS: The widget appears in the same corner on every page.
     Use a CSS class defined in a shared stylesheet rather than
     inline styles, so the position is controlled centrally and
     applied consistently across all templates. -->

ナビゲーション内のヘルプリンク — 不適切な例

<!-- Page A: Help is the 4th nav item -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>

<!-- Page B (product detail): Help link removed from nav,
     placed in a footer section instead -->
<footer>
  <a href='/help'>Help Center</a>
</footer>
<!-- FAIL: The Help link has moved from the main navigation
     to the footer, changing its relative order significantly. -->

ナビゲーション内のヘルプリンク — 適切な例

<!-- Both Page A and Page B share the same navigation template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>
<!-- PASS: The Help link is the 4th item in the main nav
     on every page where the nav is present. Using a shared
     navigation component or server-side include ensures
     this is maintained automatically. -->

条件付きヘルプ表示 — 不適切な例

<!-- On logged-out pages: phone number in header -->
<header>
  <p>Need help? Call <a href='tel:+908501234567'>0850 123 45 67</a></p>
</header>

<!-- On logged-in pages: phone number removed from header,
     only available deep inside an account dropdown menu -->
<header>
  <nav aria-label='Account menu'>
    <details>
      <summary>My Account</summary>
      <ul>
        <li><a href='/orders'>Orders</a></li>
        <li><a href='/contact'>Contact: 0850 123 45 67</a></li>
      </ul>
    </details>
  </nav>
</header>
<!-- FAIL: The contact number changes its relative position
     dramatically depending on authentication state,
     making it unpredictable for returning users. -->

条件付きヘルプ表示 — 適切な例

<!-- Both logged-out and logged-in pages: phone in the same header position -->
<header>
  <div class='header-support'>
    <a href='tel:+908501234567' aria-label='Call support: 0850 123 45 67'>
      <svg aria-hidden='true' focusable='false'><!-- phone icon --></svg>
      0850 123 45 67
    </a>
  </div>
  <nav aria-label='Account menu'>
    <!-- account links here -->
  </nav>
</header>
<!-- PASS: The contact mechanism is always in the same position
     within the header regardless of authentication state.
     Additional account-specific links can appear elsewhere
     without moving the help mechanism. -->

よくある間違い

• ページテンプレートごとにチャットウィジェットを異なるコーナーに配置する: 開発チームが、チャットウィジェットの固定位置をグローバルなスタイルシートではなくテンプレートごとに設定してしまい、マーケティングページでは右下、アプリページでは左下に表示されることがあります。位置を固定したクラスを持つ単一のグローバルコンポーネントを使用してください。
• チェックアウトページでナビゲーションからヘルプリンクを削除して要素数を減らす: 一部の UX パターンでは、コンバージョン最適化のためにチェックアウトページのナビゲーションを意図的に削ぎ落とします。ヘルプメカニズムがそのナビゲーションの一部である場合、このページテンプレートから削除すると一貫性が損なわれます。代わりに、チェックアウトフローが簡素化されていても、最小限のヘッダー内にヘルプリンクを残してください。
• DOM 上の位置が予測できないサードパーティスクリプトでヘルプメカニズムをインジェクトする: 多くのライブチャット SDK はウィジェットを非同期に DOM に挿入し、スクリプトの読み込み順序によって挿入位置が変わることがあります。その結果、ページごとにアクセシビリティツリー上の位置が変わることがあります。サードパーティウィジェットは、常に固定された既知の DOM アンカー要素に追加されるように設定してください。
• CSS の order や flexbox/grid の並び替えで DOM 順序を変えずにヘルプ要素の視覚的な位置を動かし、さらにページごとにその CSS を変える: 視覚的な位置が一貫しているように見えても、ページごとにヘルプメカニズムの視覚的順序を変える CSS を上書きすると、ユーザーが知覚する順序は変化します。読み上げ順序が DOM に従うスクリーンリーダー利用者にとって混乱の原因となります。
• ヘルプ要素の位置を入れ替える A/B テストツールに依存する: バリアント A の利用者にはヘルプボタンがトップバーに、バリアント B の利用者にはフッターに表示される場合、A/B フレームワークがページごとに異なるバリアントを適用すると、同一セッション内でヘルプの位置が一貫しない体験になります。ヘルプメカニズムの配置に影響する A/B テストは、セッション内のすべてのページで同じバリアントが適用されるようにしてください。
• 認証済み状態と未認証状態を別の「サイト」とみなし、異なるヘルプレイアウトを適用する: 利用者がセッションの途中でログインすると、ヘルプメカニズムが突然別の場所に移動してしまうことがあります。認証状態の変化は、ヘルプ配置の文脈では利用者が開始した変更とはみなされないため、これは依然として SC 3.2.6 の不適合です。すべての認証状態にわたって一貫したヘルプレイアウトを適用してください。
• 一部のページではヘルプの電話番号をフッターの密集したテキスト内にのみ埋め込み、他のページでは専用のヘッダーバーに配置する: 電話番号が技術的にはすべてのページに存在していても、その相対的な位置が大きく変わる（ヘッダーの最初のインタラクティブ要素から、数百のリンクの後にあるフッター内に埋もれてしまうなど）場合、一貫した順序の達成基準には不適合です。
• ヘルプアイコンが常に視覚的に「コーナーにある」から適合していると仮定する: この達成基準が測るのはページコンテンツ内の相対的な順序であり、絶対的なピクセル座標だけではありません。チャットアイコンが常に視覚的には右下にあっても、ページによって DOM 上の位置が大きく異なる（あるページでは <body> タグ直後、別のページでは閉じる </body> タグ直前など）場合、キーボード利用者やスクリーンリーダー利用者にとっては依然として不適合となり得ます。
• レスポンシブブレークポイントの監査を忘れる: デスクトップ幅では一貫しているヘルプメカニズムが、狭いビューポートでは非表示になったりモバイルのハンバーガーメニュー内に移動したりして、モバイルでの位置が変わることがあります。モバイル利用者がデスクトップ利用者と異なる相対位置を経験する場合、とくにモバイルが主なアクセス手段であるターゲット層に対しては、この達成基準に照らして評価する必要があります。
• デザインシステムでヘルプメカニズムの位置を文書化しない: ヘルプメカニズムをどこに配置すべきかについての標準が文書化されていないと、個々の開発者やデザイナーが独自に判断し、時間の経過とともに不整合が生じます。ヘルプメカニズムの配置ルールを、デザインシステムやコンポーネントライブラリのドキュメントに明示的に追加してください。

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

トルコの大統領通達 2025/10は、2025 年 6 月 21 日付官報（第 32933 号）で公布され、デジタルアクセシビリティに関する包括的な国家枠組みを確立しています。この通達は、トルコで運用される幅広いデジタルサービスに対し、WCAG 2.2 レベル AA への適合をベースラインのアクセシビリティ標準として義務付けています。レベル AA の達成基準として WCAG 2.2 で導入された WCAG 3.2.6 一貫したヘルプは、この法的義務の範囲に直接含まれます。

大統領通達 2025/10 の対象となる主体には、中央および地方レベルの公的機関・団体、銀行規制監督庁（BDDK）の規制下にある銀行および金融サービス提供者、電子商取引プラットフォームおよびオンラインマーケットプレイス、患者向けデジタルサービスを提供する病院および医療提供者、20 万人以上の加入者を持つ通信会社、オンライン予約システムを持つ旅行代理店、定期運行を行う民間輸送会社、そして国民教育省（MoNE）に認可された私立学校および教育機関が含まれます。これらすべての主体に対し、SC 3.2.6 を含む WCAG 2.2 レベル AA の達成基準一式が適用標準となります。

WCAG 3.2.6 への適合は、トルコ家族・社会サービス省（Aile ve Sosyal Hizmetler Bakanlığı）が発行するErişilebilirlik Logosu（アクセシビリティロゴ）を取得するための前提条件でもあります。このロゴはアクセシビリティ適合の公式な証として機能し、トルコの消費者や調達担当者の間で品質のシグナルとして認知が高まりつつあります。このロゴを取得しようとする組織は、自社のデジタルプロパティ全体で WCAG 2.2 レベル AA に完全に適合していることを示さなければならず、ヘルプの配置の不整合は、たとえ一見些細なものであっても申請を失格とする要因になり得ます。

実務的なコンプライアンスの観点から、SC 3.2.6 はとくに、ライブチャットウィジェット、WhatsApp 連絡リンク、FAQ セクションを主要なカスタマーサポートチャネルとしているトルコの電子商取引および金融サービス提供者にとって重要です。商品一覧ページ、カートページ、チェックアウトフロー、アカウント管理セクションにわたって、これらのヘルプメカニズムが一貫した位置に表示されるようにすることは、この通達の下での法的義務であると同時に、トルコの多様なインターネット利用者層 — 初めての利用者やリテラシーの低いデジタル利用者を多く含み、予測可能なインターフェースパターンから最も恩恵を受ける層 — に対応するうえで妥当な UX 実践でもあります。

通達の対象となる組織で、まだヘルプメカニズムの配置を監査していないところは、WCAG 2.2 コンプライアンスロードマップの一環として、ページをまたいだ一貫性の監査を優先すべきです。この達成基準は手動テストを必要とするため、初期の適合監査だけでなく、ヘルプ要素の位置が意図せず変わる可能性のある大規模なリデザインやテンプレート変更の後には、とくに継続的な品質保証サイクルにも組み込む必要があります。