How is a WCAG success criterion written, and how does it differ from a published technique?

middlenice to knowfreq 26%

answer

Only one layer is pass or fail
Numbered, titled, levelled and testable
Exceptions are part of the requirement
The examples alongside are not requirements

basics

~20 s

A success criterion is a normative, testable statement carrying a conformance level and often explicit exceptions. Techniques and failures published alongside it are informative examples: you conform by satisfying the criterion by any means, not by copying a listed technique.

solid answer

~50 s

Each success criterion has a number, a title, a level, one requirement written to be testable, and sometimes explicit exceptions. Testable is doing real work there: a criterion must be verifiable by machine or by human inspection with reliable agreement between competent testers, which is why the criteria read like specifications rather than advice. The material published alongside them is informative: sufficient techniques are documented ways known to satisfy a criterion, advisory techniques go further than required, and documented failures are patterns known to fail one. Conformance is measured against the criterion, so a novel implementation with no matching technique can still conform. Exceptions are part of the requirement rather than an escape hatch — and they move with the level, which is why the same subject can appear at AA with exceptions and at AAA without them.

Each success criterion has a **number**, a **title**, a **level**, one requirement written to be testable, and sometimes explicit **exceptions**. Testable is doing real work there: a criterion must be verifiable by machine or by human inspection with reliable agreement between competent testers, which is why the criteria read like specifications rather than advice. The material published alongside them is **informative**: *sufficient techniques* are documented ways known to satisfy a criterion, *advisory techniques* go further than required, and *documented failures* are patterns known to fail one. Conformance is measured against the criterion, so a novel implementation with no matching technique can still conform. Exceptions are part of the requirement rather than an escape hatch — and they move with the level, which is why the same subject can appear at AA with exceptions and at AAA without them.

code

pseudocode · 12 lines

pseudocode

SUCCESS CRITERION
  number:      <principle>.<guideline>.<position>
  title:       short name, cited in tickets
  level:       A | AA | AAA
  requirement: one statement, true or false of a page
  exceptions:  named cases the requirement does not reach

PUBLISHED ALONGSIDE (informative, not required)
  sufficient techniques : ways known to satisfy it
  advisory techniques   : go further than required
  documented failures   : patterns known to fail it
  understanding document: intent and edge cases

go deeper

for a junior

Recall that WCAG's actual requirements are the numbered success criteria and that the surrounding guidance is examples rather than rules. You are not expected to quote a criterion from memory at this level.

for a middle

Explain the anatomy — number, title, level, one testable statement, exceptions — and why the working group insisted every criterion be testable. Be ready to say why a technique list is not the requirement.

for a senior

Show that you use the distinction in review: findings are written against criteria, techniques are shortcuts, and an exception narrows a requirement rather than excusing it. That is what keeps audit findings defensible under challenge.

for a principal

The angle you own is process. Whether teams chase technique lists instead of criteria decides how fast your internal guidance rots, since the informative material is revised far more often than the criteria themselves.

The anatomy of a success criterion

Strip one down and you find six parts, in a fixed shape:

A number, which encodes principle, guideline and position.
A title, short enough to cite in a ticket.
A level — A, AA or AAA — fixed when the criterion is published.
One requirement: a statement that is either true or false of a page.
Optional exceptions: named cases the requirement does not reach.
Defined terms it leans on, which the standard defines formally so two testers read the same words the same way.

The requirement is written to be testable. That is a hard constraint the working group imposed on itself: each criterion must be verifiable either by machine or by human inspection that competent testers can agree on. It is the reason the criteria read like specifications and never like coaching.

Normative and informative — the layer that decides conformance

Artefact	Status	What it does for you
Success criterion	Normative and testable	The statement you pass or fail; the only thing a conformance claim is made of
Guideline and principle	Part of the standard, but not testable	Organise the criteria and explain their intent
Sufficient technique	Informative	One documented way that is known to satisfy the criterion
Advisory technique	Informative	Goes beyond what the criterion actually requires
Documented failure	Informative	A pattern known not to satisfy a named criterion
Understanding document	Informative	Intent, benefits, edge cases and worked examples

Three consequences follow, and they are the reason this distinction is worth an interview question:

You can conform without using any published technique. The technique lists are examples, not an approved-vendor list. A team that invents a new interaction pattern is not automatically non-conformant; it simply carries the burden of showing the criterion's statement is satisfied.
A documented failure is strong evidence, not the finding itself. Citing one shortens the argument enormously, but the finding you record is still 'this fails criterion X', with the failure pattern as the reason.
The informative material moves faster than the standard. Technique documents are maintained alongside the Recommendation and updated more often than the criteria are. An internal checklist copied from a technique list therefore rots; one written against criteria does not.

Exceptions, and how they move with the level

An exception is part of the requirement. It narrows what the criterion asks for, and it is not a waiver a team can invent by writing a justification in a ticket.

The clearest illustration is one subject at two levels. 1.4.5 Images of Text, at level AA, requires text rather than images of text where the technology can achieve the presentation — with exceptions where the image of text is customisable to the user's requirements and where a particular presentation is essential. 1.4.9 Images of Text (No Exception), at level AAA, is recognisably the same requirement with the exceptions removed. That pairing shows exactly what a higher level buys: not a different subject, but a requirement that reaches further into the edge cases.

Exceptions show up everywhere once you look. 2.2.1 Timing Adjustable, at level A, excepts real-time events and cases where the time limit is essential. 2.4.5 Multiple Ways, at level AA, excepts a page that is a step in a process, because a checkout step is supposed to be reachable one way. Reading the exceptions is often what separates a defensible finding from an argument.

