The Five Conformance Requirements

Those four criteria are the half of requirement 5 everybody quotes. The half in front of them is a test, and it has three states rather than one.

Take anything on the page you are not relying on to meet the standard. An analytics script, a decorative animation, an optional enhancement. The page as a whole has to keep meeting the conformance requirements while that technology is switched on in a browser, while it is switched off, and where a browser does not support it at all. Three states, all three checked. The one people skip is switched on, because it sounds like the state where nothing can go wrong, and it is exactly where an optional extra traps the keyboard or starts playing audio at everybody anyway.

The requirement opens with the same idea from the other side. Where a technology is used in a way that is not accessibility supported, or used in a way that does not conform, it must not block access to the rest of the page. So the rule is not that you may only ship supported things. It is that the unsupported things have to stay out of the way.

One line at the end of the requirement decides what a claim is allowed to cover at all. A page that cannot conform, such as a page demonstrating a flashing hazard or a worked example of a failure, cannot be included in the scope of conformance or in a conformance claim. It is not excused. It is excluded, and the claim has to describe the pages it covers precisely enough that a reader can tell which side of the line a page falls on.

Conformance is judged on a web page, and the standard defines that phrase more widely than everyday speech does. A web page is a non-embedded resource obtained from a single address, plus every other resource used in rendering it or meant to be rendered along with it.

Two things follow, and both change what a claim covers. A single-page application is one web page. The standard’s own worked example is a web mail program living entirely at one address with an inbox, a contacts area and a calendar, reached by buttons that never change the address. All of that is one page, so a claim over it covers every view inside it and there is nowhere to put a broken one. And a PDF sitting at its own address is a web page too, which is why an untagged terms document fails a claim that never mentioned PDFs.

The word doing the work is non-embedded. A resource has to be non-embedded within the scope of your claim to count as a page in its own right, so the video player inside your article is part of that article rather than a separate thing you could leave out. Where several pages share a purpose and an author, they also form a set of web pages, which is the unit five criteria are measured against.

A full page includes each variation the page presents by itself for different screen sizes. Every one of those variations has to conform, or has to have a conforming alternate version, before the page conforms at all.

That is one Note under requirement 2, and it doubles the size of most audits. A responsive layout is not one page tested at one width. It is a desktop layout, a tablet layout and a phone layout, and a navigation bar that collapses into a menu button at 768 pixels is a component that exists at one width and not the other. Passing at 1440 says nothing about the version most of your visitors are looking at.

A second Note runs the other way and is worth having before anybody argues about scope. Alternatives to part of a page’s content count as part of the page when they can be obtained directly from it. A long description, or a second presentation of a video, sits inside the boundary rather than beside it.

A process is a sequence of steps that has to be completed to accomplish an activity. Where a page is one of a series presenting a process, every page in that series conforms or none of them does. The standard states the consequence itself, in a parenthesis, so nobody has to infer it. Conformance is not possible at a particular level if any page in the process does not conform at that level or better.

W3C supplies the worked example too, rather than leaving it to argument. An online store has a series of pages used to select and purchase products, and every page in that series, from the first one through to checkout, has to conform before any single page in it conforms. So a payment step with a keyboard trap takes the basket page down with it, and the product page before that, however clean either one is on its own.

This is the requirement most often broken, and the reason is structural rather than careless. It fails between pages while testing happens on pages. A sampled audit picks pages that represent the site, and a process is not a set of representative pages. It is one route that has to work end to end, so the only way to test it is to walk it, in order, the way somebody buying something would. Writing your processes down before anybody tests them is what the complete-journey inventory is for.

Every level in requirement 1 offers two routes, and the second one is the one almost nobody reads. The page satisfies the criteria, or a conforming alternate version is provided. That second route is a real part of the standard rather than a loophole, and it is demanding enough that most teams decide against it once they have read the list.

Four things have to be true. The alternate version conforms at the level being claimed. It provides all of the same information and all of the same functionality, in the same human language. It is as up to date as the content it stands in for. And one of three things has to be true about how the two versions connect. Either the conforming version can be reached from the non-conforming page by a mechanism that is itself accessibility supported. Or the non-conforming version can only be reached from the conforming one. Or it can only be reached from a conforming page that also offers a way through to the conforming version.

Same human language is the clause that catches people, because it rules out an accessible English version standing in for a page published in Welsh. As up to date is the clause that ends the idea for most teams, since it makes the second version a permanent commitment rather than a project with a finish date. Two Notes soften it slightly. The versions do not have to match page for page, and the alternate does not have to live on your own site, as long as it is as freely available as the version it stands in for.

