WCAG 3.2.6: Consistent Help
When a user needs help, they shouldn't have to hunt for it. If your site offers a help mechanism — a contact number, a chat widget, a help link — on more than one page, this Level A criterion, new in WCAG 2.2, requires it to appear in the same relative order on every page. It doesn't make you add help; it just makes the help you already offer predictable, so people can find it the same way every time.
The success criterion, in full
If a web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same relative order relative to other page content, unless a change is initiated by the user: human contact details; human contact mechanism; self-help option; a fully automated contact mechanism.
Why consistent help matters
People look for help precisely when they are already stuck. A user who cannot complete a form, understand a fee, or find a product is at the edge of giving up — and in that moment, the last thing they can afford is a second puzzle: where did the help go?When the route to assistance jumps around from page to page — top-right here, buried in the footer there, gone entirely on the checkout screen — finding help becomes its own task, layered on top of the problem the user already couldn't solve.
For people with cognitive and learning disabilities, this is decisive. Predictable placement lets someone learn once where help lives and return to it reliably, without re-scanning every page. Users with anxiety are spared the stress of searching; users with low digital literacy are spared a hunt they may not win; screen reader and keyboard users are spared having to re-explore each page's structure to relocate a control they already found once.
3.2.6 asks for something modest and high-value: keep the help you offer in a consistent, predictable place. It is a sibling to 3.3.7 Redundant Entry — the two Level A criteria WCAG 2.2 added to reduce cognitive load — and, because WCAG 2.2 AA is the reference standard for the DOJ Title II rule and the European Accessibility Act, it is also a compliance target.
The four help mechanisms
3.2.6 applies only to these four kinds of help. If your pages carry one of them and it repeats across the set, its placement must be consistent. Note the criterion does not require you to provide any of these — only to place consistently whatever you do offer.
Human contact details
A phone number, email address, physical address, or social-media handle a user can use to reach a person. If your pages surface a support phone number or a contact email, that is a covered help mechanism and its placement must stay consistent.
Human contact mechanism
A way to reach a person without publishing static contact details — a contact form, a messaging service, a Slack or Discord invite, or a callback request. It connects the user to a human, so it falls under the criterion when repeated across pages.
Self-help option
A link or section that helps users help themselves — a Help or FAQ page, a support portal, a documentation hub, or a 'How do I…?' resource. When it appears on multiple pages, keep it in a consistent relative location.
A fully automated contact mechanism
A chatbot or automated assistant that answers questions or resolves issues without a human. A persistent chat widget in the corner of every page is the classic example — and it must stay in a consistent relative order across the set of pages.
What "same relative order" means
The requirement is about order relative to other content, not fixed pixel coordinates. Your layout can reflow responsively and your help control can restyle across breakpoints — what must stay stable is where the help sits in the sequence of page content.
Passes
- A "Contact support" link that is always the last item in the header, on every page.
- A chat widget pinned to the same corner sitewide.
- A help link that reflows from a top bar (desktop) into a menu (mobile) but keeps its order within that menu across pages.
- Help placement that only moves because the user chose to reorder or collapse it.
Fails
- A support number in the header on the home page but only in the footer on the pricing page.
- A chat bubble that appears bottom-right on most pages but top-left during checkout.
- A "Help" link that is first in the nav on one page and last on another.
- Help that vanishes entirely on the exact pages (checkout, forms) where users need it most.
Patterns that satisfy 3.2.6
The reliable way to meet 3.2.6 is to render your help mechanism from a single shared layout component, so its position is defined in one place and inherited by every page. Then it cannot drift.
- Put the help link or contact detail in a shared header or footer component used by every page in the set — one source of truth for its position.
- Render persistent chat and support widgets from the root layout, not per-page, so they land in the same relative spot everywhere.
- Keep help present on high-stakes pages — checkout, sign-up, error, and form pages — not just marketing pages.
- If help lives in the navigation, keep it in the same position within the nav order (see 3.2.3 Consistent Navigation).
- When the layout reflows for mobile, preserve the help's order within its container rather than relocating it.
Code examples
A shared header help link (one source of truth)
Rendering the help link from a single header component that every page uses guarantees it keeps the same relative order automatically — you cannot forget it on one page or move it on another.
// Header.tsx — used by every page in the set
export function Header() {
return (
<header>
<nav aria-label="Primary">
<a href="/">Home</a>
<a href="/products">Products</a>
<a href="/pricing">Pricing</a>
{/* Help is always the last item in the nav,
on every page — same relative order */}
<a href="/help">Help & contact</a>
</nav>
</header>
)
}A persistent chat widget rendered from the root layout
Mounting the automated-contact widget in the app's root layout — not per page — keeps it in the same relative position across the whole set. Give it an accessible name so screen reader users can find it too.
// app/layout.tsx (Next.js) — one mount, every page
export default function RootLayout({ children }) {
return (
<html lang="en">
<body>
<Header />
{children}
{/* Automated help, same corner on every page */}
<button
type="button"
className="support-chat"
aria-label="Open support chat"
>
Chat with support
</button>
</body>
</html>
)
}Human contact details in a consistent footer
Contact details expressed with semantic markup, rendered from a shared footer, satisfy both the "same relative order" requirement and good structure for assistive technology.
<footer>
<h2>Need help?</h2>
<address>
Call us: <a href="tel:+18005551234">1-800-555-1234</a><br />
Email: <a href="mailto:support@example.com">support@example.com</a>
</address>
</footer>Anti-pattern: help that moves between pages
Defining the same help link separately on each page invites drift — here it is first in the nav on one page and dropped to the footer on another, which fails 3.2.6.
<!-- home.html: help is first in the header nav -->
<nav><a href="/help">Help</a> <a href="/">Home</a> ...</nav>
<!-- checkout.html: help was moved to the footer -->
<nav><a href="/">Home</a> ...</nav>
<footer><a href="/help">Help</a></footer>
<!-- Different relative order across pages = 3.2.6 failure -->Common mistakes
- Placing the help link in the header on marketing pages but only in the footer on app or checkout pages.
- Dropping the chat widget or contact info entirely on the exact pages where users get stuck — checkout, forms, error screens.
- Letting a chat bubble render in a different corner on some templates than others.
- Copy-pasting the help markup into each page separately, so it drifts out of order over time instead of coming from one shared component.
- Assuming 3.2.6 forces you to add a help mechanism — it only governs the placement of help you already provide.
- Reordering help during a responsive reflow so its position within its container changes from page to page.
- Treating 'same relative order' as 'identical pixel position' and over-engineering fixed coordinates instead of consistent content order.
- Providing help that is visible but not keyboard reachable or lacks an accessible name, so some users still cannot use it.
How to test for 3.2.6
- 1
Inventory your help mechanisms
Identify every help mechanism on the site: contact details, contact forms or messaging, help/FAQ links, and any chatbot or support widget. Note which of the four covered types each one is.
- 2
Check whether each repeats across pages
3.2.6 only bites when a help mechanism appears on multiple pages in a set. For each one that recurs, list the pages it appears on — this is the set you must keep consistent.
- 3
Compare relative order across several pages
Open a representative sample — home, a product or content page, checkout or sign-up, and an error page. For each recurring help mechanism, confirm it sits in the same position relative to surrounding content on every page.
- 4
Check the high-stakes pages specifically
Pay special attention to checkout, sign-up, form, and error pages. Help is most valuable there and most often missing or relocated. If it disappears or moves on those pages, that is a real failure.
- 5
Confirm the help control is itself accessible
Consistent placement only helps if users can operate the control. Reach each help mechanism with the keyboard alone, and confirm a screen reader announces a clear accessible name for it.
Consistent Help is a manual, cross-page check that automated tools rarely catch on their own — but you can pair it with a scan from the URL Accessibility Auditor and confirm assistive-technology behavior using the Screen Reader Testing Guide.
Related success criteria
3.3.7 Redundant Entry — A
The other Level A criterion WCAG 2.2 added to lower cognitive load: don't make users re-enter information they already provided in the same process.
3.2.3 Consistent Navigation — AA
The blueprint 3.2.6 follows: navigational components that repeat across pages must appear in the same relative order. Help that lives in the nav should satisfy both.
3.3.8 Accessible Authentication (Minimum) — AA
Another new-in-2.2 sibling focused on reducing cognitive burden — here, removing cognitive function tests from sign-in.
3.3.2 Labels or Instructions — A
Clear labels and instructions reduce the need for help in the first place — the front line before a user reaches for support.
Browse every criterion in the WCAG Success Criteria hub or work through the full WCAG 2.2 checklist.
Frequently asked questions
What does WCAG 3.2.6 Consistent Help require?
WCAG 3.2.6 requires that if a web page contains one of four help mechanisms — human contact details, a human contact mechanism, a self-help option, or a fully automated contact mechanism (chatbot) — and that same help is available on multiple pages in a set, it must appear in the same relative order on each page, relative to the other content. It is a Level A success criterion, new in WCAG 2.2. It does not force you to add help; it only governs the placement of help you already offer.
Does 3.2.6 mean I have to add a help link or contact page to my site?
No. 3.2.6 does not require you to provide any help mechanism at all. It only applies when you already offer one of the four covered help types on more than one page. If you have no help mechanism, the criterion is met by default. But if you do have, say, a support chat widget or a 'Contact us' link that recurs across pages, those must be placed consistently.
What does 'same relative order' actually mean?
It means the help mechanism keeps its position relative to the other things on the page — not that it must sit at identical pixel coordinates. If your help link is the last item in the header on one page, it should be the last item in the header on every page in the set. The layout can reflow responsively; what must not change is the order in which the help appears relative to surrounding content. A help link that is in the top-right on one page and buried in the footer on the next fails.
Does the help have to look the same on every page?
The criterion is about location and order, not visual styling. It is fine for a chat widget to render slightly differently across breakpoints, or for a contact link to inherit page-specific theming, as long as it occupies the same relative position in the content order. Consistency of placement is what helps users build a reliable mental model of where to find help.
How is 3.2.6 different from 3.2.3 Consistent Navigation?
3.2.3 Consistent Navigation (AA) covers navigational components that repeat across pages — they must appear in the same relative order. 3.2.6 Consistent Help (A) applies the same 'same relative order' idea specifically to help mechanisms, and it is a lower conformance level (A). They are complementary: 3.2.3 keeps your nav predictable, 3.2.6 keeps your help predictable. A help link that is also a nav item should satisfy both.
Does 3.2.6 apply to a single page or a set of pages?
It applies across a set of web pages that share the help mechanism. On a single, standalone page there is no 'other page' to be consistent with, so the criterion is trivially satisfied. The value appears when a user moves between pages: they should not have to re-hunt for help each time. The 'set of pages' is typically the pages of one site or web app that carry the same help option.
Why is inconsistent help placement an accessibility problem?
Users with cognitive disabilities, low digital literacy, or anxiety rely on predictability. When the route to help moves around, finding assistance becomes its own puzzle — exactly when the user is already stuck and stressed. Consistent placement lets people learn once where help lives and return to it reliably. It also benefits screen reader and keyboard users, who otherwise have to re-scan each page's structure to relocate the help control.