Hero image for Consistent Help, Computed: What an AI Design Agent Can and Cannot Check in WCAG 2.2 SC 3.2.6

Consistent Help, Computed: What an AI Design Agent Can and Cannot Check in WCAG 2.2 SC 3.2.6

An AI design agent that reads rendered markup already holds the one data axis that WCAG 2.2’s Consistent Help criterion actually tests. This post maps that overlap precisely: what the criterion requires, why its documented test runs on serialized order rather than visual position, and where any computable check must stop. One disambiguation first, because these two criteria are constantly conflated: SC 3.2.6 Consistent Help is Level A, while SC 3.2.3 Consistent Navigation is Level AA. The distinction drives everything below.

What SC 3.2.6 requires — and that it is Level A

The Understanding page for SC 3.2.6 Consistent Help prints the level in its heading: this is a Level A success criterion, and the SC text in WCAG 2.2 agrees. For context, What’s New in WCAG 2.2 records that WCAG 2.2 was published as a W3C Recommendation on 5 October 2023, adds nine success criteria beyond WCAG 2.1, and removes 4.1.1 Parsing; the WCAG 2.2 Recommendation is the standard itself, and the WCAG overview is the entry point. SC 3.2.6 sits under Guideline 3.2 Predictable — making pages appear and operate in predictable ways.

Paraphrased, the criterion says: if a page contains any of four help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same order relative to other page content, unless a change is initiated by the user. The four mechanisms, verbatim:

Human contact details; Human contact mechanism; Self-help option; A fully automated contact mechanism.

Typical examples include a phone number, email address, or hours of operation; a messaging system, chat client, contact form, or social media channel; an up-to-date FAQ, How Do I, or Support page; and a chatbot. The order in which the four types are listed implies no priority. Note 1 clarifies that help may be provided directly on the page or via a direct link to a different page containing the information.

The scope rule matters as much as the rule itself. The requirement triggers only when a listed mechanism repeats across multiple pages in a set; the absence of help on some pages is not a violation, and the criterion does not require authors to provide help at all. PDFs and other static documents available for download are outside the set of web pages. Consistency is required within a set — pages sharing a common purpose and created by the same author, group, or organization — and different sets may locate help differently; different language versions count as different sets. This criterion is also distinct from interface-level help such as contextual help or form instructions; the adjacent criterion is covered in Understanding SC 3.3.5 Help.

3.2.6 is A, 3.2.3 is AA — the mix-up that matters

Both levels are printed in the Understanding headings: SC 3.2.6 Consistent Help (Level A) and SC 3.2.3 Consistent Navigation (Level AA). The criteria are structural cousins — both govern repeated mechanisms across a set — but they are not interchangeable.

Dimension SC 3.2.6 Consistent Help SC 3.2.3 Consistent Navigation
Level A AA
Subject Help mechanisms Navigational mechanisms
Trigger scope A listed help mechanism repeated on multiple pages within a set of web pages Navigational mechanisms repeated on multiple pages within a set of web pages
Test focus Same serialized relative order across pages in the same page variation (Note 2) Same relative order each time repeated; insertion or removal of other items permitted
Listed sufficient technique G220: Provide a contact-us link in a consistent location G61: Presenting repeated components in the same relative order each time they appear
Listed failure “Inconsistent Help Location” — no technique ID or link exists in our sources; none is invented here F66: Failure of SC 3.2.3 due to presenting navigation links in a different relative order on different pages

Read the failure row carefully: the 3.2.6 Understanding page lists its failure only as “Inconsistent Help Location,” with no identifier and no link, and that is the whole of what the sources support.

The test is serial, not visual

Note 2 to the criterion defines the ordering axis: “the same order relative to other page content” can be thought of as how the content is ordered when the page is serialized. Note 2 also frames page variations — the user can initiate a change, such as changing the page’s zoom or orientation, which may trigger a different page variation — and states that the criterion is concerned with relative order across pages displayed in the same page variation, for example the same zoom level and orientation.

The asymmetry follows directly. If the help item is visually in a different location but in the same serial order, that is not helpful from a user’s point of view, but it would not fail the criterion. Identical serialized order in a different visual location passes. Conversely, an element visually aligned with the help on other pages but sitting at a different point in serialized order can fail, because the test is relative order, not pixels.

How the test applies, per the Understanding Intent: it is the help item that is relative to the rest of the content. Other content present across the set and before the help item on other pages should be before it on this page; items after the help item on other pages should be after it here.

