Reviewed November 5, 2026

Consistent Help: WCAG 3.2.6 and the Wandering Contact Link

WCAG 2.2 criterion 3.2.6, Consistent Help, at Level A requires that help mechanisms repeated across pages, such as a contact link, human help, or a self service option, appear in the same relative order on each page unless the user changes it. A store that puts chat in the footer on product pages and a floating button at checkout is the classic fail.

Help is usually needed at the worst moment: a failed payment, a confusing size chart, a delivery date that decides the order. At that moment your customer should not have to play hide and seek with the contact link because this template puts it somewhere new.

Consistent Help is one of the cheapest criteria in WCAG 2.2 to meet and one of the easiest to break by accident, because every redesign, app install, and campaign landing page gets a vote on where help lives.

What the criterion actually requires

The scope is narrower than people fear. If a help mechanism is repeated across multiple pages, it must keep the same relative order in the page structure on each of them. The rule covers human contact details, human contact mechanisms, self service options like FAQ and order tracking, and fully automated help such as a chatbot.

It does not force you to offer help, and it does not dictate one sacred location. A header contact link, a footer help block, or a persistent chat entry can all comply. What breaks compliance is drift: help first in the footer here, buried under promotions there, absent from the campaign page the ad traffic lands on.

Where stores drift without noticing

Chat apps are the biggest source. The widget loads site wide until someone excludes it from the blog, or an A/B test moves it, and now help access depends on which door the shopper entered through. Checkout adds its own version: extensible checkout blocks reorder support links for conversion reasons nobody checked against accessibility.

Landing pages built in a page builder are the second source. They ship with their own stripped header and footer, so the help order the rest of the site uses simply does not exist there. Since paid traffic lands on exactly those pages, the shoppers with the least context get the least consistent help.

A boring fix that holds

Pick one home for each help mechanism, header order and footer order written down, and make it a release checklist item: any new template, app, or test that touches header, footer, or chat gets a help order check before launch. Automation can compare the rendered order of help elements across a template sample in a few minutes.

The business case writes itself. Support contact findability is a conversion input at the exact moment of highest purchase intent and highest confusion. Consistency here is not charity. It is wayfinding for people already holding a credit card.

Frequently asked questions

What counts as a help mechanism under WCAG 3.2.6?

Human contact details such as a phone number or email, a contact mechanism like a form or chat with staff, self service options such as FAQ pages and order tracking, and automated help like chatbots. If it repeats across pages, its relative order must stay consistent.

Does Consistent Help mean help must be in the same pixel position?

No. The requirement is the same relative order among page elements, not identical coordinates. Responsive layouts can move things visually as long as the order a user encounters them stays consistent in the page structure.

Is WCAG 3.2.6 a Level A or AA rule?

It is Level A in WCAG 2.2, the minimum conformance tier, which makes it hard to justify missing. It is also one of the new 2.2 criteria most likely to be cited in an accessibility review of an ecommerce site.

Can a floating chat button break Consistent Help?

It can if chat also appears elsewhere in a different order, or if the button is present on some templates and absent on others without the help being available in its consistent place. One mechanism, one predictable position, is the safe pattern.