Consistent Help
This one is new in WCAG 2.2, and it is conditional. If a page carries help, and that help repeats across a set of pages, it has to sit in the same place in the page order every time. Help means one of four things. Contact details for a human, a way to reach a human such as a chat or a contact form, a self-help option such as an FAQ or a support page, or a fully automated contact such as a chatbot. Two things this rule does not do are worth knowing before you test it. It does not require you to offer help at all, so a page without help does not fail. And it governs the order the page is read in, not where help sits on screen, so a help link that moves visually while keeping its place in the reading order still passes.
Why it matters
People reach for help at the worst moment, when they are stuck, confused or one click from leaving. That is exactly when hunting for a chat bubble that moved is hardest to bear. Whether help is where the user expects it can decide whether the sale survives. And there is a sharper reason underneath the commercial one. W3C's own account of this rule says users who cannot get help may end up asking somebody else for it, and that the somebody else does not necessarily keep private information secure. Predictable help is not only kindness. It is how a person keeps their own details to themselves.
Who this rule protects
Users with cognitive disabilities need help where it was last time, because relearning its position on every page is a barrier of its own. A person who can describe their problem in their own words often gets further with a chat than with a phone number, which is why the rule names those as two separate kinds of help rather than one. And anybody under stress, in the middle of a billing problem or a failed checkout, needs the entry point exactly where they last saw it.
How to check it yourself
- Note where help falls in the page order on a page that has it, meaning what content comes before it and what comes after.
- Open the other pages in the same set and check the same thing. Whatever came before help there should come before it here, and whatever came after should come after.
- Read the order rather than the screen. A help link that is visually in a different corner but in the same place in the source does not fail this rule. One that has moved in the source does.
- Walk checkout on its own, and any other flow with its own template, since each is a separate set that only has to hold consistent within itself.
- Check the mobile layout separately and raise nothing when help moves between breakpoints, because a change the user initiated, including resizing, is excepted.
Failures we see most often
- A support link comes straight after the main navigation on most article pages and drops below the body on a handful of others in the same set, so the order a user learned stops working.
- Contact details sit in the footer on most templates and in a sidebar on a few, which moves them in the reading order as well as on screen.
- Two help options are listed in one order on some pages and the other order on the rest, so the one a user reached for second is now first.
- A rebuilt template puts the help link above the main content while the rest of the set keeps it below, and nothing in the release notes says why.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it
How to fix it
- Render the help entry point from one shared layout component, so its place in the page order is defined once and only once.
- Where a link is easier to keep consistent than the help itself, use a link. A direct link to a contact page satisfies this rule exactly as inline contact details do.
- Say when a human is available. The rule does not ask you to staff a chat around the clock, and telling somebody the line opens at nine is a real kindness compared with leaving them waiting.
- If you run a chatbot, hand off to a human after three attempts that do not land, and let the bot be dismissed in one action and recalled from a link. That is W3C's own advice for making a bot work for people with cognitive disabilities.
Step-by-step fix guides (1)
Passes vs. fails
Passes
The Contact us link renders from one shared layout component, so it lands at the same point in the reading order everywhere in the set, whatever the screen size does to its position.
Fails
The Contact us link comes straight after the header on most product pages and at the very end of the page order on a few. A buyer who learned where to reach for it goes hunting at the worst possible moment.
In audits and lawsuits
This is a WCAG 2.2 addition, so it is missing from any audit written against 2.1 or earlier, which is worth checking before you trust an older conformance claim. What we actually raise is template drift inside one set. Help sits at one point in the page order on most templates and at another point on a handful, so the position a user learned stops holding. Three things we do not raise. Help disappearing from a page is not a failure of this rule, because the rule only governs pages that carry help in the first place. A checkout with its own stripped template is its own set and may place help differently. And help moving at a mobile breakpoint is covered by the rule's own exception for changes the user initiates, which includes zoom, orientation and viewport size. No automated rule exists here, so a scanner cannot clear it either way.