WCAG 2.2 AA in practice: what accessibility asks of a business website

Accessibility gets treated as a compliance chore — a checklist somebody produces at the end of a project, mostly ignored, occasionally used to justify an alt text sweep. That framing does it no favours, because it obscures two things that are straightforwardly true.

The first is commercial. Around one in five people in the UK has a disability, and a far larger number benefit from the same design decisions: anyone reading on a phone in bright sunlight, anyone whose eyes are tired at the end of a long day, anyone using a laptop trackpad on a train. Making a site usable for people with impairments makes it easier for everybody, and easier sites produce more enquiries.

The second is legal. The Equality Act 2010 requires service providers to make reasonable adjustments, and that includes digital services. There is no small-business exemption. Enforcement in the UK has historically been light for private companies, but the direction of travel — including the European Accessibility Act, which affects UK businesses trading into the EU — is one way.

This article is about what the standard actually asks for, in practical terms.

What WCAG is, briefly

The Web Content Accessibility Guidelines are the internationally recognised standard, currently at version 2.2. They are organised into four principles: content must be perceivable, operable, understandable and robust.

Each guideline has three conformance levels. A is the minimum and is not sufficient in practice. AA is the level referenced by legislation and procurement almost everywhere, and is what a business website should target. AAA includes requirements that are impractical for general content.

So "WCAG 2.2 AA" is the sensible target. It is achievable on any normal website, and much of it is free if you consider it while designing rather than afterwards.

The things that matter most

In the sites we audit, the same problems recur. Fixing these six accounts for the overwhelming majority of real-world barriers.

1. Text contrast

What is required. Body text must have a contrast ratio of at least 4.5:1 against its background. Large text (24px, or 19px bold and above) needs 3:1. Interface components and meaningful graphics — form borders, icons, focus indicators — also need 3:1.

What goes wrong. Light grey body text on white, because it looked elegant in the design tool. Placeholder text that is barely visible. White text over a photograph where contrast varies across the image. Pale grey borders on form fields, so the fields are invisible to some users.

How to fix it. Check every colour pair with a contrast tool before it ships. If your brand palette fails, adjust the shade used for text rather than abandoning the brand — usually a small darkening is enough. Never rely on your own eyesight, particularly if you have a good monitor in a well-lit room.

2. Keyboard operability

What is required. Everything usable with a mouse must be usable with a keyboard alone, in a logical order, and the currently focused element must be visible.

What goes wrong. Custom dropdowns and modals built from div elements with click handlers, unreachable by tab. outline: none applied in CSS to remove the "ugly" focus ring, leaving keyboard users with no idea where they are. Focus that jumps to the top of the page when a menu opens. Modals that let focus escape to the page behind. Content that only appears on hover, so it never appears for a keyboard user.

How to fix it. Use native elements wherever possible — a button is a button, an a navigates, a select is a select. Native elements come with keyboard behaviour and screen reader semantics for free, and there is no prize for reimplementing them. Then test by putting the mouse down and tabbing through the whole site. It takes ten minutes and it is the single most revealing test you can run.

3. Forms

Forms are where accessibility failures cost money directly, because a form that is hard to use is a form that does not get submitted.

What is required. Every control has a programmatically associated label. Errors are identified in text, not colour alone, and described well enough to fix. Fields that collect personal information use the correct autocomplete value. Errors are announced to assistive technology.

What goes wrong. Placeholders used instead of labels — so the label vanishes the moment you type and never returns, which is a particular problem for anyone with a memory or attention impairment. Errors shown as a red border and nothing else. Messages like "Invalid input" that do not say what is wrong. Error summaries that appear visually but are never announced. Required fields marked only with a red asterisk and no explanation.

How to fix it. Visible labels above every field, always. Mark optional fields "(optional)" rather than marking required ones with a symbol. Describe errors specifically and constructively: "Please enter a valid email address, for example name@company.co.uk". Associate hints and errors with aria-describedby, set aria-invalid on the field, and put a summary at the top of the form with links to each problem field, moving focus to it after a failed submission. That pattern — pioneered by GOV.UK — works for everybody.

WCAG 2.2 added a relevant criterion here: 3.3.8 Accessible Authentication, which means you must not require a cognitive test such as solving a puzzle to log in or, in practice, to submit a form. It is one reason we use scored, invisible bot protection rather than image challenges. Puzzle CAPTCHAs are an accessibility barrier and a conversion tax at the same time.

4. Headings and structure

What is required. Headings describe the content that follows them, are properly nested, and are marked up as headings rather than styled paragraphs. Landmarks (header, nav, main, footer) identify regions.

