What Is Web Accessibility?

Accessibility means building pages that work for all users — including those using screen readers, keyboard-only navigation, or other assistive technologies.

When developers hear "accessibility" they often picture one user: someone who is blind and uses a screen reader. That person is real and matters, but they represent a fraction of the people your design decisions affect. Understanding the full scope of web accessibility is the first step toward building pages that genuinely work for everyone.

Who accessibility serves

Accessibility is not a niche concern. The people who benefit span a wide range of situations:

Visual impairments — users with blindness, low vision, or colour blindness may rely on screen readers, high-contrast modes, or browser zoom set to 200% or more. If your layout breaks at 200% zoom, you have an accessibility problem.

Motor impairments — users with conditions like Parkinson's disease, RSI, or missing limbs may navigate with only a keyboard, a switch device, or an eye tracker. If an action requires a mouse, they cannot complete it.

Cognitive differences — users with dyslexia, ADHD, or anxiety benefit from plain language, predictable structure, and reduced motion. Clever UX patterns that require learning a custom interaction model create real friction here.

Temporary limitations — a developer with a broken arm uses keyboard navigation. A parent holding a baby uses a phone one-handed. A warehouse worker in direct sunlight can barely see a screen. Context shapes ability, and context changes constantly.

The practical upshot: accessibility improvements nearly always improve the experience for everyone, not just the people we usually picture.

The standard: WCAG

WCAG — the Web Content Accessibility Guidelines — is the international standard authored by the W3C. It is updated periodically; WCAG 2.1 is the current baseline and WCAG 2.2 added additional criteria in 2023.

There are three conformance levels:

Level A — the bare minimum; failing these criteria blocks some users completely.
Level AA — the practical and legal target. Most accessibility laws (the Americans with Disabilities Act case law in the US, EN 301 549 in the EU, and AODA in Canada) reference WCAG 2.1 AA.
Level AAA — aspirational; not required globally but worth pursuing for specific criteria where feasible.

When someone says "make this accessible," they almost always mean WCAG 2.1 AA.

The four principles: POUR

WCAG organises its criteria around four principles, often remembered by the acronym POUR:

Perceivable — information must be presentable in ways users can perceive. Text alternatives for images (alt text), captions for video, sufficient colour contrast. If a user cannot perceive content at all, nothing else matters.
Operable — the interface must be navigable. Every function must be reachable with a keyboard. Give users enough time to read and act. Avoid content that flashes more than three times per second (a seizure trigger).
Understandable — content and UI must be comprehensible. Use plain language. Make error messages specific. Ensure predictable behaviour — a component should work the same way in every context.
Robust — content must be interpretable by assistive technologies, both current and future. This is the technical principle: write valid HTML, use semantic elements correctly, and follow ARIA authoring patterns so screen readers can build an accurate accessibility tree.

POUR gives you a diagnostic lens. When you encounter an accessibility problem, you can classify it: "This error message is shown only in red — that is a Perceivable failure." "This modal has no keyboard escape — that is Operable." The classification tells you which WCAG success criteria to check.

The legal dimension

In the United States, courts have consistently found that WCAG 2.1 AA sets the standard for ADA compliance on the web. Lawsuits against inaccessible websites have been filed against airlines, banks, retailers, and universities. In the European Union, the European Accessibility Act mandates compliance for most private-sector digital products by 2025. In the UK, the Public Sector Bodies Accessibility Regulations already require it for government services.

Accessibility is not optional for organisations that take legal risk seriously. It is also increasingly a procurement requirement: many large corporations and governments will not purchase software that cannot demonstrate WCAG 2.1 AA compliance.

The semantic HTML shortcut

Here is the most practical insight in this module: the vast majority of accessibility problems are caused by using the wrong HTML element for the job.

A <button> is keyboard-focusable by default, fires on Enter and Space, announces itself to screen readers as a button, and supports the disabled attribute. A <div> with a click handler does none of these things. Fixing that <div> requires adding role="button", tabindex="0", keyboard event handlers, and state management — effectively reimplementing what <button> gives you for free.

Semantic HTML solves most accessibility problems before you write a line of CSS or JavaScript. The accessibility module that follows builds on this foundation — ARIA fills the gaps where no native element exists, not the spaces where the wrong element was chosen.

The first rule of ARIA (published by the W3C itself) is: do not use ARIA if a native HTML element or attribute already provides the semantics and behaviour you need. If you find yourself reaching for ARIA for something basic like a button or a form input, check whether you have the right HTML element first.

Where to go next

Accessibility starts with meaning in the markup. Next: Keyboard Navigation — the concrete mechanics of how focus moves through a page and what you must provide for keyboard-only users.

Finished reading? Mark it complete to track your progress.