Accessibility Quick Guide

Users must be able to receive information through at least one of their senses. Content that exists only in one format — only visual, or only audio — is invisible to some users.

⚠️ Perceivable is about the user receiving the content, not about the content being technically present. A video that includes audio description is perceivable to blind users; the same video without description is not.

Text Alternatives

Any content that is not text must have a text alternative that serves the same purpose.

A photo of a product on a shopping site needs alt text that describes what the image shows, not just a file name like "img0042.jpg", so a screen reader user gets the same information as a sighted user.

Time-based Media

Audio and video content needs alternatives so users who cannot hear or see the media can access the same information.

A recorded lecture needs captions for deaf users and an audio description track for blind users who cannot see what is happening on screen.

Adaptable

The meaning must survive when the presentation changes.

A table that looks organised on screen can become a jumble of disconnected words when read aloud by a screen reader — because the visual structure was not reflected in the underlying code.

⚠️ "Presentation" is not just visual — it includes any way content is rendered, including audio, braille, and reflow on small screens.

Distinguishable

Content must be easy to separate from the background and from surrounding elements, using tools like colour contrast and the ability to resize text.

Light grey text on a white background may look clean to a designer, but it fails users with low vision or colour vision deficiency who cannot distinguish the text from the page.

⚠️ Colour alone must never be the only way to convey information — for example, using only red and green to show pass and fail states excludes users with red-green colour vision deficiency.

Users must be able to interact with and navigate the interface, no matter what input method they use.

⚠️ Operable covers the full range of how people control technology — keyboard, switch, voice, eye tracking, and more. Designing only for mouse users shuts out a large group of people with motor disabilities.

Keyboard Accessible

All functionality must be available using only a keyboard, because many people with motor disabilities cannot use a mouse.

A user who controls their computer with a single switch steps through page elements using the Tab key. If a dropdown menu only opens on mouse hover, that user cannot access it at all.

Enough Time

Users must be able to complete tasks without being rushed or timed out unexpectedly.

A banking site that logs users out after two minutes of inactivity may work for a quick typist, but a user with a motor disability who types slowly may find their session ends before they finish filling out a form.

Seizures and Physical Reactions

Content must not include flashing or motion that could trigger seizures or cause physical discomfort.

An animated advertisement that flashes rapidly can trigger a photosensitive epileptic seizure in someone with that condition, even if the user did not choose to view the animation.

Navigable

Users must have ways to find content, know where they are, and move through pages efficiently.

A user who navigates by keyboard uses skip links to jump past the main navigation and go straight to the page content, saving dozens of tab presses on every page they visit.

Input Modalities

Functionality must work with a range of input methods beyond keyboard, including touch and pointer devices.

A mobile interface that requires a complex swipe gesture excludes users who can only tap, such as someone using a single finger due to a hand tremor.

⚠️ Input Modalities was added in WCAG 2.1 to address mobile and touch contexts that the original guidelines did not fully cover — it sits alongside Keyboard Accessible rather than replacing it.

Users must be able to understand both the content and how the interface works.

⚠️ Understandable is the most human of the four principles — it requires thinking about cognition, language, and predictability, not just technical implementation.

Readable

Text content must be readable and understandable, including declaring the language of the page so assistive technologies can use the right pronunciation rules.

A screen reader set to English will mispronounce French words unless the HTML declares that a passage is in French, leaving the user hearing garbled audio that does not convey the meaning of the text.

Predictable

Pages and components must behave in ways that users expect, without surprising changes of context.

If selecting an option in a dropdown automatically submits a form and loads a new page, a user who is exploring options by pressing arrow keys may trigger an action they did not intend and cannot easily undo.

Input Assistance

When users make errors in forms, the interface must help them identify and fix those errors.

A checkout form that just turns an invalid field border red gives no information to a screen reader user about what went wrong or how to fix it. A clear error message in text, linked to the relevant field, serves all users.

Content must be built to a standard that current and future user agents, including assistive technologies, can reliably interpret it.

A custom-built interactive widget that works visually but uses no standard HTML roles or ARIA attributes will be completely invisible to a screen reader, because the assistive technology has no way to understand what the widget is or how to interact with it.

⚠️ Robust is future-facing as well as present-facing. Content built on web standards is more likely to work with assistive technologies that do not exist yet, not just with those available today.