Success Criteria
What Are Success Criteria?
Success criteria are the testable rules inside WCAG. Where the guidelines describe a goal in general terms, a success criterion states something specific enough to check: text has a contrast ratio of at least 4.5 to 1, every function available by mouse is available by keyboard, form inputs have labels. Each one is written so that two people testing the same page should reach the same answer.
How They Are Numbered
Each criterion carries a three-part number such as 1.4.3 or 2.4.7. The first digit is the principle, the second the guideline underneath it, the third the criterion itself. This is why audit reports are full of numbers: 1.4.3 is contrast, 2.1.1 is keyboard, 3.3.2 is labels or instructions. The number is a shared address, so a developer, an auditor and a procurement reviewer are all pointing at the same requirement.
Pass or Fail, Not a Score
A criterion is met or it is not. There is no partial credit and no averaging: a page with ninety-eight passing criteria and two failures does not conform at that level. This surprises teams who expect a percentage, and it is the reason a report can look mostly green while the conclusion is still a fail.
Levels A, AA and AAA
Criteria are sorted into three levels by how essential and how achievable they are. Level A covers the barriers that block access outright, AA adds the requirements most laws and contracts reference, and AAA sets a higher bar that is rarely required across a whole site. Most obligations in practice land on AA, which is why audits are usually scoped to A and AA together.
How It Affects Real Users
The numbering can feel bureaucratic until you see what sits behind it. Criterion 3.3.1 says an error must be identified in text. Behind that is somebody who submits a form, sees the page refresh, and has no idea a field turned red because red is not announced and they cannot see it. The criterion exists so that experience has a name, a number and a fix.
Where Success Criteria Show Up in an Accessibility Review
Every finding in a credible audit is tied to a specific criterion. That mapping is what makes a report actionable and what makes it defensible: a developer knows exactly what to change, and a reviewer can verify the claim against a published standard rather than an opinion. A report that lists problems without criterion numbers is difficult to act on and difficult to trust.