First identify the help a customer can actually use
A customer who gets stuck during an order may look for a contact link, phone number, help centre, or chat. They should not have to relearn where that option moved on every page. WCAG 2.2 success criterion 3.2.6 addresses repeated help mechanisms within a set of web pages: if one of the listed mechanisms appears on multiple pages, it should occur in the same order relative to other page content, unless the user initiates a change. It does not require a business to add a chatbot or publish a phone number on every page. The first editorial and product decision is to identify which routes to help already exist and which pages form the customer journey being assessed.
The listed mechanisms are human contact details, a human contact mechanism, a self-help option, and a fully automated contact mechanism. A visible telephone number, a contact form link, a help-centre link, and an automated chat can each be relevant. W3C says the mechanism can be on the page or be a direct link to another page containing it. By contrast, a note beneath a single form field explaining its format is contextual instruction, not the site-level help that this criterion is about. Do not count every tooltip as a repeated help mechanism, and do not overlook a support link simply because the details live on a separate page.
Make a short inventory of page sets rather than comparing unrelated screens indiscriminately. A shop might assess its product, basket, delivery, and account pages as one connected customer experience, while a separately hosted support portal may use another template and need its own review. Record which help items recur, where each appears in the document order, whether it is visible on a phone, and what happens when activated. The inventory should name the actual page variation, not only the design component. A header link can be present in the source yet missing from the mobile menu, or a chat launcher can be injected only after the page loads.
Compare relative order, not coordinates alone
The criterion is about the order of a help mechanism relative to other page content when the page is serialised. Visual placement will usually be consistent for the same page variation, but identical pixel coordinates are not the rule. A help link after primary navigation on the product page should not jump ahead of navigation on the basket page for the same desktop presentation. Likewise, a footer support link should not become a middle-of-form interruption on the next step. W3C notes that a user can cause a different page variation by changing zoom or orientation; compare pages within the same variation. Then assess the changed variation as its own consistent set.
Consider a store with a Contact us link in the desktop header. On product and basket pages it follows the search control. On the delivery page the team moved it above the search control to make room for a progress indicator. The link still works and is visually near the top, but its relative order has changed. A repair could keep a shared header order and move the progress indicator into the main journey area. On mobile, if all three pages consistently place Contact us inside the same menu order, that is a coherent variation. Test both visual navigation and the sequence reached by keyboard or a screen reader, because CSS can make the screen look stable while the document order changes.
A sticky chat bubble can be harder to evaluate because it appears visually over content and may be injected late in the document. Decide where it belongs in both visual and programmatic order, then confirm that the launcher is discoverable and does not obscure an order button or validation error. If the chat service is unavailable on a particular page, do not leave a dead launcher that promises immediate help. A direct contact page link in a stable location may be the more reliable mechanism for a small team. That is a product choice, not a requirement that every business must offer live support. Consistency only helps when the route itself works.
Keep a common pattern without hiding special help
A shared header, footer, or support region can keep a repeated mechanism in one predictable relative position. Give the link a clear English and Traditional Chinese label that describes the destination, and make sure the destination provides the promised route. A component library helps if the team actually uses the same component across templates; a common component name in design files does not guarantee the deployed markup is the same. Review exceptional templates such as checkout, a logged-in dashboard, and an error page. If the business intentionally omits a mechanism from a page, check that the omission is understood and that customers are not stranded at a consequential step.
A page-specific explanation can coexist with consistent site help. For example, a delivery-address field may have an example of how to enter a building name, while the common Contact us link remains in the usual header order. The field guidance solves an immediate input question; the contact link supports a broader difficulty. Keep the two roles distinct in wording and interaction. If a contextual popup is essential to complete the form, test its own keyboard and touch behaviour separately. Making every small hint look like the general help button can increase confusion because customers cannot predict whether it will explain one field, open a support article, or contact a person.
When templates change, update the repeated help inventory as part of the release review. Check whether a new promotion strip, account banner, or consent panel has shifted the help mechanism in document order on only one page. A user-initiated change, such as opening a menu, can legitimately alter what is shown; the review should describe the before and after states instead of treating every animation as a violation. If a mobile breakpoint rearranges content, compare the mobile versions with one another, then compare desktop versions with one another. This makes the test reproducible and avoids a false promise that one coordinate works at every screen size.
Verify support as a usable journey
Ask a tester to start from a product page, a basket page, and an account page without telling them where support is. In each case, can they locate the same repeated option in a predictable place, activate it, and understand what happens next? For a contact form, check that it loads and explains what information to provide; for a phone number, check the number displayed is the business’s current number; for a help article, check that the page addresses the promised topic. These checks go beyond the narrow ordering criterion, but they protect the customer outcome that motivated the work. Record any broken destination separately from a placement failure.
Do the walkthrough in both site languages and in the page variations your customers use. Chinese labels may be longer or may convey a different promise from English. A desktop link may become a mobile menu item, and an automated widget may cover the main action at narrow widths. Capture the page set, variation, repeated mechanism, relative order, and observed destination. If one page differs, the repair owner can identify the exact template or injection rule rather than searching the entire website. The final decision is modest and testable: where help repeats across related pages, a customer can find it in the same relative order and reach a working route.
One final distinction prevents an overbroad audit: a help option appearing on just one page is not a repeated mechanism for this criterion. It may still be useful and should still work, but the consistency comparison requires repetition within the page set. Conversely, a mechanism that appears on several pages cannot be ignored merely because a footer also contains a different contact route. List each repeated mechanism separately and check its own relative order. This gives editors a precise question when templates diverge: which actual route moved, on which page variation, and what would the customer encounter?
Decision checks
- The repeated help mechanisms and relevant page set are listed.
- Relative order is consistent within each page variation.
- English and Traditional Chinese routes lead to the promised help.
- Mobile, desktop, keyboard, and touch routes were exercised.
