WCAG 3.2.6: Consistent Help

What This Rule Means

WCAG Success Criterion 3.2.6 Consistent Help (Level AA, introduced in WCAG 2.2) states: "If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages, they occur in the same relative order to other page content, unless a change is initiated by the user." The help mechanisms covered by this criterion are: human contact details (such as a phone number, email address, or hours of operation), a human contact mechanism (such as a live chat widget or a contact form), a self-help option (such as a frequently asked questions page, a help center, or a knowledge base), and a fully automated contact mechanism (such as a chatbot or virtual assistant).

The key requirement is consistency of relative order, not identical pixel placement. If a live-chat button appears in the bottom-right corner of the homepage, it must appear in the same bottom-right position on every other page that displays it. If a "Help" link is the third item in the top navigation bar on one page, it must remain the third item — or at least maintain the same relative relationship to surrounding content — on all other pages where that navigation bar appears.

A page passes this criterion when: (a) no help mechanism exists on the site, or (b) a help mechanism exists on only one page, or (c) wherever a help mechanism is repeated across multiple pages it appears in the same relative order within the page layout. A page fails when a help mechanism that is present on multiple pages shifts its position in the page order from one page to another without the user having initiated that change — for example, a chat widget that floats in the bottom-right on the product listing page but moves to the bottom-left on the checkout page.

The criterion includes an explicit exception: the order may change if the user initiates the change. For instance, if a user drags and repositions a floating help widget, or if a user preference toggles the help panel from one side to another, that repositioning is user-initiated and does not constitute a failure. This exception mirrors the same user-initiated logic found in SC 3.2.2 (On Input).

It is important to note that this criterion does not require every page to have a help mechanism, nor does it require the help mechanism to be effective or easy to use. It only governs positional consistency when the mechanism is present on multiple pages.

Why It Matters

Consistent help placement is primarily designed to benefit users with cognitive disabilities, including people with memory impairments, attention difficulties, learning disabilities such as dyslexia, and conditions such as ADHD or early-stage dementia. For these users, locating a familiar interface element takes deliberate cognitive effort. When a help button or contact link appears in a different location on every page, they must expend that effort repeatedly, increasing cognitive load and the risk of frustration, disorientation, or task abandonment.

Users who are new to the web or have limited digital literacy — a significant population in Turkey and globally — also rely heavily on predictable placement. According to the World Health Organization, over 1.3 billion people worldwide live with some form of disability, and cognitive and neurological conditions represent a substantial share of that population. Designing for positional consistency therefore serves a broad audience far beyond those with clinically diagnosed disabilities.

Consider a concrete scenario: a user with early-stage Alzheimer's disease is trying to complete an online flight booking. She remembers that the airline's website has a live-chat option she can use when she gets confused. On the search results page, the chat icon appears in the bottom-right corner. But when she moves to the seat-selection page, the chat widget has been relocated to the top-right corner within a collapsible help drawer. She cannot find it, becomes overwhelmed, and abandons the booking entirely. This is a direct, preventable failure of SC 3.2.6.

For motor-impaired users who navigate with switch access, eye-tracking software, or head pointers, repositioning a help mechanism means re-scanning and re-targeting a new area of the screen — an effortful and time-consuming process that consistent placement eliminates.

Screen reader users who have memorized the tab order or heading structure of a site to quickly reach the help section are equally affected when the DOM order of that mechanism changes from page to page, even if the visual position looks similar.

Beyond accessibility, there is a clear usability and business benefit: users who can quickly find help are less likely to abandon a transaction, reducing drop-off rates and support costs. Consistent UI patterns also reinforce brand trust and professionalism.

Related Axe-core Rules

WCAG 3.2.6 is classified as requiring manual testing only and does not have a corresponding automated axe-core rule that can flag violations programmatically. This is by design, and understanding why helps testers appreciate the nature of this criterion.

• Manual inspection required — no axe rule available: Automated tools such as axe-core, Lighthouse, or IBM Equal Access Checker analyze a single page in isolation. They have no inherent understanding of what a "help mechanism" is, no ability to compare the relative DOM position of an element across multiple page loads or URLs, and no way to determine whether a given element serves the functional role of providing help. A chat widget, for example, might be implemented as a plain <div>, a shadow DOM component, an <iframe>, or a third-party injected script — none of which can be reliably identified as a "help mechanism" by a rule engine without human judgment. Axe-core would need cross-page state awareness and semantic intent recognition to flag this, capabilities that fall outside the scope of single-page static analysis. This is why WCAG 2.2 itself labels 3.2.6 as a criterion that requires human evaluation through structured manual audits and cross-page comparison.

How to Test

