Web accessibility: the basics every developer should know

An accessible website is one everyone can use: people who are blind and use a screen reader, people who do not use a mouse, people who zoom text to 200%, people with colour blindness, people who feel sick with animations, but also people reading in the sun on a phone held in one hand. Accessibility is not a feature for a few: it improves everyone's experience and, in many contexts, it is also a legal requirement.

The four WCAG principles

The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the international reference. They are organised around four principles, summed up by the acronym POUR:

1. Perceivable: information must be perceivable through at least one sense. Images have alternative text, videos have captions, text has sufficient contrast.
2. Operable: every function must be usable with different input devices, starting with the keyboard, and users must have enough time.
3. Understandable: content and interface must be predictable and clear, with errors explained.
4. Robust: the code must work with different browsers and assistive technologies, now and in the future.

The guidelines define three conformance levels (A, AA, AAA); level AA is the one normally set as the target.

Colour contrast

Text must stand out clearly from the background. For level AA the minimum contrast ratio is 4.5:1 for normal text and 3:1 for large text (roughly from 24 pixels, or from 18.7 pixels in bold). User interface components, such as field borders and icons that convey information, also require a contrast of at least 3:1 against their surroundings.

Browser developer tools show the contrast ratio when you inspect a text element. Fashionable light grey on white is the most common violation.

Also, do not use colour alone to convey information: a field marked as invalid only in red is invisible to someone who cannot distinguish red. Add text, an icon or a thicker border.

Everything must work with the keyboard

Many people browse without a mouse: with a keyboard, a sip-and-puff switch, or voice commands that simulate the keyboard. Try your site using only:

• Tab and Shift+Tab to move between interactive elements;
• Enter to activate links and buttons;
• Space for buttons and checkboxes;
• arrow keys inside menus, option groups and sliders;
• Esc to close dialogs and menus.

Check that the tab order follows the logical order of the page and that no element traps focus with no way out.

Focus must be visible

Removing the focus outline with outline: none for aesthetic reasons makes the site unusable by keyboard: users do not know where they are. If you dislike the default outline, replace it rather than removing it:

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

The :focus-visible pseudo-class shows the indicator when it is needed (keyboard navigation) and usually hides it on mouse click.

The skip link

Keyboard users should be able to avoid tabbing through the whole menu on every page. A link at the start of the document solves this:

<a class="skip" href="#content">Skip to content</a>
...
<main id="content">...</main>

The link can be visually hidden until it receives focus, but it must not be removed.

Alternative text and media

Every informative image needs an alt describing its function in context; decorative images use alt="". Videos with speech need captions; audio-only content needs a transcript. Icons used as buttons without text need an accessible name, for example visually hidden text or an aria-label attribute.

Language, zoom and resizing

• Declare the page language with <html lang="en">: the screen reader then chooses the correct pronunciation. For quotations in another language, use lang on the specific element.
• Do not block zoom on mobile devices: avoid user-scalable=no and maximum-scale=1 in the viewport meta tag.
• Content must remain usable with text enlarged to 200% and in a narrow window without horizontal scrolling. Relative units such as rem and em help a lot.

Motion and animation

Large animations, parallax and moving backgrounds can cause nausea and dizziness in some people. The operating system lets users request reduced motion, and CSS can respect that preference:

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Also avoid content that flashes rapidly, and always offer a way to pause carousels and videos that start on their own.

How to test

No automated tool finds every problem: automated checks catch some of them, the rest needs manual verification. A reasonable routine:

1. an automated scan with an extension or the browser's audit panel;
2. full keyboard navigation;
3. a test with a screen reader (NVDA on Windows and VoiceOver on macOS and iOS are free);
4. 200% zoom and a narrow window;
5. where possible, tests with people who actually use assistive technologies.

In short

• WCAG rests on four principles: perceivable, operable, understandable, robust.
• Meet the contrast ratios and do not convey information through colour alone.
• Every function must be keyboard-operable, with focus always visible.
• Declare the language, do not block zoom and respect the reduced-motion preference.
• Combine automated tools, manual checks and screen readers.