One warning for public bodies in the United States. The Department of Justice’s Title II rule allows this route only where conformance is technically or legally impossible, so a door WCAG leaves open is narrowed by the regulation that adopts it.

Put requirements 2 and 3 together with the second route through requirement 1 and you can answer the question owners actually arrive with, which is how far a single broken thing reaches. The answer runs in three steps and then has a condition on it.

Take an illustrative shop with four pages in its checkout. A product page, a basket, a delivery step and a payment step. On the payment step the card-number field carries no name a screen reader can reach, which fails 4.1.2 Name, Role, Value at Level A.

1. The payment page does not conform. Requirement 2 will not let you carve the field out and keep the rest, so what fails is the page rather than the input.
2. Nor do the other three. All four are one process under requirement 3, and no page in a process conforms while any page in it does not, however clean the product page is on its own.
3. The rest of the site is untouched. Conformance is judged page by page, so a blog post that shares nothing with the checkout is unaffected. What moves is the claim, because any claim whose scope covered those four pages is now wrong.

Now the condition. Requirement 1 is satisfied if the page meets the criteria or if a conforming alternate version is provided, so a second payment step that conforms at Level AA would put the process back together. It has to carry the same information and the same functionality in the same human language, stay as up to date as the page it stands in for, and be reachable from the failing page by a mechanism that is itself accessibility supported. Miss any one of those four and you are back at step two with nothing gained.

Two things people expect to matter here do not. Severity does not move the line, because WCAG defines no severity scale. Neither does the count, because it defines no score either. One Level A failure on one step ends conformance for the process exactly as forty would. The severity ranking in an audit report, ours included, is a tool for deciding what to fix first, and it is ours rather than the standard’s.

Requirement 4 is two sentences and the second one is the escape route. Only accessibility-supported ways of using technologies are relied upon to satisfy the criteria. Then, any information or functionality provided in a way that is not accessibility supported is also available in a way that is. The rule governs what you rely on rather than what you are allowed to ship.

What counts as supported is a two-part test and both parts have to hold. The way the technology is used has been tested for interoperability with the assistive technology your readers have, in the human language of the content. And the technology has accessibility-supported user agents available, which any one of four things satisfies. Native support in widely distributed user agents that are themselves accessibility supported, which is how HTML and CSS qualify. Support in a widely distributed plug-in that is accessibility supported. A closed environment such as a university or corporate network where the required user agent is accessibility supported. Or user agents available to download or buy in a way that costs a person with a disability no more than anybody else and is no harder for them to find.

The human-language clause is the half nobody quotes, and it is what makes this a regional question rather than a global one. Support tested in English is evidence about English. A pattern that behaves cleanly with the screen readers your English-speaking readers use may have no support at all in the language your Polish site is written in. W3C is explicit that a technology being accessibility supported in one use does not make it supported in every use, and it declines to say how much support is enough, which leaves the judgement with whoever signs the claim.

Requirement 2 tells you an embedded widget can sink your page, which reads like a dead end. It is not one. The standard gives two ways out for pages that carry content from other people, such as a comments thread, an ad slot, or a syndicated feed.

The first is to monitor and repair. Remove or fix non-conforming third-party content within two business days and you can still claim conformance, because apart from errors corrected as they turn up, the page conforms. If you cannot monitor it, that route closes.

The second is a statement of partial conformance. You publish that the page does not conform, but would conform at your level if named parts from uncontrolled sources were removed. Named is doing the work in that sentence. You cannot describe them as everything we do not control unless they are clearly marked as such on the page.

There is a third statement almost nobody has heard of, and it is for language. Where a page would conform if accessibility support existed for the languages it uses, you can say exactly that instead.

A claim is optional. You can conform to WCAG without publishing anything, and plenty of careful sites do exactly that. Publish one and five things have to be in it. The date. The guidelines title, version and address. The level satisfied. A concise description of the pages covered, saying whether subdomains are in or out. And the list of web content technologies you relied on.

The fourth is the one that does the real work and the one people write loosest. The pages can be given as a list or as an expression covering a run of addresses, so you are not obliged to enumerate a thousand of them. What you are obliged to do is say where the edge is, and subdomains get named in or out rather than left for a reader to guess.

Five lines, and every one of them is a thing somebody can go and check. The date bounds it, so the claim is about pages as they stood that day rather than forever. The fourth line is what stops our site is accessible being the claim, because it names the pages and shuts the door on the subdomains. And the last line matters more than it looks, since anyone reproducing your result has to know which technologies had to be working for it to hold.

So if somebody hands you a claim, those five are what to read first, and a missing one is not a technicality. A statement with no date, or no scope, is a description of good intentions in the shape of a claim.