One nuance prevents misreading: the Understanding document describes a consistent location, both visually and programmatically, as “the most usable” and says it is best if the mechanism is consistent across the set. That is best-practice guidance, not the conformance test. Only serialized relative order is the test.

What an agent can perceive

This is where the blog’s question — how can AI agents learn to design better? — gets a concrete answer. A design agent that ingests rendered markup holds serialized document order natively: it is the node order of the DOM, the very axis Note 2 names. No additional pipeline is needed to perceive the axis the criterion tests. The agent improves by perceiving this axis directly and by applying a declared computable rule to it, while explicitly declaring what the rule cannot decide.

What the agent does not hold by default is visual position. Coordinates require a rendering or vision step, and Note 2’s framing means the conformance test never asks for them. An agent that routes every check through screenshots is doing extra work the criterion does not require — and risks failing pages that pass.

Variation capture is a configuration problem, not a perception problem. The Understanding document scopes the user-initiated exception to actions intended to change the display or layout of a page — changing the zoom level, orientation, or viewport size — and explicitly declines to treat every user action as a change: merely navigating between pages within a set is not a “change initiated by the user,” and logging in or out would not typically qualify unless logging in presents a distinct set of web pages. So the agent captures each variation, a fixed zoom × orientation configuration, separately and never compares across variations.

Two honest perception limits belong on the record here, and the first resurfaces below. Classifying which element is a help mechanism is a semantic judgment: the Understanding doc’s examples are labeled “typical,” not exhaustive, so no purely structural rule reliably separates a help mechanism from adjacent chrome. And set membership is defined by common purpose and same authorship — with different language versions as different sets — not by any computable segmentation rule in the sources reviewed. Both are escalation points, not compute tasks.

The computable check: the Serial Help-Order Check (SHOC)

Frame this precisely: SHOC is this guide’s own operationalization of Note 2 and the Understanding Intent paragraph. The W3C sources reviewed contain no step-by-step normative test procedure for 3.2.6; the Intent text is prose, not a protocol. A SHOC pass is a signal, not a conformance claim, and techniques remain sufficient rather than exhaustive — the Understanding page lists one sufficient technique, G220: Provide a contact-us link in a consistent location, while Understanding Techniques for WCAG Success Criteria explains that other ways of meeting a criterion may exist. G220 is cited by title and link only; its body text is not reconstructed here.

Name: Serial Help-Order Check (SHOC).

Inputs (human-declared, not computed): (1) Set S — the list of page URLs forming one set of web pages; (2) Variation V — a fixed capture configuration of zoom level + orientation; (3) per page, the node H identified as the help mechanism, with its type label (one of the four, C6/C7) recorded as an assumption.

Per page P ∈ S under V: (a) render P at V and read the serialized document order of the DOM; (b) locate H(P); if no help mechanism exists on P, mark P “no-help” and exclude it from comparison (C19); (c) collect shared items — nodes whose stable signature (role + accessible name + link target) appears on two or more pages of S (this signature rule is our implementation choice); (d) for each shared item X, record rel(X,H) ∈ {before, after} in document order; (e) emit the relation vector R(P).

Decision: PASS for (S,V) iff R(P) is identical across every page of S that carries a help mechanism; FAIL otherwise, with the divergent page pairs as evidence; INCOMPARABLE if fewer than two pages carry help (the rule says nothing). Insertion or removal of other items between pages does not change relative order (C28, the “same relative order” note carried on the 3.2.3 Understanding page). Run SHOC independently per variation; cross-variation differences are permitted, not failures (C10, C16, C17).

What SHOC cannot decide

Five questions stay outside the rule, and naming them is the point:

  1. Findability — whether help is findable by users; the Understanding doc explicitly separates serial consistency from helpfulness (C12).
  2. Usefulness — whether the help is useful, current, or accurate; the SC does not address this.
  3. Human-ness — whether a contact is genuinely human or responsive; mechanism typing is semantic and the examples are non-exhaustive (C7).
  4. Set membership — defined by purpose and authorship, with no computational segmentation in the sources reviewed (C25).
  5. Conformance — no W3C test procedure for 3.2.6 appears in the sources reviewed, and a SHOC pass is not a conformance claim (C27, C30).

The falsifier: how to prove SHOC wrong

