Consistent Help: What WCAG 3.2.6 Actually Requires
Quick answer: WCAG SC 3.2.6 Consistent Help (Level A, new in WCAG 2.2) does not require a site to have a help mechanism. It requires that if one exists — a “Contact us” link, a live-chat launcher, an FAQ page, a chatbot — and it repeats across multiple pages in a set, it shows up in the same relative order each time, unless the user themselves triggers a change (like resizing the viewport). The common e-commerce failure isn’t a missing help link; it’s a help link that’s in the header on the homepage and product pages, then quietly disappears — or moves — once the shopper reaches checkout.
This article is general accessibility information, not legal advice. Meeting WCAG 2.2 is a technical-practice standard, not a legal determination — consult qualified counsel for legal risk questions.
What the criterion actually says
The normative text is narrower than the name suggests. Quoted directly from the W3C Understanding doc:
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 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.
Four mechanism types, each with a plain-language example in the doc itself:
- Human contact details — a phone number, email address, or stated hours.
- Human contact mechanism — live chat, a contact form, a social-media channel.
- Self-help option — an up-to-date FAQ, “How Do I” page, or support page.
- A fully automated contact mechanism — a chatbot.
Nothing in that list requires you to add one. The doc says so explicitly: “the absence of a help mechanism on certain pages within a set does not constitute a violation.” A page with no contact link at all doesn’t fail this criterion. A page where the contact link exists but has moved does.
“Same order,” not “same pixel position”
The most common misreading is treating this as a visual-consistency rule — the link has to sit in the exact same spot on screen. It doesn’t. The Understanding doc’s own Note 2 defines the requirement in terms of document order, not layout:
“The same order relative to other page content” can be thought of as how the content is ordered when the page is serialized. The visual position of a help mechanism is likely to be consistent across pages for the same page variation… This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).
In practice that means a help link second-to-last in the footer, right before the copyright line, has to keep that same position — after the other footer links, before the copyright — on every page in the set. A responsive layout that reflows the footer at a narrower breakpoint isn’t automatically a violation, since the doc treats different viewport sizes as different “page variations.” What it doesn’t excuse is a link that’s fourth in the footer on the homepage and first in the footer on checkout, at the same viewport size.
The exception is narrower than it sounds
The criterion allows a change “initiated by the user” — but the Understanding doc is specific about what qualifies. It names viewport size, zoom level, and orientation changes as the intended case, and then rules out the two changes people most often assume count:
This exception is not intended to treat every action that a user might initiate as a “change”… For example, merely navigating between pages within a set of web pages is not a “change initiated by the user” for the purposes of this exception. Similarly, logging into or out of a page would not typically qualify, unless logging in would present the user with a distinct set of web pages.
That closes off the two easiest rationalizations for a broken implementation: “the checkout pages are a different template” doesn’t count as a user-initiated change, and neither does “the help link moves once you’re logged in.” Unless the logged-in experience is genuinely a separate set of pages with its own internal consistency, the link still has to hold its position.
Where this actually breaks on e-commerce sites
The pattern shows up in a specific, recognizable shape. A site adds a live-chat launcher and a “Contact us” footer link, both positioned consistently across the homepage, category pages, and product pages. Then checkout ships as a separate template — built by a different team, optimized for conversion — and the help mechanism either drops out of the footer entirely, gets buried inside a collapsed “More info” accordion, or moves above the payment fields instead of below them. None of that is visually wrong on any single page. It only becomes a 3.2.6 failure when you check it across the set.
This is exactly the shape the criterion’s own worked examples describe, even though neither is e-commerce-specific on its face — an online job application where “consistently located contact information will enable them to use phone or email so they can get an answer to their question,” and a medical appointment-scheduling form where “a consistently located messaging option… enables them to quickly interact with a staff person.” A multi-step checkout is the same shape: a form a shopper might abandon at the exact point they’d need help finishing it.
The Understanding doc names the failure directly as “Inconsistent Help Location,” and its own sufficient technique, G220: Provide a contact-us link in a consistent location, gives two equally valid fixes: a link near the top of the page (“one of the first links that the user reaches when tabbing through the page”), or a link in the footer, repeated in the same relative position everywhere. Either works — what doesn’t is switching patterns partway through the flow.
A quick manual check
This is a cross-page audit, not a single-page one — no automated scanner running against one URL at a time can catch it on its own.
- List every page in the flow you’re checking — for a store, that’s usually homepage, a product page, cart, and each checkout step.
- Find the help mechanism on each page (if one exists) — phone number, chat launcher, contact link, FAQ link.
- Tab through each page from the top and note where the help mechanism falls relative to the other links and content around it — third in the footer, first in the header nav, wherever it is.
- Compare across pages. If it’s third-in-footer on three pages and missing or first-in-header on the fourth, that’s the failure.
Not the same question as the chat widget’s own accessibility
This criterion is about where a help mechanism sits across pages — it says nothing about whether the mechanism itself is usable once you reach it. A live-chat launcher can be positioned perfectly consistently and still fail on its own terms: no accessible name on the button, no aria-expanded state, incoming messages that never reach a screen reader. That’s a separate, already-covered topic — see Making Live Chat and Customer Support Widgets Accessible for those fixes. The two checks are complementary: one verifies the widget works, the other verifies you can find it in the first place.
FAQ
Does adding a help link to every page automatically satisfy this criterion? No — position matters as much as presence. A link on every page in a different relative order each time still fails.
Does a chatbot count as a help mechanism on its own? Yes — the Understanding doc lists “a fully automated contact mechanism such as a chatbot” as one of the four qualifying types, alongside human contact details, a human contact mechanism, and a self-help option.
What if checkout genuinely doesn’t need the same help link as the rest of the site? That’s a legitimate design call the criterion doesn’t forbid — it just doesn’t get you an exception through the “user-initiated change” clause. If checkout is deliberately a separate set of pages with its own internal help pattern, keep that pattern consistent within checkout itself.
Get a human-reviewed audit, not just a scan
Checking help-mechanism placement across a multi-page flow is exactly the kind of cross-page comparison a single-URL automated scan isn’t built to do — it requires walking the actual flow the way a shopper would. Quietramp’s audits pair an automated scan with a manual review across your site’s real pages and flows, delivered as a prioritized, developer-actionable PDF report. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.
This article is general accessibility information, not legal advice. Meeting WCAG 2.2 does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.