Software Accessibility Standards: What WCAG Actually Requires
Ask a product team what accessibility means and most will mention alt text and colour contrast. Both matter, but they’re a small fraction of what the actual standard covers, and treating accessibility as a checklist of visual tweaks is exactly how software ends up failing people who use screen readers, switch controls or voice input.
Key Takeaways
- WCAG 2.2 is organised around four principles: content must be perceivable, operable, understandable and robust, and a failure in any one of them can make software unusable regardless of how the others score.
- Keyboard navigation, not colour contrast, is where most software fails first, because so many interfaces are built and tested with a mouse and never checked without one.
- Accessibility conformance has three levels, A, AA and AAA, and AA is the level almost every legal and procurement requirement actually asks for.
- Public sector software in the UK has a legal duty to meet WCAG 2.2 AA, and that expectation increasingly shapes what private clients ask suppliers for too.
- Testing with assistive technology users, not just automated scanners, is the only way to catch the failures that checklists consistently miss.
Accessibility standards exist because software that only works for people who can see a screen clearly, use a mouse precisely and process information quickly is software that fails a meaningful share of the population, not an edge case.
The four principles behind the checklist
WCAG 2.2, published as a formal W3C Recommendation in October 2023, organises its requirements around four principles, often abbreviated as POUR: content must be perceivable, operable, understandable and robust. Perceivable covers things like alt text and captions. Operable covers whether every function works without a mouse. Understandable covers whether error messages and instructions make sense. Robust covers whether the software works correctly with assistive technology, not just a standard browser.
The W3C’s Web Accessibility Initiative maintains the standard and is explicit that these four principles aren’t independent checkboxes. A product can nail contrast ratios and captions and still fail badly on the operable principle if none of its interactive elements can be reached by keyboard, which is one of the most common accessibility failures in software that otherwise looks well designed.
A person using a laptop with a screen reader and braille display nearby
Keyboard navigation is where most software actually fails
Colour contrast gets tested because it’s visible and easy to check with a tool. Keyboard navigation gets missed because most development and testing happens with a mouse in hand, so a broken tab order or an unreachable button never surfaces until someone who genuinely needs it tries to use the software and can’t.
Every interactive element, buttons, menus, form fields, custom components, needs to be reachable and usable using only a keyboard, in an order that makes logical sense. This isn’t a minor accommodation. It’s the difference between software that works for someone using a switch device or voice control and software that simply doesn’t, however good it looks in a demo.
An interface that can’t be operated without a mouse fails a meaningful share of its potential users before a single colour is checked.
AA is the level that actually matters
WCAG defines three conformance levels: A is the minimum, AA is the level almost every legal and procurement requirement actually specifies, and AAA is a higher bar that’s rarely required and, for some criteria, not achievable for every type of content. Teams sometimes get distracted chasing AAA on isolated pages while failing basic AA requirements elsewhere in the product, which helps nobody.
The GOV.UK guidance on accessibility requirements, building on regulations that came into force in 2018, is unambiguous that UK public sector websites and apps must meet WCAG 2.2 AA, with very limited exceptions, and that expectation has increasingly become the reference point private sector clients use too, even where there’s no legal duty to comply. A supplier that already builds to AA as standard, rather than treating it as a late-stage retrofit, saves a client a significant amount of rework.
A designer reviewing an interface’s colour contrast and layout on a large monitor
Automated tools catch a fraction of the problem
Automated accessibility scanners are useful and cheap to run, but they typically catch somewhere between a fifth and a third of real accessibility issues, because so many of the meaningful failures are about how a screen reader announces something or how a form behaves under actual use, not something a scanner can infer from the markup alone.
The Royal National Institute of Blind People, whose 2024 research put the number of people living with sight loss in the UK at more than two million, has been clear for years that genuinely inclusive software testing has to include people who actually use assistive technology day to day, because their experience surfaces problems that no automated tool or sighted tester working through a checklist will ever find. A form that validates cleanly against a scanner can still be genuinely unusable with a screen reader if the error messages aren’t announced correctly.
A person navigating a mobile app using voice control
Building accessibility in rather than bolting it on
Retrofitting accessibility into a finished product is consistently more expensive and less thorough than designing for it from the first wireframe. Component-level decisions, how a custom dropdown is built, how focus moves after a modal closes, are far cheaper to get right once than to unpick after launch across every screen that copied the same pattern.
This is one reason accessibility competence is worth checking for directly when choosing who builds a piece of software. Arch, a UK-based dev agency, built its iFell app for Parkinson’s patients with accessibility requirements considered from the outset, an approach that mattered given the app now supports 166,000 UK patients, many of whom rely on assistive technology to log symptoms reliably. Teams commissioning software with real accessibility requirements are usually better served asking how a supplier handles this from day one rather than checking it off at the end, since retrofitting these decisions later is where most of the avoidable cost and frustration end up landing.
Frequently Asked Questions
What is WCAG and who sets the standard?
WCAG stands for Web Content Accessibility Guidelines, maintained by the World Wide Web Consortium’s Web Accessibility Initiative. It’s the internationally recognised standard that most legal and procurement accessibility requirements, including the UK’s public sector duty, are built on.
What’s the difference between WCAG levels A, AA and AAA?
A is the minimum level of conformance, AA is the level almost universally required by law and procurement policy, and AAA is a stricter standard that isn’t achievable for every type of content and is rarely mandated in full.
Is WCAG 2.2 AA a legal requirement in the UK?
Yes, for public sector websites and apps, with limited exceptions. Private sector software isn’t bound by the same regulation directly, but AA has become the practical reference point many private clients now expect from any supplier.
Can automated accessibility testing tools catch everything?
No. Automated scanners catch a meaningful share of issues but typically miss problems that only surface through real use with assistive technology, such as how a screen reader announces dynamic content or handles focus after an action.
Why is keyboard navigation such a common accessibility failure?
Because most development and testing happens with a mouse, so a broken tab order or an unreachable interactive element often goes unnoticed until someone who relies on keyboard or switch navigation tries to use the product and finds they can’t.