If you have a draft in front of you, the conformance claim checker walks the five components one at a time, then asks the three questions about scope that decide what the claim is allowed to cover. It checks the components rather than the pages, so it can tell you a claim is complete and never that it is true.

There is no official WCAG certification, and the reason is visible in the five components you have just read. All five are statements you write about your own pages. There is no sixth one naming somebody who approved them, because the standard sets up no body that could. Three different things get sold under the one word, and they answer three different questions.

None of the three is permanent, and the claim is the only one of them the standard describes. A claim carries a date because it describes pages as they stood on that date, so a certificate offered with no end to it is not making a stronger statement than a dated claim. It is making a vaguer one. The useful question about any of the three is the same. What was tested, on which pages, and when.

Which leaves the question of what to publish while the work is still going on, and the answer is not a badge. Our guide to writing an accessibility statement covers what to say instead, and why we issue no certificates sets out our own position on it.

Those five are the floor. W3C lists seven more things a claim may carry, and three of the seven ask for machine-readable metadata, which is a strong hint about where the standard expected claims to end up and is something no accessibility statement we have read actually does.

The optional list runs as follows. Criteria you have met above the level you are claiming. Technologies used but not relied upon. The user agents and assistive technologies you tested with. Accessibility characteristics of the content, in machine-readable metadata. Anything you did that goes beyond the success criteria. A machine-readable version of the relied-upon technology list. And a machine-readable version of the claim itself.

There is a reason to publish more than the minimum, and it is not politeness. A claim naming the technologies you did not rely on, the readers and browsers you tested with, and the criteria you met above your level is a claim somebody can check. One carrying only the five required components has to be taken on trust, which is a worse place to be standing the day a buyer or a regulator starts asking.

The first item on that optional list is also where a partial result belongs, and it is worth its own section, because reporting progress is the thing almost everybody does wrong.

Nothing is 90% conformant. A level is met in full or it is not met, and WCAG publishes no score and no partial credit for a criterion half done. What you can publish is a progress figure that carries its own denominator, and where it goes depends on whether you have reached a level yet.

If you have reached one, the standard has a slot for the rest. Requirement 1 encourages you to report progress toward criteria above the level you achieved, inside the claim, and the optional list turns that into a component you can fill in. If you have not reached a level, there is no claim to hang the number on, so what you publish is a description of the work with its numbers written out beside it. Either way the number goes with a claim or in place of one, never disguised as one.

A figure written that way looks like this.

Every number in that has something underneath it. The 51 counts criteria rather than findings, so nobody can inflate it by splitting one problem into ten. The 55 is the denominator and it is on the page rather than assumed. The 12 templates are the scope, the date bounds the lot, and the four that failed are named so a reader can go and look. Read it aloud and there is nowhere for it to be mistaken for a level.

What it never says is 93%. The arithmetic would be right and the sentence would still mislead, because the four remaining criteria are not 7% of the problem. One of them stops people buying. A percentage beside the word conformant is a number the standard has no way to interpret and a reader will interpret anyway, which is the whole reason to write the count out instead.

The same discipline applies to every number an auditor hands you, ours included. Ask whose figure it is and what the denominator was. Severity rankings, coverage shares and readiness scores are the auditor’s own instruments, and useful ones, but the standard defines none of them and none of them is a level.

Three consequences follow, and they change how you scope the work.

Your third-party components are yours. Under full pages, an embedded widget that fails means the page fails. The vendor’s conformance report is evidence, not a defence. What to ask for before signing is in briefs and contracts.

Test the journey, not the page. Complete processes is why our audits walk a whole checkout rather than sampling pages from it, and why the QA test pass is written around journeys.

A partial claim is not a claim. If you cannot say which pages conform and stand behind all of them, say what you have done instead. An honest statement describing work in progress is worth more than a conformance claim that will not survive being checked.

They are part of WCAG itself rather than an interpretation of it, which is why they travel into the laws that cite the standard. The clearest case is the DOJ’s Title II rule, which requires covered public entities to comply with the Level A and Level AA success criteria and conformance requirements specified in WCAG 2.1. That last phrase is in the regulation, so for a US public entity these five rules are binding rather than merely good practice. Of the 38 laws we cover, every one that names WCAG inherits them along with the criteria.

Two things about how to read this part of the standard. Notes are informative, which means they help you interpret a requirement and never create one. That includes the Note where W3C advises against requiring Level AAA across a whole site, on the grounds that some content cannot satisfy every AAA criterion at all. It is advice from the people who wrote the standard. It is not a rule, and it is the best answer we know of to a procurement form that asks for AAA without meaning to.

Which version of WCAG applies to you is a separate question, and a live one, because a law that names a dated version freezes that text on the day it names it. The version history works through it.