A rule that cannot be proven wrong is an assertion. SHOC — or any implementation of it — is falsified by a concrete page-set observation where its verdict contradicts the verdict implied by the W3C texts: the SC, Note 2, the Intent testing paragraph, and the same-relative-order note. Four named falsifiers:

  1. Insertion case. Page B inserts an extra item before the help node relative to page A while every shared item keeps its before/after relation to help. The correct verdict is PASS (C28); an implementation comparing absolute document indices and failing this is falsified.
  2. Visual-only case. Identical serialized order, different visual placement. The correct verdict is PASS (C12); any version that ingests visual coordinates and fails this is falsified.
  3. Cross-variation case. Orders differ between zoom levels. Differences across variations are permitted (C10, C16); a run that pools variations and fails the set is falsified.
  4. Absence case. A no-help page triggers FAIL. Falsified by C19: absence of a help mechanism on a page is not a violation.

The falsifier of the rule itself — not just its implementations — is any W3C statement or erratum redefining the 3.2.6 test onto something other than serialized order, or restoring visual position as part of the test. Monitor the WCAG 2.2 errata page for exactly that.

Wiring it into a design system

This section is this guide’s recommendation, never a W3C requirement.

  • Declare page sets in design-system config. Which URLs constitute a set is a human decision grounded in common purpose and authorship (C25); the config records it, and the check consumes it.
  • Capture per variation. Snapshot at fixed zoom × orientation combinations so comparisons never cross variations (C16, C17); a vector captured at one variation is compared only against vectors from the same variation.
  • Run SHOC as a gate on templates. Templates, not pages, are where relative order is actually authored; a template-level FAIL is the actionable signal, with divergent page pairs as evidence.
  • Escalate the semantic edges. The classification of which node is H, and the set definition itself, go to maintainers as assumptions to confirm, not outputs to trust.

Close with the nuance that keeps the recommendation honest: keep visual consistency anyway. The Understanding document calls a consistent location, both visually and programmatically, “the most usable” (C17) — even though only serialized order is the test (C12). Compute the order; do not mistake the computation for the whole of usability.

FAQ

Is SC 3.2.6 AA?

No. SC 3.2.6 Consistent Help is Level A. The criterion it is often confused with, SC 3.2.3 Consistent Navigation, is Level AA.

Must every page offer help?

No. The criterion specifically pertains to pages that do include a help mechanism; the absence of a help mechanism on certain pages within a set does not constitute a violation, and the SC does not require authors to provide help at all.

Yes. Note 1 states that help mechanisms may be provided directly on the page, or via a direct link to a different page containing the information.

Help sits in a different visual spot on mobile — is that a fail?

Not necessarily. Changing zoom or orientation can trigger a different page variation, and the criterion is concerned with relative order across pages displayed in the same page variation. Compare within a variation; cross-variation differences in location are permitted, though consistency across variations remains best practice because a consistent location, visually and programmatically, is the most usable.

Is a chatbot enough?

The SC requires no help mechanism at all, so “enough” is the wrong frame. When help is provided, the Understanding doc’s chatbot guidance is advisory, not required: chatbots work particularly well for people with cognitive disabilities if they recognize misspelled words, provide human contact details if the chatbot is unable to provide a satisfactory response after 3 attempts, and can be dismissed with a single interaction and recalled using a link or button. Related advisory patterns live in COGA-Usable’s support user story, the COGA gap analysis table, and the make-it-easy-to-find-help-and-give-feedback pattern.

Is G220 mandatory?

No. G220: Provide a contact-us link in a consistent location is the listed sufficient technique, and sufficient techniques are not exhaustive — there may be other ways of meeting the criterion not covered by the listed techniques. It is cited here by title and link only.

Do PDFs count?

No. PDFs and other static documents that may be viewed or downloaded from the web pages are not considered part of the set of web pages from which they are downloaded.

Are different language versions one set?

No. Different language versions are considered different sets of web pages.

The Bottom Line

Verdict: SC 3.2.6 Consistent Help is Level A, and its documented test runs on the one axis an AI design agent perceives natively — serialized order, not visual position. The Serial Help-Order Check computes set-wide, variation-scoped relative order quickly, with no-help pages excluded and cross-variation differences permitted. It cannot decide findability, usefulness, the human-ness of a contact, set membership, or conformance. Compute what is computable; escalate the rest; and keep visual consistency as best practice, because “most usable” and “the test” are different claims.

How This Guide Was Built

This post is built entirely from W3C WAI sources: the Understanding documents for SC 3.2.6 and SC 3.2.3, What’s New in WCAG 2.2, the WCAG 2.2 Recommendation, and the technique page titles and links for G220, G61, and F66. No hands-on tests, site audits, or user testing were run, and no real site is presented as an examined example. SHOC is this guide’s derivation from Note 2 and the Understanding Intent paragraph; the sources reviewed include no step-by-step test procedure for 3.2.6. G220 is cited by title and link only because its body text was outside the source set reviewed.