WCAG Compliance: Where Most Organisations Fall Short

The Web Content Accessibility Guidelines, known as WCAG, are the internationally recognised standard for making websites and digital services usable by disabled people. They are published by the World Wide Web Consortium (W3C), with WCAG 2.2 the current version, and they underpin accessibility laws and procurement rules in many countries.

Most organisations aim for WCAG level AA. Far fewer achieve it consistently. The reasons are surprisingly predictable: the same types of failure appear again and again, and they persist because accessibility is treated as a checking exercise at the end rather than a habit built into how digital services are designed, built and published.

A quick refresher on WCAG

WCAG is organised around four principles. Content must be:

• Perceivable: people can see, hear or otherwise take in the information.
• Operable: people can use the interface, including with a keyboard or assistive technology.
• Understandable: content and controls behave in clear, predictable ways.
• Robust: content works with a range of browsers and assistive technologies.

Each guideline has success criteria at three levels: A (the minimum), AA (the usual target in law and policy) and AAA (the highest, not usually required for whole sites).

The most common failures

1. Low colour contrast

Light grey text on a white background, pale placeholder text and coloured buttons with white labels often fall below the contrast WCAG requires. Low contrast affects people with low vision, older users and anyone reading a screen in bright light.

Fix: build contrast checks into your design system, so every colour pairing in use has been tested.

2. Images without meaningful text alternatives

Images that convey information need alternative text that describes their purpose. Decorative images should be marked so screen readers skip them. Missing or unhelpful alt text ("image1.jpg") is one of the most common issues.

Fix: make alt text a required field in your content management system, and train content authors to write it well.

3. Forms without proper labels

Form fields that rely on placeholder text or visual position, rather than a properly associated label, are confusing or unusable with a screen reader. Error messages that appear only in red, or only at the top of the page, cause similar problems.

Fix: use standard, accessible form components everywhere, with visible labels, clear instructions and error messages linked to the fields they describe.

4. Keyboard traps and missing focus

Many people navigate with a keyboard rather than a mouse. Custom menus, pop-ups and widgets that cannot be reached or closed with a keyboard, or that hide the focus indicator, lock these users out.

Fix: test every interactive component with the keyboard alone, and never remove visible focus styles without providing a clear alternative.

5. Links and buttons that make no sense out of context

Screen reader users often navigate by listing links or buttons. Ten links all called "Read more" or "Click here" give them nothing to go on.

Fix: write link text that describes the destination, or provide an accessible name that does.

6. Missing structure

Pages that use visual styling instead of real headings, lists and landmarks are hard to navigate with assistive technology. A missing page language setting causes screen readers to mispronounce content.

Fix: use semantic HTML: one main heading, a logical heading order, proper lists and landmark regions.

7. Inaccessible documents and media

PDFs, slide decks and videos are frequently overlooked. Scanned PDFs, documents without tags, and videos without captions or transcripts exclude many users.

Fix: publish content as accessible web pages where possible; when documents are necessary, create them from accessible templates; caption and transcribe video.

Why automated scans are not enough

Automated accessibility tools are valuable. They catch many contrast, labelling and structure problems quickly, and they can run on every change. But they can only test a portion of WCAG. They cannot judge whether alt text is meaningful, whether a page makes sense with a screen reader, or whether a complex interaction is usable with a keyboard.

A sound approach combines:

• Automated testing in development pipelines and across live sites.
• Manual testing with a keyboard and screen readers for key journeys.
• Testing with disabled people, who will find problems no checklist anticipates.

From retrofitting to inclusive by default

The deeper reason organisations fall short is timing. When accessibility is checked at the end, by a specialist or an annual audit, fixing problems is expensive and often deferred. When it is built in from the start, most problems never arise.

Organisations that make progress tend to:

• Make accessibility someone's job, with senior ownership and a clear policy.
• Build it into the design system, so accessible components are the easy default.
• Include it in definitions of done, so features are not complete until they are accessible.
• Train designers, developers and content authors in the parts of WCAG that matter for their work.
• Require it from suppliers, through procurement criteria and contract terms.
• Publish an accessibility statement that honestly describes the current state and how to report problems.

Why it matters beyond compliance

Legal obligations are growing. In the European Union, for example, the European Accessibility Act has applied to many products and services since June 2025. But compliance is not the only reason. Accessible services work better for everyone: clearer forms reduce errors, captions help people in noisy places, and good structure helps search engines too.

How mature is your accessibility practice?

The Accessibility (WCAG) assessment looks beyond individual failures at the practices that prevent them: strategy and governance, inclusive design, development, testing and assurance, content and communication, and training, culture and procurement. It is a useful way to see whether your organisation is still retrofitting, or building accessibility in by default.

Frequently asked questions

What level of WCAG should we aim for?

Level AA is the usual target in law, regulation and public sector policy. Some AAA criteria are worth meeting where practical, but AAA is not normally expected for entire websites.

Can an accessibility overlay make our site compliant?

Overlays and widgets that claim to fix accessibility automatically do not address the underlying problems in your code and content, and some can make the experience worse for assistive technology users. Fixing the source is the reliable approach.

How often should we test for accessibility?

Run automated checks continuously as part of development, test key journeys manually whenever they change, and carry out a broader review at least once a year.