The Standards Landscape
WCAG, ARIA, ATAG and EN 301 549 do four different jobs, and knowing which one governs a given requirement is half of the WAS exam. Lesson 1 of the A11ytek WAS course, free to read.
What this covers, and why the exam cares
The WAS assumes you already know what WCAG is. What it tests is whether you know which document governs what, what carries normative weight, and what happens where more than one applies.
That sounds like bookkeeping. It is not. Half the arguments you will have in a real project are really disagreements about which document applies: a developer citing a technique as though it were a rule, a vendor claiming conformance against a standard that does not cover their product, a client asking for WCAG 2.2 on a contract that names 2.0.
How W3C documents work
The Web Accessibility Initiative sits inside W3C and produces most of what you will cite.
A document travels through draft stages and ends as a W3C Recommendation, which is the stable published version. WCAG 2.0, 2.1 and 2.2 are all Recommendations, and all three remain published; a newer version does not withdraw an older one. That is why a contract naming 2.0 is still coherent in 2026.
The distinction that matters most on this exam is normative versus non-normative.
Normative material defines conformance. In WCAG that means the success criteria and the conformance requirements, and nothing else.
Non-normative material is informative. Techniques are non-normative. So are the Understanding documents, and so is the ARIA Authoring Practices Guide. They tell you how something is usually done and why the criterion exists. They do not define success.
Two practical consequences, both examinable.
You can satisfy a success criterion by a method W3C never documented, and you have conformed. Nobody can fail you for inventing a valid solution.
And a Failure technique is not a rule either. It documents something that does fail a criterion, which makes it strong evidence, but the criterion is still what you cite. Write the report against the success criterion; use the technique number as support.
WCAG, briefly, because you know this
Four principles, thirteen guidelines, success criteria at A, AA and AAA, and techniques underneath. The CPACC covers the shape; the WAS cares about the edges.
2.1 added seventeen criteria, largely for mobile, low vision and cognitive needs.
2.2 added six at A and AA — focus not obscured, dragging movements, target size, consistent help, redundant entry and accessible authentication. It also removed 4.1.1 Parsing, on the basis that browsers now recover from markup errors consistently enough that it no longer described a real barrier.
WCAG 3 exists as a working draft under the old name Silver. It is not a Recommendation, it is not stable, and nothing should be built or audited against it. Knowing that it is a draft is the correct answer; treating it as a standard is not.
WAI-ARIA
A technical specification, not a set of guidelines. It defines roles, states and properties that let custom components expose meaning to assistive technology through the accessibility tree.
Two things to separate, because candidates run them together.
The ARIA specification is normative. It defines what each role means, which states and properties are supported, and what is required. If a role requires a particular child structure, that requirement is normative.
The ARIA Authoring Practices Guide, the APG, is not. It shows patterns for common widgets and the keyboard behaviour people expect of them. It is the best guidance available and it is still advice. A component that behaves differently from the APG is not automatically a failure, though it usually needs a better reason than the developer's preference.
Lessons 4 to 6 cover ARIA properly. What matters here is where it sits in the family.
ATAG and UAAG
Two more W3C documents, and the exam expects you to know which is which.
ATAG, the Authoring Tool Accessibility Guidelines, covers tools that produce content: editors, content management systems, course builders, anything with a publish button. Part A asks whether the tool is usable by a disabled author. Part B asks whether the tool helps any author produce accessible output, by prompting for alternative text, generating sound structure and not shipping inaccessible templates.
UAAG, the User Agent Accessibility Guidelines, covers browsers and media players. Mostly handled by vendors now, but it completes the set: content, the tool that made it, the tool that renders it.
EN 301 549
The European standard, and the one that catches people who only know WCAG.
It is broader in two directions. It covers more than the web: hardware, non-web software, non-web documents, and support services such as documentation and help desks. And it covers functional performance statements, which describe what a user must be able to do rather than which technique was used.
Its structure is worth carrying roughly. Early clauses set generic requirements and functional performance. Clause 9 covers web content and adopts WCAG Level AA by reference. Clause 10 covers non-web documents. Clause 11 covers software. Clause 12 covers documentation and support services. Clause 5 covers generic requirements including closed functionality, which is the case where a user cannot attach their own assistive technology, such as a ticket kiosk.
That closed-functionality material is the part with no WCAG equivalent at all, and it is where EN 301 549 earns its place in your head.
The standard underpins EU public procurement and the European Accessibility Act, and the 2017 refresh of Section 508 in the United States was harmonised with it, which is why American federal procurement now effectively means WCAG Level AA.
Which one applies
A short path that works in practice.
Start with the contract or the law, because it names a version and a level, and that settles the argument regardless of what is newest.
Then look at the artefact. Web content: WCAG. A document: the document standard, PDF/UA for PDF. Software or hardware or a kiosk: EN 301 549. A tool other people author in: ATAG as well.
Where several apply, they stack rather than compete. A European public body buying a web application is subject to EN 301 549, whose clause 9 points at WCAG. You are not choosing between them; you are reading one through the other.
The distinction candidates get wrong
Technique versus success criterion. A technique is never the requirement. If a question describes a defect report citing a technique number as the failure, the report is written wrongly even if the underlying problem is real.
ARIA specification versus APG. Normative versus advisory. A component that departs from an APG pattern needs justification, not a citation.
WCAG versus EN 301 549. If a scenario mentions hardware, a kiosk, support documentation or closed functionality, WCAG alone is the wrong answer.
Newest versus governing. A contract naming WCAG 2.0 AA is met by WCAG 2.0 AA. Delivering 2.2 is a courtesy; demanding it is a change of scope.
Check yourself before the questions
- A developer says a page fails because it does not use technique H42. What is wrong with that statement, and what would the correct finding look like?
- Which parts of WCAG are normative?
- What does EN 301 549 cover that WCAG does not, and name the clause area where the difference is sharpest.
- Is a component that departs from the ARIA Authoring Practices Guide non-conformant?
- A client asks you to audit against WCAG 3. What do you tell them?
Primary sources
- W3C, Web Content Accessibility Guidelines 2.2, specifically the Conformance section, which is normative and short.
- W3C, WAI-ARIA 1.2 specification, and separately the ARIA Authoring Practices Guide. Notice as you read which one tells you what you must do.
- ETSI, EN 301 549, clauses 5, 9, 10, 11 and 12.
- W3C, ATAG 2.0, at least the Part A and Part B summaries.
The rest of the course
This is the first of 19 lessons. The full WAS course is included with an A11ytek Exam Prep WAS subscription, alongside the 9,233 verified WAS practice questions, spaced repetition and mock exams.
- Open the Exam Prep app
- WAS Study Guide, free and complete
- Not sure which certification you need?
This is lesson one of nineteen
The full WAS course runs to 24,939 words, written the same way as the lesson you have just read and mapped section by section to the official Body of Knowledge. It comes with the other eighteen WAS lessons and 9,233 practice questions, at no extra cost over the question bank itself.