Accessibility Standards: WCAG, Inclusive Design and Digital Accessibility Guide

This page treats it as conformance: WCAG structure, legal requirements, testing, and how to verify compliance. Inclusive design evolution covers practice beyond compliance, for readers who want the inclusive-design mindset rather than the conformance floor.

What this gets you:

a working grasp of WCAG’s structure and levels, the exact contrast ratios and testing method an auditor checks, and the legal deadlines that make conformance a requirement rather than a preference.

Where it applies:

any digital product a business must make accessible, and any product a designer wants to make usable regardless of that requirement.

What to get right first:

test in production, not on the design system component. A pattern library can conform perfectly while the page built from it fails, because real content breaks assumptions a clean component never had to face.

Where it comes from

The World Wide Web Consortium maintains WCAG as the technical definition of what accessible means in practice, organised around four principles known as POUR. Lawmakers in the European Union, the United States, and the United Kingdom did not write their own competing accessibility criteria. Instead, each pointed an existing law at this one standard, which is why a single set of guidelines carries legal weight across most of the markets a product ships into.

WCAG conformance

WCAG groups every success criterion under one of four principles.

Within each principle, criteria sit at one of three conformance levels.

Build to WCAG 2.2 AA, published October 2023. It is the level the ADA, Section 508, and the European Accessibility Act all reference, and the level EN 301 549 V4.1.1 is confirmed as the EU harmonised standard.

Contrast and colour vision deficiency sit here because they are conformance requirements, not colour theory. Colour theory basics cover the wheel, schemes, and harmony instead, and colour systems cover specification and management.

Approximately 8 per cent of men and 0.5 per cent of women have some form of colour vision deficiency. The two most common forms, deuteranomaly and protanomaly, both reduce sensitivity to red and green, which is why a red-green pairing for error and success states fails the largest share of colour-blind users.

Never rely on colour alone to carry meaning. Pair a red error state with an icon or a text label, and differentiate chart lines by pattern as well as by hue. A design that still communicates in greyscale works for colour-blind users.

How to apply it

Conformance is a set of decisions made throughout a project, not a single audit at the end.

Build to WCAG 2.2 AA by default, not as a late fix before launch.

You must reach for semantic HTML first. Use a button element for a control that behaves like a button, and add ARIA roles and states only when native HTML doesn’t already provide the semantics you need.

You must set focus order and DOM order to match the reading order a screen reader will announce, not the order a visual layout happens to produce.

You must label every form input and tie every error message to the field it describes.

You must check contrast whenever you choose a colour in the palette, not after the interface ships. A post-launch fix touches every screen that used the colour. A fix before launch touches one decision.

Verification needs three passes, and no one of them covers what the other two catch.

A worked example

Take captions on a product video. WCAG names this requirement directly, at Success Criterion 1.2.2: synchronised captions for prerecorded audio in video. An automated scan confirms a caption track exists and stops there. It cannot tell you whether the captions are synchronised, complete, or attributed to the right speaker. Only a manual review, someone watching the video with the captions on, confirms that.

I check captions in the state an automated tool cannot see: a video re-encoded after the captions were generated, where the track still exists but has drifted out of sync with the audio. The criterion reads as met and fails for the person watching it.

Where it goes wrong

I have watched a team run an automated scan, clear every flagged issue, and call the product done. An automated tool catches rule violations. It does not catch a screen reader user who cannot tell what a custom dropdown is, because the scan has no way to test meaning.

I have watched a developer add an ARIA role of button to a div, when the fix that worked was to use a button element and delete the ARIA entirely. Native HTML carries keyboard behaviour, focus, and semantics for free. ARIA promises the same three things and delivers none unless you implement each one by hand.

I have watched keyboard focus order follow the visual layout of a page rather than its reading order, because the two matched by coincidence on every screen a developer happened to test and diverged on the first one nobody checked.

I call the last failure template conformance: an interface where the design system component passes every check and the page built from it fails, because the real heading someone typed is longer than the one the design tested, or a value is empty in production and the layout that assumed content collapses. Conformance is a property of what ships, not of what the template promised.

Common questions

Which WCAG version do we build to in 2026? Build to WCAG 2.2 Level AA. EN 301 549 V4.1.1, published 2 September 2026, made it the EU harmonised standard, and the ADA and Section 508 both reference WCAG.

Does the European Accessibility Act apply to us if we are not a public body? Yes, in most cases. Directive (EU) 2019/882 has been enforceable since 28 June 2025 and reaches private services, including e-commerce.

Is anyone enforcing it? Yes. The first lawsuits were filed in France in November 2025, and in June 2026 a French court ordered Carrefour France to make its site and app accessible within six months, with fines for delay.

Does an accessibility statement protect us? Only if it is true on the day somebody looks. Conformance is a property of what is in production, not of what the design system said when the statement was signed.

How do we know our live code still matches the standard? Test per component in production, in the states nobody prompts for: empty, loading, error, expired session, no permission. That is where conformance fails.

Key facts, current as of September 2026