3.2.6 Consistent Help
- Level A
- Understandable
- New in WCAG 2.2
Summary
When people get stuck, they look for help where they found it last time. This criterion, new in WCAG 2.2 at Level A, requires that when a help mechanism repeats across a set of web pages, it appears in the same order relative to the rest of the page content on every page where it occurs. It protects people with cognitive disabilities in particular: once someone has learned that the contact link lives at the end of the footer, moving it elsewhere on the next page can mean they never find it at all.
Four types of mechanism are in scope: human contact details (a phone number or support email), a human contact mechanism (a contact form or messaging link that reaches a person), a self-help option (an FAQ page, help centre link, or how-to guidance), and a fully automated contact mechanism (a chatbot). Note the important scoping: the criterion does not require help to exist. A site with no help mechanism at all cannot fail it. It only demands consistency once help is offered and repeated. The "set of web pages" definition also matters: pages must share a common purpose and be created by the same author, group, or organisation, so a single standalone page has no set and the criterion does not apply.
Official wording
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.
EN 301 549 mapping
This success criterion is new in WCAG 2.2. EN 301 549 V3.2.1, the harmonised European standard currently in force, references WCAG 2.1 and contains no clause for it. A revision aligned with WCAG 2.2 is in progress; until it is published and cited in the Official Journal of the EU, this criterion is not part of the harmonised standard.
Checked against EN 301 549 V3.2.1 (2021-03).
In practice
Web
Start by identifying every help mechanism on a representative page: scan the header, footer, sidebars, and any floating widgets for phone numbers, contact links, FAQ links, and chat launchers. Then compare across templates within the same set of pages: marketing pages, checkout, account settings, and error pages often come from different templates, and that is where the relative order drifts.
"Same order relative to other page content" is the key phrase, and it is more forgiving than it first appears. Pages can differ: a checkout page may drop entire sections that a marketing page has. What must hold is the relative order in the DOM and reading order. If the footer contains navigation links followed by a contact link, the contact link must not jump ahead of the navigation links on another page, but content may be added or removed around it. Judge the sequence as a screen reader or keyboard user would encounter it, not by pixel position alone, though a chat widget that visually wanders between corners is usually failing in both senses.
Changes the user initiates are exempt. If a user collapses a help panel, dismisses a chat widget, or reorders a customisable dashboard, the resulting inconsistency is their choice, not the author's.
iOS
The criterion is worded for web pages, and there is no direct native equivalent of a "set of web pages". The honest position for an auditor is that a native app is assessed by analogy: treat the app (or a coherent section of it) as the set, and its screens as the pages. The intent transfers cleanly, so apply it as such and say so in your reporting.
In practice that means the app's help entry point should live in a consistent location across screens: always in the settings tab, always in the navigation bar, or always at the foot of each form. A support link that appears in the navigation bar on some screens, in a toolbar on others, and buried in a menu elsewhere breaks the intent even though each placement is individually findable. Check tab bars, navigation bar items, and settings screens, and confirm the help affordance holds its relative position among its neighbours from screen to screen.
Android
The same by-analogy application holds on Android. Look at where help and contact affordances sit across the app's screens: a "Help and feedback" entry that lives in the navigation drawer on some screens but moves to the overflow menu on others is the classic inconsistency. Pick one home for it and keep it there, in the same relative position among its sibling items.
Check the drawer, the overflow menu, bottom navigation, and any settings hierarchy. As on iOS, the relative order matters more than the absolute one: if the drawer lists account items then help then sign out, that sequence should survive from screen to screen, even when individual screens add or remove other drawer entries.
Pass and fail examples
Passes:
- A footer "Contact us" link that appears after the navigation links on every page in the set, even though some pages have extra footer sections around it: the relative order holds.
- A phone number shown in the header on every page of a booking flow, always following the logo and preceding the account menu.
- An FAQ link present only in the help centre section of the site: a mechanism that does not repeat across the set has nothing to be inconsistent with.
Fails:
- A chat widget launcher anchored bottom-right on most pages but bottom-left on the checkout template: the same mechanism, repeated across the set, in a different position relative to the page content.
- A support email listed first in the footer on marketing pages but pushed below the social links on blog pages: the relative order changed between templates.
Not a fail under this criterion:
- A site with no help mechanism anywhere: the criterion requires consistency, not the existence of help.
- A help panel the user has collapsed or repositioned through their own customisation: user-initiated changes are explicitly exempt.
- A single standalone page with no set of related pages: with nothing to repeat across, the criterion is not applicable.
- Help that is hard to find but consistently placed: findability on first encounter is a usability concern, not a 3.2.6 failure.
Commonly confused with
- Consistent Navigation, SC 3.2.3. That criterion covers the order of repeated navigation mechanisms; 3.2.6 covers repeated help mechanisms specifically, at Level A rather than AA. A footer that reshuffles its nav links is a 3.2.3 finding; a contact link that moves is 3.2.6. Note that the European standard declares 3.2.3 void for software by design, a different situation from this criterion's temporary absence, though the walkthrough still applies its intent as guidance in app audits.
- Consistent Identification, SC 3.2.4. That criterion is about components being named and labelled consistently, not positioned consistently. A help icon labelled "Support" on one page and "Contact" on another is 3.2.4 territory; a help link that changes position is 3.2.6.
- Error Suggestion, SC 3.3.3. Providing help when a form error occurs is a 3.3.3 concern. 3.2.6 says nothing about the quality or presence of help, only about where repeated help mechanisms sit.
- Redundant Entry, SC 3.3.7. Also new in WCAG 2.2 and often reviewed together in form journeys: 3.3.7 stops users re-entering information they already provided, while 3.2.6 keeps the route to help stable when they need it.
How AUDITSU tests this
AUDITSU's audit walkthrough handles this criterion as a cross-screen consistency question rather than a per-screen check. As you review each screen you record where its help mechanisms sit, and the walkthrough then compares help placement across the screens in the audit, prompting you to grade whether each repeated mechanism holds its relative order. The finding lands in your report with the screens that diverge identified, so the evidence shows exactly where the order broke.
Because EN 301 549 V3.2.1 does not yet include this criterion, AUDITSU tracks it under WCAG 2.2 conformance. When your audit targets the European Accessibility Act, the walkthrough treats 3.2.6 as forward guidance until the revised harmonised standard adopts WCAG 2.2.
For the full guided workflow, see the audit platform.