Search topics
Help links that move from page to page
Every shop page ends its header with a Help link, but the checkout's slimmed-down header drops it and puts Help in the footer, below the payment form.
<footer class="checkout-footer"><a href="/help">Help</a> The problem
People who learned where Help is on one page can't find it on the page where they need it most.
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.
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.
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.
4 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited language, cognitive and learning abilities People who find their way by remembering where things were look for Help where it was on the last page. When it isn't there, they may decide the site has no help, and give up at the step where they were stuck.
- Limited vision People using a screen magnifier see a small part of the page at a time and go straight to where Help was. When it has moved, they have to sweep the whole page, piece by piece, to find it.
- Without vision A screen reader user who found Help near the top of every page finds no Help there at checkout, and has to read through the whole form, or list every link, to learn it is now at the end.
- Limited manipulation Keyboard users reached Help after a few Tab presses on every other page. At checkout they have to Tab through every field of the form first.
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.
Try it
Find Help on the product page, then choose Go to checkout and find it again.
The panel under the window says where Help sits on each page you have opened, and whether the two agree. Choose Juniper to go back.
The fix
Put help at the same point in every page's order, the checkout included.
- 1Keep each repeated help mechanism at the same point in every page's order.
- 2Build slimmed-down pages, such as checkout, from the header or footer that holds help everywhere else.
- 3Keep where help is drawn and where it is read in step.
html
<!-- Every shop page --><header class="site-header"> <a href="/" class="logo">Juniper</a> <nav aria-label="Main"> <a href="/shop">Shop</a> <a href="/sale">Sale</a> </nav> <a href="/account">Account</a> <a href="/basket">Basket</a> <a href="/help">Help</a></header><main>…</main><footer class="site-footer"> <a href="/privacy">Privacy</a> <a href="/terms">Terms</a></footer>html
<!-- Checkout --><header class="checkout-header"> <a href="/" class="logo">Juniper</a> <p>Secure checkout</p></header><main>…</main><footer class="checkout-footer"> <a href="/help">Help</a> <a href="/privacy">Privacy</a> <a href="/terms">Terms</a></footer>The same Help link in the checkout's header
html
<!-- Every shop page --><header class="site-header"> <a href="/" class="logo">Juniper</a> <nav aria-label="Main"> <a href="/shop">Shop</a> <a href="/sale">Sale</a> </nav> <a href="/account">Account</a> <a href="/basket">Basket</a> <a href="/help">Help</a></header><main>…</main><footer class="site-footer"> <a href="/privacy">Privacy</a> <a href="/terms">Terms</a></footer>html
<!-- Checkout --><header class="checkout-header"> <a href="/" class="logo">Juniper</a> <p>Secure checkout</p> <a href="/help">Help</a></header><main>…</main><footer class="checkout-footer"> <a href="/privacy">Privacy</a> <a href="/terms">Terms</a></footer>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.
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.
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.
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.
Fixing this with an AI coding assistant? Get this guide as Markdown
Verify the fix
5 checks, no mouse.
Test with: Screen reader, Keyboard, Zoom
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. 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.
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.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.