Nearly every accessibility law that references WCAG, the ADA in practice through case law and DOJ guidance, Section 508, the AODA, the EAA, uses Level AA as the specific target. That consistency across legal frameworks has produced a widespread and understandable shorthand inside product and engineering teams: "WCAG AA" has become synonymous with "accessible" as a finished state, a box that gets checked once and closed. That shorthand is not quite what the standard itself, or the laws citing it, actually say.
WCAG defines three conformance levels, A, AA, and AAA, each building on the one below it, and Level AAA is explicitly not recommended as a general policy requirement for entire sites, because some AAA criteria are genuinely difficult or context-dependent to satisfy universally. That is a real and reasonable design decision in how the standard is structured. It is also frequently misread as evidence that AA represents a complete, sufficient accessibility target on its own, rather than the specific, deliberately pragmatic floor that both W3C's guidance and the legal frameworks citing it actually intend it to be.
The Standard's Own Framing: W3C's WCAG conformance documentation describes Level AA as the commonly targeted legal and policy baseline, while explicitly noting that meeting WCAG success criteria does not by itself guarantee a website is usable by everyone, particularly people with cognitive or learning disabilities, a group AAA-level and beyond guidance addresses more directly than AA does.
Why AA Was Chosen as the Legal Baseline, Not the Ceiling
Regulators and standards bodies settled on AA as the common legal target for a practical reason: it represents a broad, achievable improvement across the majority of disability categories without the more context-specific or genuinely harder-to-universally-guarantee requirements that AAA introduces. That is a sensible policy compromise for setting a nationwide or industry-wide legal floor. It was never intended, by the standard's own authors, to represent the point at which an organization's accessibility responsibility ends. The gap between "the minimum the law will actually enforce" and "genuinely good, inclusive design" was baked into the standard's structure from the start, not an unintended side effect of how AA happened to get selected.
Where AA-Only Compliance Leaves Real Gaps
Several concrete examples illustrate the difference in practice. AA requires a 4.5:1 contrast ratio for normal text; AAA requires 7:1, a meaningfully higher bar that measurably helps users with low vision read comfortably rather than merely legally. AA does not require a text-only alternative or simplified-language version of complex content; AAA-adjacent guidance addresses reading level and content complexity far more directly, an area that matters enormously for users with cognitive and learning disabilities, a population WCAG's own documentation specifically flags as underserved by AA alone. AA's keyboard and focus requirements ensure operability; they do not, on their own, ensure an efficient or low-effort experience for a keyboard user navigating a long, complex page, which is a usability question AA conformance does not directly measure at all, a gap covered in more depth in our companion piece on a site that meets every success criterion and is still unusable.
The Legal Risk in Treating AA as a Ceiling
There is also a practical legal argument for treating AA as a floor rather than a target: WCAG itself continues to evolve, and criteria added in 2.1 and 2.2, several of which are AA-level requirements like input purpose identification and target size, were not part of WCAG 2.0 AA at all. An organization that certified against WCAG 2.0 AA years ago and never revisited that baseline is, in practice, behind the current legal expectation even while technically able to point to an old, once-accurate conformance statement. Standing still at "AA, as it was defined at whatever point we last checked" is not the same as maintaining a current AA baseline, let alone building meaningfully beyond it.
What "Beyond AA" Actually Looks Like in Practice
Going beyond AA does not require chasing full AAA conformance across an entire site, which even W3C does not generally recommend as a blanket target. It means selectively adopting the AAA and best-practice guidance that addresses the specific gaps AA leaves open for your actual user base: higher contrast where content is genuinely hard to read at the AA minimum, plainer language for complex legal or financial content, more generous timing for time-limited interactions, and real usability testing with people who use assistive technology daily rather than testing limited to automated and criterion-based checks alone. This is a targeted, prioritized extension of the AA baseline, not a wholesale AAA project, and it is where the most genuine reduction in both legal risk and real user frustration tends to come from.
If your organization has treated a past WCAG AA audit as a completed, permanent achievement rather than an ongoing floor, that assumption is worth revisiting, both because the standard itself has moved since then and because AA alone was never meant to be where the work stops. Our WCAG conformance level guide covers the full distinction between A, AA, and AAA in more depth.
Our team can run a current audit against the latest WCAG version and show you specifically where your site sits relative to today's AA baseline, and where targeted improvements beyond it would matter most for your actual users. Reach us at experts@wcag.world, or review WCAG 2.2's own conformance documentation and the W3C's accessibility guidelines overview directly.
A practical review loop
Start with the task a person needs to complete, not with the score produced by a single automated scan. Write down the entry point, the expected focus order, the announcement a screen reader should receive, and the recovery path when something goes wrong. Then repeat that task with a keyboard and at least one assistive technology setup. This turns a vague accessibility concern into an observable acceptance test.
The useful evidence is specific. Capture the URL, the control label, the keystrokes, the browser state, and the expected result. Separate a defect from a design choice, and separate both from a limitation in the test environment. Give the product owner a short reproduction and a clear severity rationale. A developer can fix a named interaction. Nobody can reliably fix a general instruction to make a page more accessible.
Finally, put the check into the delivery process. Add the scenario to a pull request checklist, retest it after JavaScript changes, and keep a small set of representative pages available for regression testing. That routine protects the people who depend on the workflow and gives the team a defensible record of what was tested, when it was tested, and what happened.
For the next review, use these related resources: request the relevant WCAG review.
A short written test plan also makes handoffs safer. Name the user goal, the starting focus, the success announcement, and the exact fallback when the preferred path is unavailable. Review that plan with someone who uses the interface differently from its author, then record the result alongside the release notes. This is a small habit, but it catches regressions that a green automated result cannot describe.