Key takeaways
  • WCAG rests on four principles: Perceivable, Operable, Understandable, Robust (POUR).
  • Levels are A, AA and AAA; AAA is the goal, and UK/EU law increasingly requires it.
  • Three changes get you most of the way; automated tools catch only part of the problem.

Accessibility is the bit most product teams treat as a checkbox at the end of a project and then complain about when the audit comes back. It is not a checkbox. It is the design constraint that makes the product work for the people who actually need it to work — keyboard-only users, screen-reader users, anyone with low vision, anyone with a motor impairment, anyone using your software at the end of a long day with one hand on a phone. The team that designs for those constraints from the start produces a better product for everyone. The team that bolts it on at the end produces something that technically passes audit and is still frustrating to use.

The Web Content Accessibility Guidelines (WCAG, currently at version 2.2, with 3.0 in draft) are the standard the W3C maintains for what accessibility actually means on the web. It is not an opinion. In the UK it sits behind the Equality Act 2010; in the EU, the European Accessibility Act becomes enforceable in 2025; in the US, ADA case law and Section 508 reference it. If your product is regulated, government-procured, or operates in the EU, WCAG isn't aspirational. It's a legal floor. The good teams treat it that way and aim higher.

The four principles — POUR.

WCAG is built on four principles, captured by the acronym POUR. Every success criterion in the standard rolls up to one of them. Worth memorising.

  • Perceivable. The user can take in the information through at least one of their senses. Text has sufficient contrast against background. Images have alt text. Video has captions. Audio has transcripts. If the user can't perceive it, nothing else matters.
  • Operable. The user can interact with the interface. Every action achievable by mouse is achievable by keyboard. Focus is visible. Time limits can be extended or removed. Nothing flashes in a way that could trigger seizures.
  • Understandable. The user can comprehend what they see and what will happen when they act. Language is plain. Form errors are explained, not just flagged. Navigation patterns are consistent across the site.
  • Robust. The interface works with the technologies the user brings — screen readers, voice control, switch devices, future assistive tech. Semantic HTML. ARIA used correctly. Markup that validates.
Diagram · POUR — the four principles of WCAG
POUR — the four principles of WCAG, arranged as four quadrants around a central WCAG 2.2 badge A two-by-two grid of four quadrants representing the four WCAG principles. Top-left, Perceivable lists contrast 7:1, alt text, captions. Top-right, Operable lists keyboard nav, focus rings, no timeouts. Bottom-left, Understandable lists plain language, predictable patterns, error help. Bottom-right, Robust lists semantic HTML, ARIA, works with AT. A marigold circle in the centre holds the label WCAG 2.2. P Perceivable Contrast 7:1 Alt text Captions can the user take it in? O Operable Keyboard nav Focus rings No timeouts can the user act on it? U Understandable Plain language Predictable patterns Error help does the user follow it? R Robust Semantic HTML ARIA Works with AT does it survive the next tool? WCAG 2.2 Every WCAG success criterion rolls up to one of these four.
POUR is the structural backbone of the entire standard. If you can't remember everything in WCAG (nobody can), remembering POUR gives you the right question to ask of any screen: can the user perceive it, operate it, understand it, and will it survive their assistive tech?

A, AA, AAA: what the levels actually mean.

WCAG defines three conformance levels. Most teams misread which one they should aim for. Level A is the bare minimum. Fail this and people are actively excluded. Level AA is what every public sector site in the UK and EU is legally required to meet, and the level most procurement processes name. Level AAA is the higher bar: contrast ratios of 7:1 rather than 4.5:1, sign language for video, no movement that can't be paused. WCAG itself notes you can't conform AAA across all content; you aim for it.

The opinion most teams need to hear: AA is the legal floor. AAA is what good teams aim for. Treating AA as the goal is treating the minimum acceptable standard as the bar. Treating AAA as the goal, knowing you'll fall short in places, means you build the product better and your accessibility audit is a victory lap rather than a fire-drill.

UK and EU legal context.

If your team operates in the UK or EU, the legal picture matters. The Equality Act 2010 in the UK requires reasonable adjustments for disabled users. The Public Sector Bodies Accessibility Regulations 2018 require WCAG 2.1 AA across government-procured digital services. The European Accessibility Act became enforceable across the EU in June 2025 for products and services including e-commerce, banking, ticketing, e-readers and consumer devices. Non-compliance penalties vary by member state but include fines and trading restrictions.

In the US, ADA Title III case law has settled clearly enough that any consumer-facing product without WCAG conformance is exposed to lawsuit. Section 508 governs federal procurement. The defence in depth for any product reaching multiple jurisdictions is the same defence: hit AA as a floor, aim AAA, document where you fall short and why.

WCAG isn't an opinion. It's a legal floor. AAA is what good teams aim for.

The three changes that get you most of the way.

If you do nothing else, do these three, in this order. They'll close 70-80% of the gap on most products.

  • Fix contrast. Run your colour palette through a contrast checker. Body text at AAA needs 7:1 against background; 4.5:1 minimum for AA. Most brand palettes have at least one combination, usually the marigold-on-cream of someone's favourite secondary, that fails. Adjust it. The number of users who benefit from this single change vastly exceeds the design pain.
  • Make keyboard navigation work, with visible focus. Try to use your product without a mouse. If you can't reach every interactive element with Tab, if the focus indicator is invisible, if Escape doesn't close modals, you have a class of users who can't use it. Fix the focus ring, fix the order, fix the keyboard traps.
  • Use semantic HTML. Button not div onClick. Heading hierarchy that follows the visual hierarchy. Form fields that have labels. Lists that are actual lists. This is where the engineering team gets 80% of the screen-reader gain for 10% of the effort.

The tools — and their limits.

Three you'll use regularly. axe DevTools is the industry-standard browser extension; it catches roughly a third of WCAG issues automatically. Lighthouse in Chrome DevTools is bundled and gives you a quick accessibility score. A screen reader (VoiceOver on macOS or iOS, NVDA on Windows, both free) is the test no automated tool replaces. Half an hour with NVDA on your product surfaces problems no scanner catches.

The trap is treating axe's green score as the bar. It catches contrast, missing alt, ARIA misuse, semantic gaps — the bits a machine can verify. It cannot test whether your form makes sense to a screen-reader user, whether your error messages explain anything, whether your animation makes someone with vestibular sensitivity feel ill. Manual testing with assistive tech is the only way to know.

The bigger frame — inclusive design.

WCAG is necessary, not sufficient. It is the technical floor. Inclusive design is the broader practice of designing for the full range of human variation — temporary disability, situational impairment, cognitive load, language, age, device, network. Microsoft's Inclusive Design Toolkit frames it well: the parent holding a baby has one hand free. The commuter in bright sunlight needs contrast. The user on a 3G connection needs the page to render before all the JavaScript loads. Designing for the extremes makes the product better for the middle.

WCAG conformance is the minimum. Inclusive design is the ambition. Don't confuse them, and don't stop at the minimum.

Where this lands at Product Pieces.

When we run the Foundations Set Piece, accessibility runs through every output. The user stories carry accessibility AC. The Definition of Done has an accessibility line. The design system components ship with focus states, contrast tokens, and keyboard interaction documented from the start, not retrofitted at audit. If your team has the symptom (accessibility found by audit, not by design), the missing piece is the discipline at every stage, not a heroic clean-up sprint at the end.

Read the standard directly when you can — the W3C WAI page is the source of truth and is genuinely well-written. Don't take it second-hand from blog posts; the actual success criteria are clearer than most summaries of them.

Next issue: N°15 — MVP. The most misused three letters in product.