Level A

New in WCAG 2.2 Level A: help mechanisms repeated across a set of pages must appear in the same relative order.

3.2.6 Consistent Help

In Plain Language

3.2.6 Consistent Help is new in WCAG 2.2 at Level A[1]. It governs four specific help mechanisms: human contact details (phone, email, hours), a human contact mechanism (contact form, live chat link, messaging handle), a self-help option (FAQ, support page, "How do I" article), and a fully automated contact mechanism (chatbot).

If a page exposes any of these mechanisms and that mechanism is repeated across a set of pages, every page that includes it must place it in the same relative order with respect to the rest of the page content. The criterion does not require the mechanism to appear on every page, and it does not require pixel-identical positioning -- it requires a stable relative sequence so a user who found help once can find it again without re-scanning the layout.

Why It Matters

  • Users with cognitive and learning disabilities build procedural memory of where help lives. When the "Contact Us" link is the third footer item on the home page and the first header utility link on the checkout page, that memory is invalidated and the user has to re-search from scratch on every page transition.
  • Screen-reader users navigate by landmark and heading order. A help link that moves from a `contentinfo` footer landmark to a `banner` header landmark between pages forces a different keystroke sequence (`F` to footer, or `B` to banner) on each page instead of a learned shortcut.
  • Low-vision users with high magnification see a viewport-sized slice at a time. A consistent relative position means they know which direction to pan; an inconsistent one means they pan the entire page on every visit.
  • Users with anxiety or panic disorders who need to reach human support quickly depend on help being where it was last time. Re-searching for help while already distressed is the exact failure mode 3.2.6 was written to prevent[1].

Examples

Do: Keep help mechanisms in the same relative order across pages

Page: Home

Help

Page: Products

Help

✔ Self-help, human contact mechanism, and human contact details appear in the same sequence on both pages

<!-- Rendered from a shared footer partial included on every page -->
<footer>
  <nav aria-label="Help">
    <ul>
      <li><a href="/faq">FAQ</a></li>
      <li><a href="/chat">Live Chat</a></li>
      <li><a href="/contact">Call Us</a></li>
    </ul>
  </nav>
</footer>
Don't: Reorder help mechanisms between pages

Page: Home

Help

Page: Products

Help

✘ Relative order changes between pages -- fails 3.2.6

<!-- Fails 3.2.6: same three mechanisms, different relative order -->
<!-- Home page footer: FAQ, Chat, Call -->
<!-- Products page footer: Call, FAQ, Chat -->
<footer>
  <nav aria-label="Help">
    <ul>
      <li><a href="/contact">Call Us</a></li>
      <li><a href="/faq">FAQ</a></li>
      <li><a href="/chat">Live Chat</a></li>
    </ul>
  </nav>
</footer>
Do: Render help from a single shared template

Every page includes the same header partial. The Help button renders in the same position relative to the logo on every route.

✔ One shared template eliminates the possibility of per-page drift

<!-- _includes/site-header.html, included in the base layout -->
<header>
  <a href="/" class="logo">MySite</a>
  <nav aria-label="Help">
    <a href="/help">Help</a>
  </nav>
</header>
<!-- No route can override the order without editing the partial -->
Don't: Move help between page regions across routes

Home page:

Help link in header
...page content...
Footer (no help)

Checkout page:

Header (no help)
...page content...
Help link in footer

✘ Help moves from banner to contentinfo -- relative order changes, fails 3.2.6

<!-- Fails 3.2.6: the same Help link occupies a different relative position -->
<!-- Home: help is the first interactive element after the logo -->
<header>
  <a href="/help">Help</a>
</header>
<main>...</main>
<footer></footer>

<!-- Checkout: help is the last element on the page -->
<header></header>
<main>...</main>
<footer>
  <a href="/help">Help</a>
</footer>

How to Fix It

  1. Inventory the four mechanisms. Walk the site and list every instance of human contact details, human contact mechanism, self-help option, and fully automated contact mechanism[1]. Anything outside those four categories is out of scope for 3.2.6 -- a newsletter signup or a product search is not "help."
  2. Render help from a shared partial. Move the help block into a single header, footer, or sidebar include used by every route. Per-page copies drift; a single source of truth cannot.
  3. Fix the relative order, not the absolute position. 3.2.6 requires the same order relative to other page content, not pixel-identical coordinates. A floating Help button that appears in the same DOM position relative to `main` on every page satisfies the criterion even if responsive breakpoints move it visually.
  4. Audit templates that override the shared layout. Checkout, error pages, and marketing landing pages are the common offenders -- they often ship with their own header or footer and quietly drop or reorder the help block. Grep the codebase for every layout that sets its own `header` or `footer` and verify each one.
  5. Walk the site with a screen reader and a keyboard. Tab through the home page, note the ordinal position of each help mechanism in the focus order, then tab through a deep page (checkout, account settings, error page) and confirm the same ordinal positions. A shift of even one slot is a 3.2.6 failure.
  6. Remember 3.2.6 is Level A. It is new in WCAG 2.2 alongside 3.3.7 Redundant Entry, 3.3.8 and 3.3.9 Accessible Authentication, 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, and 2.5.8 Target Size (Minimum)[1]. Any conformance claim at Level A against WCAG 2.2 includes it.

References

  1. [1] W3C (2023). Understanding Success Criterion 3.2.6: Consistent Help. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/consistent-help.html ↩ ↩ ↩ ↩