The 2025 TestParty Guide to WCAG 3.2.6 – Consistent Help (Level A)

Why did the user get lost on the website? Because the help link kept playing hide-and-seek across every page!

WCAG 3.2.6 Consistent Help ensures that when you offer help mechanisms—contact forms, phone numbers, chatbots, FAQs—they appear in the same relative position across your site. This new Level A criterion (introduced in WCAG 2.2) recognizes that people with cognitive disabilities need predictable patterns to find assistance when they're stuck.

Table of Contents

• What WCAG 3.2.6 Requires
• Why This Matters
• Quick Implementation Guide
• Common Mistakes to Avoid
• How to Test for WCAG 3.2.6
• How TestParty Helps
• FAQs

What WCAG 3.2.6 Requires

WCAG 3.2.6 Consistent Help requires that if you provide help mechanisms on multiple pages, they must appear in the same order relative to other content across those pages.

What qualifies as a "help mechanism":

• Human contact details (email address, phone number, physical address)
• Human contact mechanisms (contact forms, live chat with a person)
• Self-help options (FAQs, knowledge base, help documentation)
• Fully automated contact mechanisms (chatbots, virtual assistants)

Key points:

• You only need to provide one type of help mechanism—this criterion doesn't mandate which kind
• The help mechanism must maintain the same relative order to other page content
• Users can trigger changes (zooming, orientation shifts) that alter layout—that's fine
• The criterion applies to help mechanisms repeated across multiple pages in a set

What's exempt:

• Single-page sites (no repetition across pages)
• Help mechanisms that appear on only one page
• User-initiated layout changes (responsive breakpoints, zoom levels)

Why This Matters

People with cognitive disabilities, anxiety disorders, or memory impairments rely on consistent patterns to navigate websites. When a "Contact Us" link jumps from the header to the footer to a sidebar across different pages, it creates cognitive load and frustration.

Legal and compliance context:

WCAG 3.2.6 is a Level A requirement, making it mandatory for ADA Title II and Title III compliance, Section 508 conformance, EN 301 549 adherence, and European Accessibility Act compliance. Because it's Level A—the most basic conformance level—failure to meet this criterion exposes organizations to significant legal risk. The criterion was added in WCAG 2.2 (October 2023) specifically to address cognitive accessibility gaps.

Business impact:

Consistent help placement reduces support costs by making it easier for users to find assistance. It decreases cart abandonment in ecommerce, improves task completion rates, and builds trust. When users know exactly where to find help, they're more likely to complete transactions and return to your site.

Quick Implementation Guide

1. Audit your existing help mechanisms

Identify every place you offer help: headers, footers, sidebars, contact pages, chatbot widgets. Document their position relative to other content.

2. Standardize placement across templates

Choose one consistent location for each help mechanism type. Most sites place contact links in the header navigation or footer.

<!-- Good: Consistent footer help across all pages -->
<footer>
  <nav aria-label="Site navigation">
    <ul>
      <li><a href="/about">About</a></li>
      <li><a href="/products">Products</a></li>
    </ul>
  </nav>
  
  <!-- Help mechanisms always appear after main nav, before legal links -->
  <section aria-label="Help and support">
    <a href="/contact">Contact Us</a>
    <a href="/faq">FAQs</a>
    <a href="tel:+1-555-0100">Call: 555-0100</a>
  </section>
  
  <nav aria-label="Legal">
    <ul>
      <li><a href="/privacy">Privacy</a></li>
      <li><a href="/terms">Terms</a></li>
    </ul>
  </nav>
</footer>

3. Update component libraries and templates

If you use a design system or shared templates, update the base components so the consistent order cascades automatically to all pages.

4. Handle responsive layouts carefully

The "same order" refers to the serialized DOM order, not visual position. Your help link can move visually at different breakpoints, but it should maintain the same position in the HTML structure.

5. Document the pattern

Add the consistent help placement to your design system documentation so new pages follow the same pattern.

Relevant WCAG techniques:

• G220: Provide a contact-us link in a consistent location

Common Mistakes to Avoid

Moving help mechanisms between header and footer

Placing "Contact Us" in the header on some pages and the footer on others violates this criterion. Pick one location and stick with it.

Reordering navigation items that include help

If your main navigation includes a "Support" link, don't move it from the third position to the fifth position across different page templates.

Inconsistent chatbot placement

Loading a chatbot widget that appears in different positions relative to page content (sometimes before the footer, sometimes after) creates inconsistency. Ensure the widget loads in the same DOM position.

Forgetting about DOM order vs. visual order

Using CSS to visually reposition help links differently across pages while keeping DOM order the same is acceptable. But if you're reordering the actual HTML structure, you're creating a violation.

How to Test for WCAG 3.2.6

Automated testing catches:

• Inconsistent DOM order of identified help elements across pages
• Missing help mechanisms on pages where they should repeat

Manual testing required:

1. Identify all help mechanisms on your site (contact forms, phone numbers, FAQs, chatbots)
2. Visit 5-10 representative pages from different sections of your site
3. Use browser DevTools to inspect the DOM order of help mechanisms
4. Verify the relative position stays the same—count elements before and after the help mechanism
5. Test responsive breakpoints to ensure DOM order remains consistent even when visual layout changes

