Accessibility is the quality that lets people with visual, hearing, motor and cognitive disabilities use an interface — and, along the way, everyone who is temporarily or situationally limited. The yardstick is the W3C standard WCAG 2.2: four principles (perceivable, operable, understandable, robust) and success criteria at levels A, AA and AAA; level AA is the target for most sites. Contrast, focus, target size, labels and error messages are decided in the design — fixing them after development costs more.
After this you will be able to
- Explain the four WCAG principles (POUR) and the difference between levels A, AA and AAA
- Name the WCAG 2.2 success criteria that are settled at the design stage rather than in code
- Review a design against a 12-point checklist mapped to WCAG 2.2 success criteria
- Specify focus states, focus order and gesture alternatives for developers
Know beforehand
Verified with
WCAG 2.2 (W3C Recommendation, 2024-12-12)
Checked against docs: October 11, 2026
Contents
- Who needs accessibility: permanent, temporary and situational limitations
- WCAG 2.2: the POUR principles and levels A/AA/AAA
- Contrast, size and more than colour
- Focus, order and keyboard — what the designer decides
- Touch target size and gestures
- Copy: labels, errors, alternative text
- The design checklist before handover to development
Who needs accessibility: permanent, temporary and situational limitations
Accessibility is often seen as looking after a small group of blind users. W3C WAI frames it more broadly: it covers auditory, visual, physical, speech, cognitive and neurological disabilities — and at the same time helps people without disabilities. It helps to think in three kinds of limitation.
Permanent
- Examples
- Low vision, colour vision deficiency, tremor, deafness, dyslexia
- What helps in the interface
- Contrast, text alternatives, larger targets, captions, plain language
Temporary
- Examples
- A broken arm, lost glasses — examples from W3C WAI materials
- What helps in the interface
- One-handed and keyboard operation, text resizing
Situational
- Examples
- Bright sunlight, sound can’t be played, a child in one arm, a slow connection
- What helps in the interface
- Contrast, captions, large buttons, lightweight pages
The same applies to older people, whose vision and motor skills change with age, and to everyone using a site on a phone, a watch or a TV. So accessibility is not a separate “low-vision version” — it is a quality of the main interface.
WCAG 2.2: the POUR principles and levels A/AA/AAA
WCAG (Web Content Accessibility Guidelines) is the W3C standard for web content accessibility. Version 2.2 was published on 5 October 2023 and updated on 12 December 2024; it is also approved as the international standard ISO/IEC 40500:2025. W3C encourages using the latest version: content that conforms to WCAG 2.2 also conforms to 2.1 and 2.0. The requirements are grouped under four principles, known by their initials as POUR.
- 01PerceivableInformation can be perceived: seen, heard or received as text. Contrast, image alternatives, captions.
- 02OperableThe interface can be operated: by keyboard, with one finger, without precise gestures, with visible focus.
- 03UnderstandableBoth content and operation are clear: field labels, meaningful errors, predictable behaviour.
- 04RobustContent is interpreted correctly by different browsers and assistive technologies — mainly a markup job.
A
- What it means
- Baseline criteria: without them some people can’t use the interface at all
- How to use it
- Mandatory minimum
AA
- What it means
- Includes A and adds criteria for contrast, focus, target size and more
- How to use it
- The practical target for most sites and apps
AAA
- What it means
- The highest level: enhanced contrast, larger targets, stricter requirements
- How to use it
- Selectively, where feasible; W3C does not recommend requiring AAA for entire sites
Contrast, size and more than colour
Contrast and colour roles are covered in detail in the article on typography and colour. Here is a summary of the criteria you can check right in the design file, without code.
1.4.3 Contrast (Minimum)
- Level
- AA
- What to check in the design
- Text at least 4.5:1; large text (18 pt or 14 pt bold and up, roughly 24 and 18.5 px) at least 3:1. Placeholders and hover text count too
1.4.11 Non-text Contrast
- Level
- AA
- What to check in the design
- Field borders, icons, toggle states and meaningful chart parts at least 3:1 against adjacent colours
1.4.1 Use of Color
- Level
- A
- What to check in the design
- Errors, status, required fields and links aren’t marked by colour alone — there’s text, an icon or an underline
1.4.4 Resize Text
- Level
- AA
- What to check in the design
- Text can be enlarged to 200% without losing content: labels don’t get clipped, buttons grow with their text
1.4.10 Reflow
- Level
- AA
- What to check in the design
- At 320 CSS pixels wide the content reflows into one column with no horizontal scrolling (except tables, maps and the like)
Focus, order and keyboard — what the designer decides
Many people operate interfaces without a mouse: with a keyboard, a switch, voice or a screen reader. For them it matters where the focus is — the highlight on the element that will receive the action — and in what order it moves. That is set in the design and the component specs.
Draw the focus state
Every button, link, field and toggle has a visible focus state that stands out on any background (2.4.7, AA). The indicator is a non-text element too; aim for 3:1 contrast.
Define the order
Focus order follows reading and task logic: form fields top to bottom, then the submit button (2.4.3, A). On complex screens, number the order right in the design.
Everything works by keyboard
Anything done with a mouse must also be possible by keyboard (2.1.1, A): menus, carousels, date pickers, closing a dialog.
Focus isn’t hidden under the header
A sticky header, cookie banner or chat widget must not fully cover the focused element (2.4.11, AA). Plan for scroll padding or a dismissible banner.
Touch target size and gestures
WCAG calls the area you press a target: a button, link or icon. Small, tightly packed targets are hard to hit for people with tremors and for anyone holding a phone in one hand.
2424
CSS pixels — minimum target size under 2.5.8 (AA); exceptions include enough spacing, links in text and an equivalent control
4444
CSS pixels — the enhanced criterion 2.5.5 (AAA)
Gestures need separate attention. Criterion 2.5.1 (A) forbids making complex gestures — a two-finger pinch or a path-based swipe — the only way to perform an action. Criterion 2.5.7 (AA) requires that anything done by dragging can also be done with simple taps or clicks.
Gesture only
- The carousel only moves with a swipe
- The map only zooms with a pinch
- List order only changes by dragging
- The price slider only moves by dragging
Gesture plus tap
- The carousel has “previous” and “next” buttons
- The map has “+” and “−” buttons
- List items have “move up” and “move down” buttons
- Tapping the track moves the thumb, and there’s a field for an exact value
Copy: labels, errors, alternative text
A large part of accessibility is copy, and it’s written by the designer, editor and product manager, not the developer. If a field has no label in the design and an icon has no name, someone will have to invent them in code on the fly.
1.1.1 Non-text Content
- Level
- A
- What to provide
- Text conveying meaning or action for every meaningful image and icon button; decorative images marked as decorative
3.3.2 Labels or Instructions
- Level
- A
- What to provide
- A visible label on every field, the format where it isn’t obvious, required fields marked — without excess instructions
3.3.1 Error Identification
- Level
- A
- What to provide
- The error points to the specific field and is described in text
3.3.3 Error Suggestion
- Level
- AA
- What to provide
- If the fix is known, the message suggests it: “Enter the number as +7…”
2.4.6 Headings and Labels
- Level
- AA
- What to provide
- Headings and labels describe topic or purpose, not “Section 1”
3.3.7 Redundant Entry
- Level
- A
- What to provide
- Information entered earlier in the same process is auto-filled or available to select
3.3.8 Accessible Authentication (Minimum)
- Level
- AA
- What to provide
- Sign-in without memorising or retyping: paste and password managers allowed, an email link or passkey offered
Doesn’t work
- alt “photo”, “image123.jpg” or an empty alt on a product photo
- A cart icon with no name
- A placeholder instead of a label: it disappears on typing
- “There is an error in the form” above all fields
Works
- alt “Leather backpack, brown, front view”
- A button named “Cart, 2 items”
- A persistent label above the field, an example in the hint
- Error text next to the specific field, plus how to fix it
The design checklist before handover to development
The checklist covers what is visible in the design. It doesn’t replace testing the finished interface: semantics, screen reader and keyboard behaviour are checked in code.
- Text contrast at least 4.5:1, large text 3:1, placeholders included (1.4.3)
- Field borders, icons and component states at least 3:1 against the background (1.4.11)
- No meaning is conveyed by colour alone (1.4.1)
- The design is checked with text at 200% and at 320 px wide (1.4.4, 1.4.10)
- Every interactive element has a clearly visible focus state (2.4.7)
- Focus order is marked on complex screens and follows the task logic (2.4.3)
- Sticky headers, banners and widgets don’t cover the focused element (2.4.11)
- Targets are at least 24×24 px or have enough spacing (2.5.8)
- Swipes, pinches and drags have a tap alternative (2.5.1, 2.5.7)
- Fields have visible labels; errors have text and a suggested fix (3.3.1, 3.3.2, 3.3.3)
- Meaningful images and icon buttons have alternative text written (1.1.1)
- Sign-in doesn’t require memorising or retyping codes, and no data has to be entered twice (3.3.7, 3.3.8)
Accessibility is cheapest at the design stage: every decision postponed to code comes back as rework.