Accessibility: WCAG 2.2 and EN 301 549¶

Exercise accessibility-wcag-annex.pdf · PDF

Have you ever tried to read your phone in bright sunlight, or watched a video on the bus with the sound off? For a few seconds the app stopped working for you. For many people that is not a few seconds. It is every day.

The World Health Organization estimates that 1.3 billion people — about 1 in 6 — live with a significant disability. An app that ignores them locks out a crowd bigger than the population of Europe. And in the EU, locking them out can also be against the law.

Your app is a building¶

Accessibility means that people with the widest possible range of abilities can perceive, understand and use your interface.

Think of your app as a building. Anyone who wants to use it has to get in, find their way around and use what is inside. Some visitors arrive in a wheelchair, some cannot see the signs, some cannot hear the announcements. A well-designed building has a ramp next to the stairs, signs big and clear enough to read, and a lift that says each floor out loud.

We will keep this building all the way through the page:

Disabilities are not only permanent. A broken arm is temporary. Holding a baby in one arm is situational. Everyone is in one of these groups at some point.

WCAG 2.2: the building code¶

WCAG (Web Content Accessibility Guidelines) is the international set of rules for making digital content accessible, written by the W3C, the organisation that also writes the standards for HTML and CSS.

Each rule is called a success criterion: a sentence you can test with a clear yes or no. For example, 1.4.3 Contrast (Minimum) says normal text must have a contrast ratio of at least 4.5:1. Either it has, or it does not.

The versions you will hear about:

Some of the new criteria in 2.2, so you can picture them:

The four principles: POUR¶

Every success criterion hangs from one of four principles. Their initials spell POUR:

flowchart LR
    P["<b>Perceivable</b><br>can I notice it?<br>(can I read the sign?)"] --> O["<b>Operable</b><br>can I use it?<br>(can I reach the door?)"]
    O --> U["<b>Understandable</b><br>does it make sense?<br>(do the signs agree?)"]
    U --> R["<b>Robust</b><br>does it work with my tools?<br>(does my wheelchair fit the lift?)"]

Three levels: A, AA, AAA¶

A conformance level says how many of the criteria your interface meets: A (minimum), AA (the usual target) or AAA (the highest).

The levels stack, like inspections: to pass AA you must pass every A criterion and every AA criterion.

EN 301 549: when the code becomes law¶

WCAG is a recommendation. Nobody is forced to follow a recommendation — until a law points at it.

EN 301 549 is the European standard for the accessibility of ICT products and services (websites, apps, documents, software, even ticket machines). In Spain it is published by UNE as UNE-EN 301549.

For web content, EN 301 549 does not invent new rules: its chapter 9 includes all the WCAG criteria of levels A and AA. So in practice, "meet EN 301 549" means "meet WCAG AA", plus some extra requirements for software, documents and support services.

flowchart TB
    W["<b>WCAG</b><br>the building code<br>(W3C)"] -->|"levels A + AA<br>copied into chapter 9"| EN["<b>EN 301 549</b><br>European standard<br>(UNE-EN 301549 in Spain)"]
    EN -->|"the law says:<br>follow this standard"| L1["<b>RD 1112/2018</b><br>public sector websites and apps"]
    EN -->|"the law says:<br>follow this standard"| L2["<b>Ley 11/2023</b><br>private products and services<br>(European Accessibility Act)"]

Which version? The one cited in the EU's Official Journal today is V3.2.1 (2021), which includes WCAG 2.1. In September 2026 ETSI published V4.1.1, which moves to WCAG 2.2 AA; it becomes the legal reference once the EU cites it. Designing to WCAG 2.2 AA now covers both.

Pillar 1: colour contrast¶

Contrast ratio measures how different the brightness of text is from its background, from 1:1 (identical colours, invisible) to 21:1 (black on white).

The sign on the building must be readable from across the street. The WCAG thresholds:

Some real numbers on a white background:

#767676 and #777777 look identical to your eye, yet one passes and one fails. That is why you measure contrast with a tool (Figma plugins, browser DevTools, WebAIM's Contrast Checker) instead of trusting your eyes.

Text inside a logo has no contrast requirement, and neither does pure decoration. Everything the user needs to read does.

Pillar 2: keyboard navigation¶

Keyboard navigation means every action in the interface can be done without a mouse or a touchscreen.

This is the ramp next to the stairs: a second route to every room. It is used by people who cannot use a mouse (motor disabilities, tremors), by blind users (a mouse is useless if you cannot see the pointer) and by power users who are simply faster on the keyboard.

The basic keys:

The rules that matter:

• Everything reachable. If you can click it, you can reach it with Tab (2.1.1 Keyboard, level A).
• No traps. If Tab gets you into something, you can also get out (2.1.2 No Keyboard Trap, level A).
• Visible focus. The element you are on must be highlighted: the focus indicator, usually an outline (2.4.7 Focus Visible, level AA). Removing it with outline: none is like switching off the lights in the corridor.
• Logical order. Tab follows the reading order: top to bottom, left to right, not jumping around the page.

Pillar 3: screen readers¶

A screen reader is software that reads the interface out loud (or sends it to a braille display), so people who cannot see the screen can use it.

This is the guide who walks the building with you and reads every sign out loud. But a guide can only read what is written. If a door has no sign, the guide says "door". Nothing else.

You already have one installed:

For every control, the screen reader announces three things: its name, its role and its state. For example: "Subscribe, checkbox, not checked".

Alternative text (alt text) is the written description of an image that the screen reader reads instead of showing it. Purely decorative images get an empty alt (alt="") so they are skipped.

Key takeaways¶

• Accessibility means everyone can perceive, understand and use your interface — and like a ramp, it ends up helping everyone.
• WCAG 2.2 (W3C, October 2023) organises its rules under POUR: Perceivable, Operable, Understandable, Robust. Levels stack: A → AA → AAA, and AA is the realistic target.
• EN 301 549 (UNE-EN 301549) brings WCAG A + AA into European law: RD 1112/2018 for the public sector, Ley 11/2023 for many private services since 28 June 2025.
• Contrast: 4.5:1 for normal text, 3:1 for large text and UI parts. Measure it; never trust your eyes, and never use colour as the only signal.
• Keyboard: every action reachable with Tab, no traps, a visible focus indicator, a logical order.
• Screen readers announce name, role and state: give images alt text, give icon buttons a name, and use native controls.

Quick check¶

Your rules are clear: readable signs, a ramp, a guide who can read every label. Next, you open Figma and start building the screens that follow them: Figma: frames, auto layout and components.