Web Accessibility Basics for Developers (WCAG 2.2)

Web accessibility means building sites and apps that people with disabilities can perceive, operate and understand, including those using screen readers, keyboards, voice control or magnification. The standard to aim for is the Web Content Accessibility Guidelines (WCAG) 2.2, published by the W3C, at level AA. For developers, most of the work comes down to using correct semantic HTML, ensuring everything works from the keyboard, providing text alternatives, maintaining sufficient colour contrast, and labelling forms clearly.

This article is a practical starter for developers and the people who commission them. It is general guidance rather than legal advice. In the EU, the European Accessibility Act brings accessibility requirements to a range of products and services, and public sector bodies have their own rules, so ask a qualified adviser which obligations apply to your organisation.

The four principles

WCAG is organised under the acronym POUR. Every requirement fits one of these:

• Perceivable: information must be presentable in ways users can perceive, for example text alternatives for images and captions for video.
• Operable: interface components must be usable with a keyboard and other input methods, with enough time and no seizure-inducing content.
• Understandable: content and behaviour should be readable and predictable, with help for correcting input errors.
• Robust: content must work with current and future assistive technologies, which in practice means valid, semantic markup.

Levels A, AA and AAA indicate increasing strictness. Level AA is the common target for legal and procurement purposes.

What is new in WCAG 2.2

WCAG 2.2 became a W3C Recommendation in 2023 and builds on 2.1. It adds new success criteria, several of which affect everyday front-end work:

Criterion	Level	What it asks for
2.4.11 Focus Not Obscured (Minimum)	AA	A focused element must not be entirely hidden by other content, such as a sticky header or cookie banner
2.5.7 Dragging Movements	AA	Anything done by dragging must also be possible with a single pointer action, such as clicking buttons
2.5.8 Target Size (Minimum)	AA	Pointer targets should be at least 24 by 24 CSS pixels, with exceptions such as adequate spacing
3.2.6 Consistent Help	A	Help options such as contact links appear in the same place across pages
3.3.7 Redundant Entry	A	Do not make users re-enter information they already provided in the same process
3.3.8 Accessible Authentication (Minimum)	AA	Login must not depend on a cognitive test, such as remembering or transcribing, unless an alternative exists; allow paste and password managers

WCAG 2.2 also removed the old criterion 4.1.1 Parsing, because modern browsers handle malformed markup consistently. Focus Appearance and a few other additions sit at AAA. Always check the criteria text on the W3C site before claiming conformance.

Start with semantic HTML

The single most effective habit is to use the right element for the job. Native elements arrive with keyboard support, roles and states built in.

<!-- Poor: a div pretending to be a button -->
<div class="btn" onclick="save()">Save</div>

<!-- Better: a real button, focusable and activated with Enter and Space -->
<button type="button" class="btn">Save</button>

• Use button for actions and a for navigation.
• Use landmark elements: header, nav, main, footer, so screen reader users can jump around.
• Use one h1 and a logical heading order; do not choose heading levels for their size.
• Use real lists and tables for list and table content, with th headers.

The first rule of ARIA is not to use it when a native element will do. ARIA attributes change how assistive technology describes an element, but they add no behaviour. A div role="button" still needs focus handling and key events that you must write yourself.

Keyboard access

Unplug your mouse and try your product. Can you reach and operate everything with Tab, Shift+Tab, Enter, Space and the arrow keys?

• Keep a logical focus order that follows the visual order.
• Never remove the focus outline without replacing it with a clearly visible style.
• Do not create keyboard traps. In a modal dialog, move focus into it, keep it inside while open, and return it to the trigger on close. The native dialog element handles much of this.
• Provide a "skip to main content" link as the first focusable element.

:focus-visible {
  outline: 3px solid #1a56db;
  outline-offset: 2px;
}

Text alternatives and media

• Informative images need alt text describing their purpose. Decorative images should have an empty alt="" so screen readers skip them.
• Icon-only buttons need an accessible name, for example aria-label="Close" or visually hidden text.
• Provide captions for prerecorded video with speech, and transcripts where useful.
• Do not put important text inside images.

Colour, contrast and text

• Normal text needs a contrast ratio of at least 4.5 to 1 against its background at level AA; large text needs 3 to 1. Interface components and meaningful graphics also need 3 to 1.
• Do not rely on colour alone to convey meaning. Pair a red error border with an icon and text.
• Let users zoom and resize text. Avoid fixed pixel containers that clip content at larger sizes, and support reflow at narrow widths.
• Respect the prefers-reduced-motion setting for animations.

Forms

Forms are where inaccessible sites lose the most users.

<label for="email">Email address</label>
<input id="email" name="email" type="email"
       autocomplete="email" required
       aria-describedby="email-help">
<p id="email-help">We will only use this to send your receipt.</p>

• Every input needs a visible, programmatically associated label. A placeholder is not a label.
• Use correct input types and autocomplete values so browsers and password managers can help.
• Show errors in text next to the field, describe how to fix them, and move focus to a summary or the first error on submit.
• Do not block pasting into password fields; it is also relevant to secure login design.

Dynamic content in modern front ends

Single-page apps need extra care. When a route changes without a page load, update the document title and move focus to the new content or heading so screen reader users know something happened. Announce important status updates, like "Item added to basket", using a live region such as role="status". Check that custom components, such as menus, tabs and comboboxes, follow the patterns in the WAI-ARIA Authoring Practices. Framework choice matters less than discipline, though the rendering approach affects what assistive technology sees on first load; see Next.js vs React SPA.

How to test

1. Automated tools such as axe, Lighthouse or WAVE catch a portion of issues, such as missing labels and low contrast. They cannot judge whether alt text is meaningful or whether the experience makes sense.
2. Keyboard test of every key journey.
3. Screen reader test with at least one, for example NVDA on Windows or VoiceOver on macOS and iOS.
4. Zoom and reflow test at high magnification and narrow widths.
5. Testing with disabled users where you can; nothing replaces it.

Add automated checks to your build pipeline so regressions are caught early.

Common mistakes

• Adding an "accessibility overlay" and calling it done. Overlays do not fix underlying code and are widely criticised by accessibility practitioners.
• Using div and span for everything. You then have to reinvent behaviour that native elements provide.
• Misusing ARIA, which can make things worse than no ARIA.
• Removing focus outlines for aesthetics.
• Relying on automated scores alone.
• Tiny tap targets and hover-only interactions, which also hurt mobile users.
• Treating accessibility as a final audit instead of a design and development habit.

Building accessibly from the start

Accessibility costs far less when it is part of design and component choices from the beginning than when it is retrofitted. Our team builds interfaces with semantic markup and keyboard support as standard practice within web application development, and works with designers on contrast and layout. If you need an existing application reviewed against WCAG 2.2, get in touch to discuss scope.