# Help links that move from page to page
Source: https://easeweb.dev/learn/consistent-help
Topics: Menus and navigation > Help is in the same place on every page (WCAG 3.2.6)
The fix: Keep help at the same point in every page's order. Either keep the same Help link in the checkout's slimmed-down header, where every other page has it, or move help into a footer that every page shares, so it comes after the main content everywhere. The footer passes, but puts help at the end of every page.
Test with: screen reader, keyboard, zoom
References: https://www.w3.org/WAI/WCAG22/Understanding/consistent-help.html https://www.w3.org/WAI/WCAG22/Techniques/general/G220 https://www.w3.org/TR/coga-usable/
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
## What happens
A shop's pages share one header: the logo, Shop and Sale, then Account, Basket and, last, Help. Someone who used Help on a product page knows where it is. They add a shirt to the basket and go to checkout, and the page changes. Checkout has a slimmed-down header with only the logo and "Secure checkout", a common way to keep people focused on paying. Help is no longer in the header. It is in the footer, below the delivery and payment form. The moment people are most likely to need help, with a card declined or a delivery option they don't understand, is the moment it isn't where they learned to look.
The same move turns up in other forms:
- A phone number sits in the header on most pages, but on product pages it is in a sidebar after the reviews.
- A chat launcher is drawn in the same corner on every page, but its script is added at the top of some templates and at the end of others, so a screen reader meets it at a different point.
- An account area built on another platform puts "Contact us" first in its menu, where the shop's pages have it last.
## Why it fails
Success criterion 3.2.6, Consistent Help, is level A and new in WCAG 2.2. It covers four kinds of help: contact details for a person, such as a phone number or an email address; a way to reach a person, such as a contact form or a chat with staff; a self-help option, such as a help centre or FAQ; and a fully automated contact, such as a chatbot. When a page has one of these, and it is repeated across a set of pages, it must be in the same order relative to the rest of the page on each of them, unless the person changed something, such as the zoom or the orientation. Moving from one page to the next is not such a change.
Order here means order in the code, the order a screen reader reads. The test is simple: whatever comes before help on one page comes before it on the others, and whatever comes after it comes after. On every shop page, Help comes before the main content. At checkout it comes after it.
The criterion doesn't require help on every page, and a page with no help doesn't fail it. Nor does it require a site to offer help at all. Help may be a link to a contact page rather than the details themselves. A help link that only looks moved, drawn somewhere else by CSS while its place in the code stays the same, doesn't fail, but it is no help to people who look for it where it was.
## Who is affected
Checkout is where help matters most: a declined card, a delivery date, a discount code that won't apply. It is also the page most often given its own slimmed-down layout, so it is where help most often moves.
## What automation and AI miss
Each page passes on its own, and axe and other scanners test one page at a time; none of their rules covers 3.2.6. EaseWeb's audit compares the pages of a run. It reports a help link that sits before the main content on some pages and after it on others, recognising help by its words (Help, Support, Contact us, FAQ and their Japanese forms) or by a phone or email link. It can't recognise help under other words, a chat launcher inside a frame, or a move within the header, and it only compares the pages it was given, so checkout must be in the list. A code assistant asked for a "distraction-free checkout" takes the header links out, Help with them. Asked to add help to the checkout, it often adds a floating "Need help?" button that appears only there: a new place, not the old one.
## Before: Help moved to the footer at checkout
```html
…
```
```html
…
```
The link is the same on both, but its place is not. On every shop page Help comes before the main content; at checkout it comes after the whole form.
## After: the same Help link in the checkout's header
```html
…
```
```html
…
```
The shop pages stay as they are. At checkout, Help ends the header again, after the logo and before the main content, as it does on every shop page. The checkout still leaves out the shop's navigation, Account and Basket. Leaving out other repeated items is allowed, because what is left keeps the same order around Help. Draw it at the header's end, where shop pages draw it, so where it looks and where it is read agree.
## After: help in a footer every page shares, when the checkout's header can't change
```html
…
```
```html
…
```
Some hosted checkouts let a shop change the footer but not the header. Then help can move to the footer on every page instead: first in the same footer, after the main content everywhere, so it passes. It holds only while every page that has help uses that footer, and no page keeps a Help link in its header. It is not enough on its own. People have to get past the whole page to reach help, which on a long product list or a long form is a long way, and it is no longer in the header, where people look first.
## Which option to use
Both pass 3.2.6. Keep the Help link in the checkout's header: it costs one link, and it leaves help where people found it on every other page, near the top and a few Tab presses away, while the footer puts it at the end of every page. Use the footer only when the checkout's header can't take a link, and move help back to the header when it can.
## Implementation decisions
Build slimmed-down pages from the shared components rather than from copies. A checkout header that is the shared header with a `slim` option, dropping the navigation but keeping Help, can't drift from the rest of the site when someone later changes one of them. The same goes for sign-in, error and order-confirmation pages, which are often built separately.
Each kind of help is held to its own place, and the usual ones need care in different ways:
- A help or contact link: keep it at the same point in the header, or in the footer, on every page, and don't change its words from page to page.
- A phone number or email address: if the header shows it on some pages, it shows it on all of them that have it, in the same spot, not moved into the content on product pages.
- A chat launcher: load its script from the shared layout at the same point on every page, such as just before the end of the body, and keep it in the same corner. Its place in the code decides where a screen reader meets it, whatever corner it is drawn in.
On a phone, Help often moves into the menu. That is a different page variation, so compare pages at the same width, zoom and orientation, but at that width every page must put it in the same place too: if product pages keep it in the menu, so does checkout.
Don't move help with CSS order, grid placement or absolute positioning on some pages. A link drawn in a different place from where it sits in the code can pass the criterion while defeating its purpose, and a link drawn in the same place but placed differently in the code fails it.
Signed-in and signed-out pages are usually one set of pages. Keep help in the same place whether or not someone has signed in.
## Verify the fix
1. On each page of the main journeys, list every help mechanism it has: help and contact links, phone numbers and email addresses, contact forms, chat launchers and chatbots.
2. For each one, check it comes after the same items and before the same items on every page that has it, in the code or the browser's inspector as well as on screen.
3. With a screen reader, read each page from the top, or move through it with Tab, and confirm you reach help at the same point every time.
4. Check the slimmed-down pages in particular: checkout, sign-in, error pages and order confirmation, and any part of the journey hosted by another platform.
5. Repeat at one other width, such as a phone, keeping the zoom level and orientation the same across the pages you compare.
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after any layout, template or widget change.
## Limits
This is a starting pattern, not a guarantee for every site. The criterion asks for consistency, not for good help: a Help link in the same place still fails people if it leads to a page that answers nothing, and what the accessibility page among them should answer is in [accessibility statements that are missing or say nothing](/learn/accessibility-statement). It covers one set of pages, so a separate help portal with its own layout can put help in its own place, as long as it does so consistently. Test the whole journey, step by step, with the people and tools your users rely on.