What this changes in practice

Write findings against criteria, with number, title and level. A finding written against a technique cannot be closed, because satisfying the criterion by another route is legitimate.
Read the exceptions before raising a defect. A large share of disputed findings are exceptions the reporter did not read.
Keep internal guidance one step removed from technique lists. Say what the criterion requires, then offer your house pattern as one way to meet it.
Never treat an understanding document as a requirement. It explains intent and is invaluable for that, but it adds nothing to what must be true.

This is a differentiator rather than a gate: nobody's offer has turned on knowing that techniques are informative. But a candidate who knows it will not spend a sprint chasing a technique list as though it were the requirement, and will not concede a finding just because their implementation is not on the list.

## The anatomy of a success criterion Strip one down and you find six parts, in a fixed shape: 1. A **number**, which encodes principle, guideline and position. 2. A **title**, short enough to cite in a ticket. 3. A **level** — A, AA or AAA — fixed when the criterion is published. 4. One **requirement**: a statement that is either true or false of a page. 5. Optional **exceptions**: named cases the requirement does not reach. 6. **Defined terms** it leans on, which the standard defines formally so two testers read the same words the same way. The requirement is written to be **testable**. That is a hard constraint the working group imposed on itself: each criterion must be verifiable either by machine or by human inspection that competent testers can agree on. It is the reason the criteria read like specifications and never like coaching. ## Normative and informative — the layer that decides conformance | Artefact | Status | What it does for you | |---|---|---| | Success criterion | **Normative and testable** | The statement you pass or fail; the only thing a conformance claim is made of | | Guideline and principle | Part of the standard, but not testable | Organise the criteria and explain their intent | | Sufficient technique | **Informative** | One documented way that is known to satisfy the criterion | | Advisory technique | **Informative** | Goes beyond what the criterion actually requires | | Documented failure | **Informative** | A pattern known not to satisfy a named criterion | | Understanding document | **Informative** | Intent, benefits, edge cases and worked examples | Three consequences follow, and they are the reason this distinction is worth an interview question: - **You can conform without using any published technique.** The technique lists are examples, not an approved-vendor list. A team that invents a new interaction pattern is not automatically non-conformant; it simply carries the burden of showing the criterion's statement is satisfied. - **A documented failure is strong evidence, not the finding itself.** Citing one shortens the argument enormously, but the finding you record is still 'this fails criterion X', with the failure pattern as the reason. - **The informative material moves faster than the standard.** Technique documents are maintained alongside the Recommendation and updated more often than the criteria are. An internal checklist copied from a technique list therefore rots; one written against criteria does not. ## Exceptions, and how they move with the level An exception is part of the requirement. It narrows what the criterion asks for, and it is not a waiver a team can invent by writing a justification in a ticket. The clearest illustration is one subject at two levels. **1.4.5 Images of Text**, at level AA, requires text rather than images of text where the technology can achieve the presentation — with exceptions where the image of text is customisable to the user's requirements and where a particular presentation is essential. **1.4.9 Images of Text (No Exception)**, at level AAA, is recognisably the same requirement with the exceptions removed. That pairing shows exactly what a higher level buys: not a different subject, but a requirement that reaches further into the edge cases. Exceptions show up everywhere once you look. **2.2.1 Timing Adjustable**, at level A, excepts real-time events and cases where the time limit is essential. **2.4.5 Multiple Ways**, at level AA, excepts a page that is a step in a process, because a checkout step is supposed to be reachable one way. Reading the exceptions is often what separates a defensible finding from an argument. ## What this changes in practice - **Write findings against criteria**, with number, title and level. A finding written against a technique cannot be closed, because satisfying the criterion by another route is legitimate. - **Read the exceptions before raising a defect.** A large share of disputed findings are exceptions the reporter did not read. - **Keep internal guidance one step removed from technique lists.** Say what the criterion requires, then offer your house pattern as one way to meet it. - **Never treat an understanding document as a requirement.** It explains intent and is invaluable for that, but it adds nothing to what must be true. This is a differentiator rather than a gate: nobody's offer has turned on knowing that techniques are informative. But a candidate who knows it will not spend a sprint chasing a technique list as though it were the requirement, and will not concede a finding just because their implementation is not on the list.

If no published technique matches your implementation, can you still conform?
Yes. Conformance is measured against the success criterion, not against a technique list. Techniques are informative examples of routes known to be sufficient, so a novel implementation conforms if it satisfies the criterion's statement and its exceptions. The burden shifts to you to show that it does, which is exactly why teams prefer documented techniques where they exist.
What weight does a documented failure carry in an audit finding?
Strong evidence, but the finding is still written against the criterion. A documented failure is a pattern the working group states does not satisfy a named criterion, so citing it removes most of the argument about whether the pattern is acceptable. What you record is that the criterion is unmet, with the failure pattern given as the reason.

saying these in an interview costs you the question

Treats a published technique as the requirement itself
Thinks an implementation absent from the list cannot conform
Reads an exception as permission to skip the criterion
Believes the guidelines themselves are testable statements
Cites an explanatory document as a normative requirement

How is a WCAG success criterion written, and how does it differ from a published technique?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The anatomy of a success criterion

Normative and informative — the layer that decides conformance

Exceptions, and how they move with the level

What this changes in practice

▾common follow-ups2 questions

▾red flags5 flags

The anatomy of a success criterion

Normative and informative — the layer that decides conformance

Exceptions, and how they move with the level

What this changes in practice

answer

go deeper