1. Inventory help mechanisms: Before testing individual pages, create a list of all help mechanisms present on the site — live chat widgets, contact phone numbers, email links, FAQ links, chatbot launchers, contact forms, and help center links. Note which pages each mechanism appears on. If a mechanism appears on only one page, it is out of scope for this criterion.
2. Run an automated scan for baseline context: Use axe DevTools (browser extension) or Lighthouse on representative pages to capture DOM order snapshots and identify the structural position of help-related elements. While no axe rule directly targets SC 3.2.6, the DOM order reported by these tools can be compared manually across pages. Export or screenshot the accessibility tree for each page containing a help mechanism.
3. Compare relative positions across pages: Open two or more pages that share the same help mechanism side by side (or sequentially). For each mechanism, identify its position relative to surrounding landmark regions (<header>, <main>, <footer>, <nav>). Record whether the mechanism appears in the same landmark region and in the same relative order (before or after adjacent elements) on every page. A change in position constitutes a potential failure.
4. Test with keyboard navigation (all browsers): Tab through each page containing a help mechanism. Count the number of tab stops required to reach the help mechanism from the start of the page. Compare this count across pages. A significant difference — say, reachable in 5 tabs on the homepage but 47 tabs on the checkout page — indicates a change in DOM order even if the visual position appears similar.
5. Test with NVDA + Firefox: Open the NVDA Elements List (NVDA key + F7) and switch to the Links or Buttons view. Locate the help mechanism in the list. Note its position relative to other listed elements. Repeat on each page where the mechanism appears and compare positions.
6. Test with VoiceOver + Safari (macOS/iOS): Use the VoiceOver rotor (VO + U) to open the Links or Form Controls list. Navigate to the help mechanism and note its position in the list. Compare across pages.
7. Test with JAWS + Chrome: Use the JAWS Links List (Insert + F7) to locate the help mechanism. Note its ordinal position and adjacent elements. Repeat across pages.
8. Check user-initiated exceptions: If the site allows users to reposition or hide help mechanisms (e.g., a draggable chat widget), verify that the repositioning is triggered by an explicit user action and that the preference persists logically. Document this as a valid exception under the criterion.
9. Review on mobile viewports: Responsive layouts sometimes reorder DOM elements at different breakpoints. Test on both desktop and mobile viewports (375px and 1440px widths as a minimum) to confirm the help mechanism maintains consistent relative placement at all common screen sizes.

How to Fix

Floating chat widget — Incorrect

<!-- Page A (homepage): chat button in bottom-right -->
<div class='chat-widget' style='position:fixed; bottom:20px; right:20px;'>
  <button>Chat with Us</button>
</div>

<!-- Page B (checkout): chat button moved to bottom-left -->
<div class='chat-widget' style='position:fixed; bottom:20px; left:20px;'>
  <button>Chat with Us</button>
</div>
<!-- FAIL: The widget changes its fixed position between pages,
     breaking consistent help placement. -->

Floating chat widget — Correct

<!-- Both Page A and Page B: chat button consistently in bottom-right -->
<div class='chat-widget chat-widget--bottom-right'>
  <button type='button' aria-label='Open live chat support'>
    Chat with Us
  </button>
</div>
<!-- PASS: The widget appears in the same corner on every page.
     Use a CSS class defined in a shared stylesheet rather than
     inline styles, so the position is controlled centrally and
     applied consistently across all templates. -->

Help link in navigation — Incorrect

<!-- Page A: Help is the 4th nav item -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>

<!-- Page B (product detail): Help link removed from nav,
     placed in a footer section instead -->
<footer>
  <a href='/help'>Help Center</a>
</footer>
<!-- FAIL: The Help link has moved from the main navigation
     to the footer, changing its relative order significantly. -->

Help link in navigation — Correct

<!-- Both Page A and Page B share the same navigation template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>
<!-- PASS: The Help link is the 4th item in the main nav
     on every page where the nav is present. Using a shared
     navigation component or server-side include ensures
     this is maintained automatically. -->

Conditional help display — Incorrect

<!-- On logged-out pages: phone number in header -->
<header>
  <p>Need help? Call <a href='tel:+908501234567'>0850 123 45 67</a></p>
</header>

<!-- On logged-in pages: phone number removed from header,
     only available deep inside an account dropdown menu -->
<header>
  <nav aria-label='Account menu'>
    <details>
      <summary>My Account</summary>
      <ul>
        <li><a href='/orders'>Orders</a></li>
        <li><a href='/contact'>Contact: 0850 123 45 67</a></li>
      </ul>
    </details>
  </nav>
</header>
<!-- FAIL: The contact number changes its relative position
     dramatically depending on authentication state,
     making it unpredictable for returning users. -->

Conditional help display — Correct

<!-- Both logged-out and logged-in pages: phone in the same header position -->
<header>
  <div class='header-support'>
    <a href='tel:+908501234567' aria-label='Call support: 0850 123 45 67'>
      <svg aria-hidden='true' focusable='false'><!-- phone icon --></svg>
      0850 123 45 67
    </a>
  </div>
  <nav aria-label='Account menu'>
    <!-- account links here -->
  </nav>
</header>
<!-- PASS: The contact mechanism is always in the same position
     within the header regardless of authentication state.
     Additional account-specific links can appear elsewhere
     without moving the help mechanism. -->

Common Mistakes

