Consistent Help

In brief

When people get stuck, they look for help. If the contact link is in the header on one page and in the footer on another, or the chat button keeps moving, those who struggle most to find it, such as people with cognitive disabilities, give up.

This criterion, new in WCAG 2.2, requires that if a web page contains help mechanisms and they repeat on multiple pages in a set of web pages, they occur in the same order relative to other page content, unless a change is initiated by the user.

What does it cover?

• The four mechanisms: Human contact details, such as a phone number, an email address or hours of operation. A human contact mechanism, such as a messaging system, chat client, contact form or social media channel. A self-help option, such as an up-to-date FAQ, a How Do I page or a support page. A fully automated contact mechanism, such as a chatbot.
• Only if you provide it: The criterion does not require you to offer help. It applies only when a listed mechanism appears on multiple pages of a set.
• Same relative order: The help keeps the same position relative to other page content. A link to a page that holds the help counts, as does help placed directly in the page.
• Serial order, not pixels: What matters is the order of the content when the page is serialised. Visual position can vary between page variations, for example at different breakpoints, although a different visual position is less helpful.
• User-initiated changes: Zoom, orientation or viewport changes can alter the order. Ordinary navigation between pages, or logging in and out, does not count.
• Set of web pages: Pages with a common purpose, made by the same author, group or organisation. Each set is evaluated separately, and a PDF downloaded from a page is not part of the set.
• Out of scope: Consistent position of navigation is 3.2.3. Redundant entry is 3.3.7.

Who does it affect?

People with cognitive disabilities and memory limitations, who find help more easily when it is always in the same place. People who experience fatigue and want to save their energy for the task. People with low vision and screen reader users, who locate help by position. Anyone stuck in a process who needs help quickly.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Help that is easy to find is part of "understandable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 3.2.6 by reference and turns it into separate clauses for each kind of ICT.

Because this criterion is new in WCAG 2.2, it is not part of EN 301 549 V3.2.1. Check clauses 10 and 11 of V4.1.1 for the rows that apply to documents and software. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: Criterion 3.2.6 is new in WCAG 2.2, so it is not part of EN 301 549 V3.2.1, which is based on WCAG 2.1. It appears in EN 301 549 V4.1.1 (September 2026), the first version prepared specifically for the EAA. V4.1.1 has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. A Contact link in a consistent place

Provide a link to contact details in the same location on every page (G220).

<!-- Home: Contact in the header; inner pages: Contact in the footer only -->

<!-- Footer on every page, in the same serial position -->
<footer>
  <a href="/help">Help</a>
  <a href="/contact">Contact us</a>
</footer>

2. A shared template for the help mechanism

Put it in one shared layout so it cannot move.

<!-- Help link added by hand to some pages -->

<!-- layout.html -->
<header>…</header>
<main>{% block content %}{% endblock %}</main>
<footer>{% include "help-links.html" %}</footer>

3. A chat widget that stays in the same order

A chat button counts as a human contact mechanism. Keep it at the same position in the page order on each page.

document.querySelector("main").prepend(chatBtn); // only on some pages

<!-- End of body on every page -->
<button type="button" id="chat">Chat with us</button>

4. A self-help link

An FAQ or a support page link follows the same rule.

<!-- FAQ link in the sidebar on some pages and in the header on others -->

<nav aria-label="Support">
  <a href="/faq">Frequently asked questions</a>
  <a href="/support">Support</a>
</nav>

5. Help in a disclosure widget

A help link inside a disclosure widget on some pages and visible on others can pass, but a consistently visible link is better (G220).

<!-- Help link in a different place on every page -->

<details>
  <summary>Need help?</summary>
  <a href="/contact">Contact us</a>
</details>

6. A chatbot that can be dismissed

A fully automated contact mechanism needs to stay in the same place as well, and be easy to close.

<!-- Chatbot opens in a different part of the page on each page -->

<aside aria-label="Virtual assistant">
  <button type="button">Ask the assistant</button>
  <button type="button">Close</button>
</aside>

Code examples for mobile

In an app, keep the help entry in the same place across screens, for example the same toolbar position or the same position in the screen order. Use one shared component.

iOS (SwiftUI)

import SwiftUI

// A shared modifier puts the help button in the same toolbar position on every screen
extension View {
    func helpToolbar(_ action: @escaping () -> Void) -> some View {
        toolbar {
            ToolbarItem(placement: .topBarTrailing) {
                Button("Help", action: action)
            }
        }
    }
}

Android (Jetpack Compose)

import androidx.compose.material3.*
import androidx.compose.runtime.Composable

@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun AppTopBar(title: String, onHelp: () -> Unit) {
    // One shared top bar, so Help is in the same place on every screen
    TopAppBar(
        title = { Text(title) },
        actions = { TextButton(onClick = onHelp) { Text("Help") } }
    )
}

How to test

• Find the help mechanisms: List contact details, contact forms, chat, FAQs, support pages and chatbots that appear on more than one page.
• Compare the order: On each page, where does the mechanism sit relative to other page content? Is it the same?
• Compare at the same variation: Test at the same zoom level, orientation and viewport size.
• Check the source order: Check the order in the markup or tab through the page. It should be the same on each page.
• Check different sets: Evaluate each set separately. A checkout or another language version may be its own set.
• Check user-initiated changes: Zoom or rotate. A change caused by that action is allowed.
• Use a checker as a starting point: Automated tools cannot compare pages. A person must compare where help is placed.

Common mistakes

• Help in a different place on different pages: The failure W3C calls "Inconsistent Help Location".
• A contact link in the header on some pages and the footer on others: The classic case.
• A chat widget that appears only on some pages: Or in a different order.
• Relying on visual position alone: The serial order must also be the same.
• Different templates for the same set: Pages of one set built from unrelated layouts.
• Treating login pages as exempt: Logging in or out is not a user-initiated change of order.
• Forgetting self-help links: FAQ and support links are also covered.
• Assuming help is required: The criterion applies only if you provide a mechanism on multiple pages.

Sources

• Understanding SC 3.2.6: Consistent Help (W3C), opens in a new tab
• G220: Provide a contact-us link in a consistent location (W3C), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.