WCAG 2.1 Level AA is the standard that makes websites work for everyone.
It is also the standard that most UK organisations are legally expected to meet, and the one that appears in procurement frameworks. Yet the majority of websites still fall short of it, not because the requirements are unreasonable, but because they are not widely understood.
This guide covers what WCAG 2.1 Level AA actually requires, why it matters beyond compliance, how to test for it, and why building to the standard from the start costs significantly less than retrofitting it later.
What WCAG 2.1 Level AA Is
WCAG stands for Web Content Accessibility Guidelines. It is the international technical standard published by the W3C for making websites and applications accessible to people with disabilities, including those who are blind or have low vision, deaf or hard of hearing, have mobility or cognitive disabilities, or use assistive technology.
WCAG 2.1 Level AA is built on four foundational principles, known by the acronym POUR:
- Perceivable. Information and user interface components must be presentable to users in ways they can perceive. This covers visual alternatives for images, captions for video, sufficient colour contrast, and content that survives magnification.
- Operable. User interface components and navigation must be operable. This means everything must be accessible via keyboard alone, interactive elements must have visible focus indicators, and users must not get trapped in components they cannot escape.
- Understandable. Information and the operation of the interface must be understandable. This covers predictable navigation, clear labelling of form fields, plain language, and error messages that explain what to fix.
- Robust. Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies like screen readers, magnification software and voice control. This requires valid markup and proper semantic structure.
WCAG 2.1 contains 50 success criteria in total across these four principles. Level A comprises 25 criteria addressing basic accessibility. Level AA adds a further 13 criteria and is the industry standard and most widely adopted target. Level AAA adds 28 more but is rarely required outside specialist contexts.
Why Level AA
Level AA is the de facto standard because it balances accessibility requirements with practical design feasibility. The W3C WCAG 2.1 Quick Reference documents all 50 criteria and their implications. Key Level AA requirements that fail audits most often include contrast ratios of at least 4.5:1 for normal text, visible focus indicators on interactive elements, properly associated form labels, descriptive alternative text for images, and the ability to operate the entire site using keyboard navigation alone.
Why WCAG 2.1 Level AA Matters
Legal obligation and reasonable adjustment
In the UK, the Equality Act 2010 requires organisations to make reasonable adjustments to remove barriers for disabled users. WCAG 2.1 Level AA is widely recommended as the target for demonstrating reasonable adjustment in website accessibility, though specific guidance varies by case and context. While specific enforcement cases are rare, the legal risk of non-compliance is material, particularly for organisations providing public services, selling to public sector bodies, or operating in regulated sectors.
Usability beyond disability
WCAG 2.1 Level AA benefits extend well beyond users with registered disabilities. High contrast improves readability on mobile phones in sunlight. Keyboard operation works on touch devices without a mouse. Larger touch targets accommodate people with motor control variation. Plain language and clear labelling help non-native speakers, older users, and anyone under time pressure. Captions for video help people in loud environments. The standard was built on the principle that accessibility features benefit everyone.
Technical coherence
Semantic HTML, required for accessibility, reduces CSS complexity and specificity debt. Keyboard navigation simplifies JavaScript event handling. Alt text for images eliminates the need for decorative image overlays. These are not separate benefits; they are the same code working better.
How to Test for WCAG 2.1 Level AA
Testing happens in layers, because no single method catches everything.
- Automated tools come first. Tools like Axe DevTools, Lighthouse and WAVE are free or low-cost and integrate into development pipelines. They catch structural problems, colour contrast failures and missing labels reliably. However, automated tools catch only an estimated 30-40% of accessibility issues. They cannot tell you whether a real person can complete a task.
- Manual testing comes next. Tab through your most important user journey using only the keyboard. Can you reach everything? Is the focus indicator visible? Does the order make sense? Test colour contrast using a free tool like WebAIM Contrast Checker. Zoom the page to 200 per cent and check that content reflows without horizontal scrolling. Verify that form errors are announced in text, not only shown in colour.
- Assistive technology testing surfaces the problems that automated and manual testing miss. Screen readers like NVDA, JAWS or VoiceOver expose structural issues, missing labels and problems with custom components. It is possible to test with screen readers yourself if you have the time; many organisations conduct this testing or recruit disabled users to do it.
- User testing with disabled participants catches context-specific problems that no other method finds, but it requires specialist recruitment, payment and moderated sessions. It is not universally done during development, though it is recommended practice.
Cost: Building to Standard vs. Retrofitting
Building accessibility into design and development from the start is significantly cheaper than retrofitting it later. When accessibility is considered at the brief stage, it is baked into design systems, developers are trained upfront, and testing happens continuously. Retrofit projects often require simultaneous changes to markup, components, content, test coverage and documentation.
Industry estimates suggest building to standard from the start adds 5-15% to design and QA time. Retrofitting estimates range much wider (reports vary from 50-300% more) and depend heavily on site complexity and existing code quality. These are not independently verified across all project types; cost depends on your specific starting point. The principle is consistent: early adoption is cheaper.
Common Misconceptions
- Misconception: Accessibility = screen readers only. Screen readers are one assistive technology. WCAG 2.1 Level AA covers keyboard navigation for people with mobility impairments, colour contrast for people with low vision or colour blindness, captions for people who are deaf, plain language for people with cognitive disabilities, and large touch targets for people with motor control variation.
- Misconception: Automated testing is sufficient. Automated tools catch only about 30-40% of issues. Manual testing and assistive technology testing are required for comprehensive coverage.
- Misconception: It harms design. Accessibility and good design are compatible. High contrast improves readability for everyone. Larger touch targets work on mobile. Clear headings improve scannability. Some constraints exist (text cannot be hidden from screen readers purely for visual effect), but these drive better information architecture, not worse.
- Misconception: Level A is enough. Level A addresses only basic accessibility. Level AA is the industry standard, the benchmark for legal compliance, and what appears in procurement frameworks.
- Misconception: Only a specialist can do it. Accessibility is not a specialist skill; it is a baseline quality standard. Semantic HTML, keyboard operation and colour contrast are within reach of any developer or designer who has learned what to check and why.
Getting Started
Start with an audit. Automated tools are free and give you a baseline. Manual testing with a keyboard takes an hour and exposes focus indicators, navigation order and keyboard traps immediately. If you have budget, bring in a qualified auditor to do comprehensive testing with assistive technology.
Prioritise fixes that prevent users from completing key tasks. A form that cannot be operated with a keyboard turns away somebody who had already decided to contact you.
Build accessibility into the next phase. If your site was designed without accessibility in mind, your next redesign is the time to shift to WCAG 2.1 Level AA as the standard. It costs less to do from the start than to retrofit.
Sustainable website development includes accessibility from the brief, because accessible code is performant code, and performance reduces digital carbon.
Publish an accessibility statement describing your standard, how you test, and what you know is not yet fixed. Stating known gaps reads as more credible than claiming full compliance.