Quick checklist:

• [ ] All help mechanisms appear in the same order relative to other content across pages
• [ ] Help mechanism position is consistent in the HTML source (not just visually)
• [ ] Responsive layouts maintain the same DOM order
• [ ] User-initiated changes (zoom, orientation) don't break the pattern

How TestParty Helps

TestParty's AI-powered accessibility platform automates detection and remediation of WCAG 3.2.6 Consistent Help violations across your entire site.

What TestParty detects:

TestParty's DOM analysis engine crawls multiple pages within your site and identifies all help mechanisms—contact links, phone numbers, email addresses, chat widgets, FAQ links, and support forms. It maps the relative position of each help mechanism in the DOM tree and flags inconsistencies when the same mechanism appears in different positions across pages.

The platform recognizes common help patterns (footer contact sections, header support links, floating chat widgets) and automatically categorizes them. It detects violations even in complex scenarios: component-based architectures where different templates render help mechanisms inconsistently, JavaScript-injected widgets that load in varying positions, and responsive layouts where visual position changes but DOM order should remain stable.

How TestParty suggests fixes:

For template-based sites (WordPress, Shopify, headless CMS), TestParty generates code-level fixes that standardize help mechanism placement at the template or component level. This ensures the fix cascades across hundreds or thousands of pages automatically.

The AI analyzes your site's architecture and suggests the optimal consistent location based on existing patterns—typically recommending the most common position already in use. For sites with multiple help mechanisms, TestParty provides a prioritized remediation plan that addresses the most impactful inconsistencies first.

TestParty generates specific code patches showing exactly where to move help elements in your HTML structure. For React, Vue, or other component-based frameworks, it suggests component refactoring to ensure consistent ordering. All suggested fixes are reviewed by your team or TestParty accessibility specialists before deployment—automation with human oversight.

Developer workflow integration:

TestParty integrates directly into your CI/CD pipeline to catch WCAG 3.2.6 violations before they reach production. When a developer creates a new page template or modifies an existing one, TestParty scans the changes during the pull request and flags any help mechanism reordering.

The platform provides line-level annotations in GitHub, GitLab, or Bitbucket PRs, showing exactly where the DOM order has changed and suggesting how to restore consistency. This shift-left approach prevents regressions—once you've fixed consistent help placement, TestParty ensures new code doesn't reintroduce violations.

For large sites with multiple teams, TestParty's IDE integration provides real-time feedback as developers write code, highlighting when they're placing help mechanisms in positions that differ from the established pattern.

Ongoing monitoring:

TestParty continuously monitors your site for WCAG 3.2.6 compliance, detecting when content updates, new page templates, or third-party script changes introduce inconsistencies. The dashboard tracks help mechanism placement across your entire site, visualizing which pages conform and which need attention.

Automated regression testing runs after each deployment, ensuring that fixes remain in place and new pages follow the established pattern. For organizations managing multiple sites or white-label products, TestParty tracks consistent help compliance across all properties from a single dashboard.

Audit-ready reports document your WCAG 3.2.6 conformance with page-by-page evidence, supporting legal compliance, procurement requirements, and accessibility statements.

Some TestParty features described in this article are currently under development. Visit TestParty.ai to learn more about our current capabilities and roadmap, or book a demo at TestParty.ai/book-a-demo to see TestParty in action.

Disclaimer: Some of this article was generated with Large Language Models (LLMs) and Artificial Intelligence (AI). There may be some errors and we advise you to consult with human professionals for detailed questions.

FAQs About WCAG 3.2.6

What is WCAG 3.2.6 Consistent Help in plain language?

If you provide help options like contact forms, phone numbers, or FAQs on multiple pages, they need to appear in the same position relative to other content across all those pages. This predictability helps people with cognitive disabilities find assistance without hunting for it on every page.

Is WCAG 3.2.6 required for ADA compliance?

Yes. WCAG 3.2.6 is a Level A criterion, which means it's part of the baseline conformance level required for ADA compliance. The Department of Justice references WCAG 2.1 Level AA in recent guidance, and many organizations are already adopting WCAG 2.2 standards, which include this criterion.

Do I need to provide help mechanisms on every page?

No. WCAG 3.2.6 doesn't require you to offer help mechanisms at all—it only requires consistency when you do provide them across multiple pages. If you only have a contact form on your dedicated contact page, this criterion doesn't apply.

Does "same order" mean the exact same visual position?

Not necessarily. "Same order" refers to the order in the DOM (the HTML structure), not the visual position on screen. Your help link can appear in different visual locations at different responsive breakpoints, as long as its position in the HTML source code remains consistent relative to other elements.

What counts as a "help mechanism" under WCAG 3.2.6?

Help mechanisms include human contact details (email, phone, address), human contact methods (contact forms, live chat), self-help options (FAQs, knowledge bases, tutorials), and fully automated contact mechanisms (chatbots, virtual assistants). You only need to provide at least one of these types—the criterion focuses on consistency, not comprehensiveness.

Can users change the position of help mechanisms themselves?

Yes. User-initiated changes like zooming, changing orientation, or adjusting browser settings can alter the visual layout without violating this criterion. The requirement is that the default relative order remains consistent across pages—what users do to customize their view is their choice.