Help mechanism location is inconsistent across pages

What is this issue?

A help-related control (a link to a contact page, a phone number, a live chat launcher, or a link to a self-service help center) is present on more than one page in the same set of pages, but its location relative to other repeated page structure (the header, the footer, a persistent sidebar) differs between pages. On one page, “Help” sits as the last item in the header; on another, it’s moved into the footer instead.

Like navigation consistency, this is a cross-page structural comparison rather than a single page’s own defect. A page can be entirely well-built on its own (a clearly labeled, keyboard-accessible help link) and still fail this rule if that link’s relative position doesn’t match where the same kind of link sits on other pages in the same site.

Why does this matter?

A help mechanism exists specifically for the moment a user is stuck: confused, frustrated, or unable to complete a task on their own. That’s precisely the moment someone has the least patience or cognitive bandwidth to go hunting for where “Contact us” or “Help” happens to be on this particular page, especially if it was somewhere different the last time they needed it.

A help control that moves around undermines its own purpose. If a user remembers finding help in the footer on one page, and it’s moved to a header dropdown on the next, they’ve lost the exact shortcut they needed at the exact moment they needed it most, turning what should be a one-glance action into another obstacle layered on top of whatever problem sent them looking for help in the first place.

Who is affected?

• Cognitive disabilities: depend on predictable, memorized page structure to reduce the effort of finding help under stress; a moved help control adds search cost at precisely the moment a user is already struggling with something else.
• Screen reader users: who’ve learned a help link’s position within a repeated landmark region on one page have to re-explore an unfamiliar structure to relocate it on a page where it’s moved, right when they may already be seeking help because something else on the page failed them.
• Motor impairments: anyone using a switch device, head pointer, or other assistive input that makes each individual navigation action more effortful pays a higher cost for having to re-search a shifted layout than a standard mouse or keyboard user does.

What users experience

Oliver has a mild intellectual disability and relies on a support worker’s guidance for unfamiliar tasks, but tries to complete routine ones (like renewing an online subscription) independently when he can. He gets stuck partway through a billing form on a service he’s used before, and remembers the “Need help?” link sitting at the top right of the page from a previous visit. This time it’s been moved into a collapsed footer accordion on this particular page. He scans the top of the page repeatedly, doesn’t find it, and gives up on completing the task independently, calling his support worker for something he’d successfully done alone before, because the one consistent anchor he’d learned to rely on wasn’t where he expected it.

How do I fix it?

Place the help mechanism in the same relative position (the same spot within the header, footer, or persistent sidebar) on every page in the set where it appears. This works because it preserves the exact shortcut a user builds after finding help once, so a returning user (or a user moving between pages during the same task) never has to re-search for it.

The most reliable way to guarantee this is rendering the help control from the same shared layout component every page uses, rather than letting individual page templates each place it independently. If different sections of a site genuinely need different help resources (a billing page linking to billing support, a technical page linking to technical support), keep the position of the help link consistent even as its destination or label changes to match the page’s content.

Code Examples

<!-- Page A -->
<header><a href="/help">Help</a></header>

<!-- Page B -->
<footer><a href="/help">Help</a></footer>

<!-- Page A -->
<header><a href="/help">Help</a></header>

<!-- Page B: same relative position, same shared header component -->
<header><a href="/help">Help</a></header>

Both versions of the link are individually valid, accessible markup; the fix isn’t in either snippet alone but in guaranteeing both pages render the same header component instead of one page moving the help link into an independently-authored footer. Once both pages share the same source for their header, the position can’t drift apart again.

Common Mistakes

Mistake: “Moving help into the footer on longer pages makes it easier to find near the end of the content.” This reasoning optimizes for a single page in isolation while breaking the cross-page consistency the rule actually requires. A help mechanism that’s easy to find on one page but relocated on the next costs users the exact shortcut they’d already learned; keep the primary help control’s position fixed, and add a secondary, page-specific help link near the end of long content if that’s genuinely useful, without removing the consistent one.

Mistake: “The help link’s destination changes per section, so its position has to change too.” These are independent. The link’s label and destination can reasonably change from “Billing help” on a billing page to “Technical support” on a technical page, while its position (say, always the last item in the header) stays fixed. Changing the content behind a help link doesn’t require moving where it sits.

Mistake: “A chatbot that pops up automatically satisfies this requirement, regardless of where it’s positioned.” Automatic chat widgets typically render in a fixed corner of the viewport by default, which does often satisfy the consistent-position requirement, but only if the widget is genuinely present and functional on every page in the set. A chatbot configured to appear on some pages and not others, with no alternative help link filling the gap on the pages it’s missing from, still fails the criterion on those pages.

How RedFlag Detects This

Guidance only: RedFlag documents this issue but does not currently flag it; verify manually. RedFlag’s own coverage model records this WCAG 2.2 criterion’s evidence as docs_only: cross-page comparison of help-mechanism placement is not implemented in any of RedFlag’s automated scanning, custom DOM detectors, or manual-check workflows today.

As with navigation consistency, this check is structurally different from most of RedFlag’s rules because it requires comparing multiple pages against each other rather than evaluating a single page’s markup in isolation, which is outside RedFlag’s current single-page scan model. There is no automated false-positive or false-negative profile to describe here, since no automated detection runs at all. Manual step: use the Manual Testing steps below across at least two to three pages that should share a consistent help mechanism.

Manual Testing

1. Identify a help mechanism (a contact link, phone number, chat launcher, or help-center link) on one page of the site.
2. Note its position relative to other repeated content: is it the last header item, a specific footer link, part of a persistent sidebar?
3. Navigate to two or three other pages within the same set (the same section, or the site broadly, depending on scope) and locate the equivalent help mechanism on each.
4. Confirm its relative position matches what you recorded on the first page.
5. Flag any page where the help mechanism has moved to a different relative location, or is missing entirely where other pages in the same set include it.

Related WCAG Success Criteria

3.2.6 Consistent Help: A WCAG 2.2 success criterion requiring that if a help mechanism is provided across multiple pages within a set, it must occur in the same relative order on each page it appears on. This rule maps directly to 3.2.6, documenting the specific failure of a help control’s position shifting between pages.

Related Issues

Navigation order is inconsistent across pages is this rule’s closest sibling: the same cross-page consistency principle, applied to a full navigation menu rather than specifically a help mechanism.

Form field has more than one label is unrelated in mechanism but often surfaces in the same audit pass, since help-mechanism and form-structure issues both tend to appear on sites with inconsistent page templates.

Page is missing a language declaration shares this rule’s need for a multi-page review during a full site audit, even though its underlying mechanism is unrelated.

HTML lang attribute is not a valid language code is worth checking during the same cross-page audit pass as this rule, for the same multi-page-review reason.

Accessible authentication requires a cognitive function test is another WCAG 2.2 criterion RedFlag documents without automated detection, worth reviewing together with this rule when auditing a site for the newer 2.2-specific requirements.

References

• W3C Understanding 3.2.6: Consistent Help
• W3C Technique G220: Provide a contact-us link in a consistent location