• Placing the chat widget in different corners on different page templates: Development teams often apply fixed positioning for chat widgets on a per-template basis rather than through a global stylesheet, causing the widget to appear bottom-right on marketing pages and bottom-left on app pages. Use a single globally included component with a locked position class.
• Removing the help link from the navigation on checkout pages to reduce clutter: Some UX patterns intentionally strip navigation on checkout pages for conversion optimization. If a help mechanism is part of that navigation, removing it from this page template breaks consistency. Instead, retain the help link in a minimal header even on stripped checkout flows.
• Injecting help mechanisms via third-party scripts that load with unpredictable DOM positions: Many live-chat SDKs inject their widget into the DOM asynchronously, and their insertion point may vary based on script load order. This can cause the widget to appear at a different position in the accessibility tree across pages. Configure third-party widgets to always append to a fixed, known DOM anchor element.
• Using CSS order or flexbox/grid reordering to visually move the help element without changing DOM order, then changing that CSS per page: While the visual position may appear consistent, per-page CSS overrides that alter the visual order of a help mechanism still change the user-perceivable order and can confuse screen reader users whose reading order follows the DOM.
• Relying on A/B testing tools that swap the position of the help element between test variants: If users in variant A see the help button in the top bar and users in variant B see it in the footer, those users will experience inconsistent help placement across pages within their session as the A/B framework applies different variants on different pages. Ensure A/B tests that affect help mechanism placement apply the variant consistently across all pages in a session.
• Treating authenticated and unauthenticated states as different "sites" and applying different help layouts: Users who log in mid-session will suddenly find the help mechanism in a new location. The authentication state change is not user-initiated in the context of help placement, so this still fails SC 3.2.6. Apply a consistent help layout across all authentication states.
• Embedding the help phone number only within dense footer text on some pages and in a dedicated header bar on others: Even if the phone number is technically present on all pages, a significant change in its relative position (from the first interactive element in the header to buried in the footer after hundreds of links) is a failure of consistent order.
• Assuming that because a help icon is always visually "in the corner" it passes the criterion: The criterion measures relative order in the page content, not just absolute pixel coordinates. A chat icon that is always visually bottom-right but appears at a wildly different point in the DOM order on different pages (e.g., immediately after the <body> tag on one page and just before the closing </body> tag on another) may still fail for keyboard and screen reader users.
• Forgetting to audit responsive breakpoints: A help mechanism that is consistent at desktop widths may be hidden or moved into a mobile hamburger menu at narrow viewports, resulting in a different position on mobile. If mobile users experience a different relative position than desktop users, this should be evaluated against the criterion — particularly if mobile is the primary access method for the target audience.
• Not documenting help mechanism locations in design systems: Without a documented standard for where help mechanisms must appear, individual developers and designers will make independent decisions that produce inconsistencies over time. Add help mechanism placement rules explicitly to your design system or component library documentation.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette numbered 32933 on June 21, 2025, establishes a comprehensive national framework for digital accessibility. The circular mandates conformance with WCAG 2.2 Level AA as the baseline accessibility standard for a wide range of digital services operating in Turkey. WCAG 3.2.6 Consistent Help, as a Level AA criterion introduced in WCAG 2.2, falls directly within the scope of this legal obligation.

The entity types covered by Presidential Circular 2025/10 include: public institutions and agencies at both central and local government levels; banks and financial service providers regulated under the Banking Regulation and Supervision Agency (BDDK); e-commerce platforms and online marketplaces; hospitals and healthcare providers offering patient-facing digital services; telecommunications companies with 200,000 or more subscribers; travel agencies with online booking systems; private transportation companies operating scheduled services; and private schools and educational institutions authorized by the Ministry of National Education (MoNE). For all of these entities, the full WCAG 2.2 Level AA criterion set — including SC 3.2.6 — is the applicable standard.

Compliance with WCAG 3.2.6 is also a prerequisite for obtaining the Erişilebilirlik Logosu (Accessibility Logo) issued by the Turkish Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı). This logo serves as an official mark of accessibility conformance and is increasingly recognized by Turkish consumers and procurement officers as a quality signal. Organizations seeking the logo must demonstrate full WCAG 2.2 Level AA conformance across their digital properties, meaning that inconsistent help placement — even if seemingly minor — can disqualify an application.

From a practical compliance standpoint, SC 3.2.6 is particularly relevant for Turkish e-commerce and financial service providers, whose websites and mobile web apps typically feature live-chat widgets, WhatsApp contact links, and FAQ sections as primary customer support channels. Ensuring that these help mechanisms appear in consistent positions across product listing pages, cart pages, checkout flows, and account management sections is both a legal obligation under the Circular and a sound UX practice for serving Turkey's diverse internet user base — which includes a large population of first-time and low-literacy digital users who benefit most from predictable interface patterns.

Organizations subject to the Circular that have not yet audited their help mechanism placement should prioritize a cross-page consistency audit as part of their WCAG 2.2 compliance roadmap. Because this criterion requires manual testing, it should be included in both initial conformance audits and ongoing quality assurance cycles, particularly after major redesigns or template changes that may inadvertently shift the position of help elements.