What goes wrong. Heading levels chosen for their size — an h4 used because it looked right, skipping h3 entirely. Multiple h1 elements, or none. Bold paragraphs standing in for headings, which look like headings but are invisible to a screen reader's outline. Everything wrapped in div elements with no landmarks.

Why it matters more than it seems. Screen reader users routinely navigate by pulling up a list of headings and jumping to the relevant one — much as a sighted reader skims. If the outline is wrong or absent, that entire navigation mode disappears and the only option is to listen to the whole page.

5. Images and alternative text

What is required. Images that convey information have a text alternative describing that information. Decorative images have an empty alt="" so they are skipped.

What goes wrong. Missing alt text. Alt text stuffed with keywords. Filenames used as alt text (IMG_4021.jpg). Decorative images given long descriptions, which forces screen reader users to sit through irrelevant detail. Text baked into an image, so it cannot be read, translated or resized.

How to fix it. Ask what the image is doing. If it conveys information, describe it in a sentence. If it is atmosphere, alt="". If it is a link or a button, describe the destination or action rather than the picture. And avoid text in images entirely — put the text in the page.

6. Motion and animation

What is required. Users must be able to stop or hide anything that moves for more than five seconds, and animation triggered by interaction must be able to be disabled. Nothing may flash more than three times a second.

What goes wrong. Autoplaying carousels and video backgrounds. Parallax that moves the whole page as you scroll. Elaborate scroll-triggered entrances. For people with vestibular disorders these are not merely irritating; they cause genuine nausea and dizziness.

How to fix it. Respect prefers-reduced-motion, which every modern operating system exposes and which is a two-line CSS media query. When it is set, reduce animation to a plain fade or nothing at all. Avoid autoplay, and if a carousel is unavoidable, give it real, keyboard-accessible controls.

What WCAG 2.2 added

Version 2.2 introduced nine criteria. Four are relevant to a typical business website:

2.4.11 Focus Not Obscured. When an element receives focus, it must not be hidden behind other content. This catches a very common bug: a sticky header covering the field you have just tabbed to.

2.5.7 Dragging Movements. Anything achieved by dragging must have a single-pointer alternative — relevant to sliders and custom file uploads.

2.5.8 Target Size (Minimum). Interactive targets must be at least 24 by 24 pixels, or have sufficient spacing. This rules out the cluster of tiny social icons crammed into a footer.

3.3.8 Accessible Authentication. Covered above, and the reason to avoid puzzle challenges.

Testing without buying anything

Automated tools catch perhaps a third of issues. They are worth running, and they are not sufficient. A realistic testing routine for a small site:

1. Run an automated check. axe DevTools or Lighthouse in Chrome, free. Fix everything it reports.
2. Tab through the whole site. Can you reach everything? Can you see where you are? Does anything trap you?
3. Zoom to 200%, and set the browser's minimum font size larger. Does the layout hold, or does text overlap and disappear?
4. Turn the sound on and use a screen reader. VoiceOver on macOS and iOS, Narrator on Windows, TalkBack on Android — all built in and free. You will feel clumsy for ten minutes; do it anyway, particularly on your contact form.
5. Check contrast on every text and background pair, including hover and focus states.
6. Test on a phone, one-handed, outdoors if you can. This exposes target size and contrast problems immediately.

Publish a statement

An accessibility statement is a short page explaining what standard you aim for, what you know is not yet compliant, and how somebody can tell you about a problem. It is a legal requirement for public sector bodies and good practice for everyone else.

It also has a practical benefit: it gives a disabled customer a route to contact you instead of simply leaving. Ours is on our accessibility statement page, and it names the things we are still working on rather than claiming perfection.

Retrofitting versus building it in

Building accessibility in from the start costs very little. Retrofitting is expensive, because the problems are usually structural — a component system built without focus management, a colour palette that fails contrast throughout, a navigation pattern that cannot be operated by keyboard.

What retrofitting is not is an overlay widget. The plugins that promise one-line compliance are widely criticised by disabled users and by accessibility professionals, do not achieve conformance, and in several documented cases have made sites harder to use while creating a false sense of security. There is no product that makes an inaccessible site accessible.

The honest route is to fix the underlying site. On a well-built site that is usually days of work. On a badly built one it may be a reason to consider a rebuild, which is a judgement to make with the numbers in front of you.

How we handle it

We design and build to WCAG 2.2 AA as standard, not as an extra: contrast checked programmatically against our colour tokens, a single visible focus style throughout, semantic HTML with ARIA only where it is genuinely required, forms built on the pattern described above, and reduced-motion support everywhere. Every site is tested with a keyboard and a screen reader before launch. The detail is on our website design page.

If you would like to know where your current site stands, ask us for a look or call 01420 446331. We will tell you what we found, what matters most, and roughly what it would take to put right — including when the answer is "less than you feared".