Accessibility (a11y) — a working reference

Accessibility — often abbreviated a11y (an “a”, eleven letters, then a “y”) — is the practice of building products that people with disabilities can perceive, understand, navigate and use on equal terms with everyone else. It is part craft, part law, and almost entirely a matter of not accidentally locking people out of things you built for them.

This page is a single-sitting reference: what a11y is and who it serves, the WCAG standard explained from the top (its versions, the four principles, and the A / AA / AAA conformance levels), the practical techniques that matter most, what each major market requires legally, what changes on mobile, and how to test. It leans on examples throughout — the fastest way to understand and to share this stuff is a good story.

Why it matters

There are three honest answers, and you don’t have to choose between them.

It’s a lot of people. The WHO estimates that around 1.3 billion people — roughly one in six of us — live with a significant disability. That number is not a niche; it is larger than China. And it is not static: everyone who lives long enough acquires impairments — vision, hearing, dexterity, memory — so designing for disability is, in the long run, designing for your future self.

It’s the right thing. A digital service that can’t be used by a blind person is, in 2026, the equivalent of a shop with a step at the door and no ramp. Most of us would rather not build the step.

It’s good business and increasingly the law. Accessible products reach more customers, rank better in search (much of accessibility is just clean, semantic, well-labelled markup), and keep you on the right side of a fast-tightening body of regulation. The same work pays off three ways.

Who it's for

“Disability” covers a wide range, and good design has to hold all of it in mind at once. A useful way to think about it (from Microsoft’s Inclusive Design work) is that every impairment comes in three flavours: permanent, temporary and situational. One arm might be amputated, in a cast, or simply holding a baby — and a one-handed interface helps all three.

• Visual — blindness, low vision, colour blindness (about 1 in 12 men, 1 in 200 women). Situational: bright sun on a phone screen, a dirty projector.
• Auditory — Deaf and hard-of-hearing. Situational: a loud bar, a quiet library, a broken speaker.
• Motor / dexterity — tremor, paralysis, RSI, missing limbs; people who use a keyboard only, a switch, or voice control. Situational: one hand on the wheel, a phone in a cold glove.
• Cognitive & learning — dyslexia, ADHD, autism, memory and processing differences. Situational: stress, a second language, a screaming toddler, 3 a.m.
• Speech — people who can’t reliably use voice interfaces.
• Vestibular / neurological — motion sensitivity, seizure triggers, migraine.

The curb-cut effect

The curb cut — the little ramp where a pavement meets the road — was fought for by wheelchair users in 1970s Berkeley. Once installed, it turned out to help everyone: parents with prams, travellers with wheeled luggage, delivery workers with trolleys, cyclists, kids on scooters. Accessibility researchers call this the curb-cut effect: a feature built for a disabled minority routinely becomes a convenience for the whole population.

The digital world is full of curb cuts that you already rely on:

• SMS and the typewriter. Text messaging was embraced early and heavily by the Deaf community; the typewriter itself is often traced to a machine built around 1808 by Pellegrino Turri so a blind countess could write legible letters.
• The telephone. Alexander Graham Bell’s work grew directly out of teaching the Deaf (his mother and wife were both deaf).
• Audiobooks began as “talking books” for blind and visually-impaired veterans in the 1930s.
• OXO Good Grips peelers were designed for a cook with arthritis; the fat, soft handle made them a best-seller for everyone.
• Voice assistants and dictation — born as access tools — are now how millions set timers with floury hands.

The lesson for a builder: accessibility isn’t a tax on the “normal” product. Done well, it is the better product.

WCAG, the standard

When people ask “is this accessible?” the answer almost always routes through one document: the Web Content Accessibility Guidelines (WCAG, pronounced “wuh-cag”), published by the W3C’s Web Accessibility Initiative (WAI). WCAG is the de-facto global standard; nearly every accessibility law in the world either references it directly or copies its requirements.

WCAG is structured as a tree, and it pays to know the four words:

• Principles — the four big ideas (POUR).
• Guidelines — 13 broad goals under the principles (e.g. “Make it easier to see and hear content”). Not testable themselves.
• Success criteria (SC) — the testable rules, each tagged level A, AA or AAA. This is what you actually conform to. They’re numbered principle.guideline.criterion — so “1.4.3” is Perceivable → Distinguishable → Contrast (Minimum).
• Techniques — non-binding, advisory ways to satisfy a criterion (“use the alt attribute…”). You can meet a criterion any way you like; techniques are just known-good recipes.

Crucially, WCAG is technology-agnostic and outcome-based. It almost never says “use this HTML element”; it says “the information must be available to assistive technology.” That’s why the same standard governs websites, native mobile apps, PDFs and kiosks.

WCAG versions

WCAG has evolved, and which version you must meet depends on your jurisdiction. The versions are additive: 2.2 contains everything in 2.1, which contains everything in 2.0. Targeting the newest version you can is the safe move.

Rule of thumb: build to WCAG 2.2 AA. It satisfies almost every current law (most of which still say 2.1 AA or 2.0 AA) and future-proofs you for the rest.

The POUR principles

Everything in WCAG hangs off four principles. If content fails any one of them, some group of people simply can’t use it. The mnemonic is POUR:

• Perceivable — users can perceive the information with at least one sense. Text alternatives for images, captions for audio, enough colour contrast, content that doesn’t rely on colour alone. Can they sense it at all?
• Operable — users can operate the interface. Works with a keyboard, gives enough time, doesn’t flash dangerously, has clear navigation and focus. Can they drive it?
• Understandable — the content and operation make sense. Readable text, predictable behaviour, helpful error messages. Can they comprehend it?
• Robust — it works across browsers, devices and assistive technologies, now and in future. Valid markup, correct names/roles/values. Will their tools understand it?

Conformance: A, AA, AAA

Every success criterion carries a level, and the levels are cumulative: to claim AA you must meet all of A and AA.

• A — essential. The floor. Failing these creates serious barriers (an image button with no label, a video with no captions at all, content that traps the keyboard). Nobody should ship below A.
• AA — the real-world target. This is what virtually every law and contract means by “accessible.” It adds the criteria that make a site genuinely usable: 4.5:1 text contrast, resize to 200%, consistent navigation, visible focus, meaningful headings. Aim here.
• AAA — gold standard, selectively. The strictest tier (7:1 contrast, sign-language interpretation, no time limits, reading level). The W3C itself says you can’t guarantee AAA across all content, so it’s rarely a blanket requirement — but specific AAA criteria are great to adopt where you can.

Key success criteria

WCAG 2.2 has 86 success criteria; you don’t need them memorised, but a working developer should recognise the heavy hitters. These are the ones that catch the most users and show up most in audits and lawsuits.

The rest of this page walks through the techniques behind these, grouped the way you actually build.

Semantic HTML first

The single highest-leverage accessibility habit costs nothing and is faster to write: use the right HTML element. Native elements come with keyboard behaviour, focus management, roles and states already wired up, for free, in every browser and screen reader. The moment you rebuild a button out of a <div>, you sign up to re-implement all of that by hand — and you will forget some of it.

<div class="btn"
  onclick="buy()">Buy</div>

<button type="button"
  onclick="buy()">Buy</button>

The same goes for <a> for navigation, <nav>, <main>, <header> and <footer> landmarks (screen-reader users jump between them), one <h1> per page with a logical heading outline (they navigate by heading, like a table of contents), real <ul>/<ol> lists, and <label> tied to every input. Markup is the accessibility layer.

A handy diagnostic is the “skip link.” The first focusable thing on many good sites is a hidden “Skip to main content” link that appears when you Tab to it — it lets keyboard and screen-reader users jump past the navigation they’ve heard fifty times. Small touch, big relief.

Alternative text

alt text is the text a screen reader speaks (and search engines read, and that shows when an image fails to load) in place of an image. Getting it right is a craft: describe the function or meaning in context, not every pixel.

<img src="ceo.jpg" alt="image">
<img src="ceo.jpg" alt="ceo.jpg">
<img src="ceo.jpg"
  alt="Photo of a photo of...">

<img src="ceo.jpg"
  alt="Asha Rao, CEO,
       speaking at the 2026 keynote">

The rules that cover almost every case:

• Decorative? Give it an empty alt: alt="". That tells the screen reader to skip it. A missing alt attribute is not the same — then the reader may announce the filename.
• Informative? Describe the information (“Bar chart: revenue doubled 2024–2026”).
• A link or button? Describe the destination/action, not the picture (“Home”, not “blue logo”).
• Text in the image? Put that text in the alt. (Better still, don’t put text in images.)
• Don’t start with “Image of…” — the screen reader already says “image.”

Colour & contrast

Two separate rules, often confused:

1. Don’t rely on colour alone (SC 1.4.1). Roughly 1 in 12 men can’t reliably tell red from green. So a form field that goes red on error, a “required” label that’s just a red asterisk, or a chart with red and green lines and no other cue, all fail people who can’t see the difference.

<span style="color:red">●</span> Failed
<span style="color:green">●</span> Passed

✗ Failed  (red)
✓ Passed  (green)

2. Make contrast sufficient (SC 1.4.3 / 1.4.11). Text needs 4.5:1 against its background (3:1 if large); non-text essentials — an input’s border, an icon that carries meaning, the focus ring — need 3:1. A contrast checker takes the guesswork out; you give it two colours and it tells you the ratio and which levels it passes.

Keyboard & focus

A large group never touches a mouse: blind users (a screen reader is driven by the keyboard), people with motor impairments using switches or alternative keyboards, and plenty of power users. If it works with a keyboard, it works for them. The test is simple and you can do it right now: put the mouse away and Tab through your page.

• Reachable — you can Tab to every interactive thing, in a logical order (SC 2.4.3).
• Operable — Enter/Space activate buttons, arrow keys move within menus/sliders, Escape closes dialogs (SC 2.1.1).
• Visible — you can always see where focus is (SC 2.4.7). Never outline: none without a replacement.
• No traps — you can Tab back out of anything you Tabbed into (SC 2.1.2). The classic offender is a modal that swallows focus forever.

:focus { outline: none; }

:focus-visible {
  outline: 2px solid #5b4636;
  outline-offset: 2px;
}

For modals and menus you do have to manage focus deliberately: move focus into the dialog when it opens, keep Tab cycling within it while it’s open (a focus trap, the good kind), and return focus to the element that opened it on close. This is exactly the plumbing native <dialog> now gives you for free — another argument for semantics first.

Forms & errors

Forms are where accessibility most often makes or breaks a transaction — sign-up, checkout, booking. The essentials:

• Every field has a real <label>, tied by for/id (SC 3.3.2). Placeholder text is not a label — it vanishes when you type, fails contrast, and isn’t reliably announced.
• Group related controls with <fieldset>/<legend> (e.g. a set of radio buttons).
• Describe errors in text, next to the field, and say how to fix them (SC 3.3.1 / 3.3.3). “Enter a date as DD/MM/YYYY,” not a lone red outline.
• Announce errors programmatically — link the message to the field with aria-describedby, and surface a summary in a live region so a screen-reader user knows the submit failed.
• Use the right type and autocomplete — type="email", inputmode="numeric", autocomplete="email" — so mobile keyboards adapt and autofill works (a real help for cognitive and motor needs).

<input type="text"
  placeholder="Email">

<label for="email">Email</label>
<input id="email" type="email"
  autocomplete="email"
  aria-describedby="email-hint">
<p id="email-hint">We’ll only use this
  to send your receipt.</p>

ARIA, used sparingly

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes — role, aria-label, aria-expanded, aria-live and friends — that describe the role, name and state of an element to assistive technology. It is powerful and necessary for genuinely custom widgets (tabs, comboboxes, tree-views, live-updating regions). It is also the most misused tool in the kit.

The first rule of ARIA: don’t use ARIA. If a native HTML element or attribute does what you need, use it instead — you’ll get the behaviour for free and you can’t get it wrong.

The reason for the warning: ARIA changes only what assistive tech announces — it adds no behaviour. Put role="button" on a <div> and a screen reader will say “button,” but it still won’t be focusable or respond to Enter unless you add all of that yourself. So a bad ARIA attribute is worse than none: it actively lies to the user. Used well, ARIA shines for things HTML can’t express:

• aria-label / aria-labelledby to name an icon-only button (“Close”).
• aria-expanded="true|false" on a disclosure/accordion toggle.
• aria-live="polite" on a region so updates (a “Saved” toast, a search-results count) are announced without moving focus.
• aria-current="page" for the active nav item.
• role="alert" for an error that must be spoken immediately.

For full custom widgets, follow the ARIA Authoring Practices Guide (APG) patterns rather than improvising — they spell out the exact roles, states and keyboard interactions expected.

Media: captions & more

Audio and video carry obligations that scale with how much information lives in them:

• Captions (SC 1.2.2, Level A) — synchronised text of speech and meaningful sound (“[door slams]”) for Deaf and hard-of-hearing viewers. Distinct from subtitles, which assume you can hear and just translate language.
• Transcripts — a full text version. Required for audio-only content (podcasts), and a kindness everywhere: searchable, skimmable, translatable, great for SEO.
• Audio description (SC 1.2.3/1.2.5) — a narration track describing important visual action for blind viewers in the gaps between dialogue (“She slips the letter into her coat”).
• No autoplay with sound, and always provide pause/stop controls (SC 1.4.2). Auto-playing audio is a nightmare for screen-reader users — it talks over their screen reader.

Motion & seizures

Two distinct risks live here, and one of them is a genuine safety issue.

Seizures (SC 2.3.1). Content must not flash more than three times in any one second. Rapid, high-contrast flashing — especially red — can trigger seizures in people with photosensitive epilepsy. This is not theoretical: a 1997 Pokémon episode with a few seconds of flashing red-and-blue sent hundreds of Japanese children to hospital. Avoid flashing; if you must, keep it slow, small and low-contrast.

Vestibular disorders. Large parallax effects, zooming transitions, and big sliding animations can cause real nausea, dizziness and migraine for people with vestibular sensitivity. The fix is built into the platform: honour the user’s prefers-reduced-motion setting (SC 2.3.3 is the AAA criterion, but respecting it is simply good manners at any level):

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

Let big motion be opt-in, keep essential motion subtle, and never tie meaning to an animation a user has asked you to switch off.

Mobile apps

WCAG applies to native mobile apps too — you map its outcomes onto platform APIs instead of HTML — and the EU’s EN 301 549 explicitly covers mobile software. The principles are identical; the mechanics differ.

What changes on mobile:

• Screen readers are built in. VoiceOver on iOS and TalkBack on Android are driven by swipe gestures. Test with the real thing — it’s a Settings toggle away.
• Label everything through the platform’s accessibility API. On iOS that’s accessibilityLabel / accessibilityTraits (and SwiftUI’s .accessibilityLabel()); on Android it’s contentDescription and proper roles. An unlabelled icon button reads as “button” — useless.
• Touch targets. WCAG 2.2 asks for ≥ 24 px (SC 2.5.8); the platform guidelines go further and are the standard to hit — Apple recommends 44×44 pt, Android Material 48×48 dp.
• Respect system text size. Support iOS Dynamic Type and Android font scaling — don’t hard-code point sizes or clip text that grows. Many users run their phone at large text all day.
• Don’t lock orientation (SC 1.3.4) unless essential — someone with a mounted wheelchair device may only be able to use one orientation.
• Gestures need alternatives (SC 2.5.1) — anything done with a complex or multi-finger gesture (pinch, swipe-path) needs a simple single-pointer way too (a button). And actions should complete on release, not touch-down, so a mistaken touch can be slid off and cancelled (SC 2.5.2).
• Don’t require motion (SC 2.5.4) — if “shake to undo” exists, give a button too.

Both platforms publish accessibility guidance worth bookmarking: Apple’s Human Interface Guidelines → Accessibility and Google’s Material / Android accessibility docs. They also ship excellent testing tools (Xcode’s Accessibility Inspector; Android’s Accessibility Scanner).

Assistive technologies

Knowing the tools your users actually use makes abstract criteria concrete.

• Screen readers — speak the interface aloud (or send it to a refreshable Braille display). JAWS and NVDA on Windows, VoiceOver on Apple, TalkBack on Android, Orca on Linux. They rely entirely on your semantics, labels and ARIA.
• Screen magnifiers — enlarge part of the screen; they’re why reflow and resize-without-breaking matter, and why focus must be visible (the magnified viewport follows focus).
• Voice control — Dragon, Apple/Android Voice Control; users say “click Buy.” This is why the visible label must match the accessible name (SC 2.5.3).
• Switch access — one or two physical buttons (or a sip- and-puff, or a head switch) scanning through controls for people with limited movement. If your keyboard order is sane, switch access tends to follow.
• Alternative input — eye-tracking, head pointers, adaptive keyboards.
• Browser & OS settings — high-contrast / forced colours, dark mode, larger text, reduced motion, reader mode. Don’t fight them; inherit them.

The law, market by market

Accessibility is increasingly a legal requirement, not a nicety — and the obligations are tightening fast. Almost every regime below points back at WCAG, which is why building to WCAG 2.1/2.2 AA covers most of the planet at once. The table is an orientation map, not legal advice (see the note below it); confirm the current rule for your sector and country.

Not legal advice. Laws, versions and deadlines change and vary by sector and sub-jurisdiction. Treat this as a starting map and verify the current requirement with a qualified source before relying on it.

Requirements checker

Pick what you’re building and where it ships, and this tool sketches the standard to target, the laws likely to apply and a starter checklist — then the built-in AI can tailor it to your specific project. It’s here to give you an idea of scope, not a ruling: general guidance, not legal advice.

How to test

No single tool finds everything. Automated scanners reliably catch only a minority of issues (industry estimates hover around 30–40%); the rest need a human. Use all three layers:

• Automated — fast, cheap, run in CI. axe DevTools, WAVE, Lighthouse (built into Chrome), Pa11y. Great at contrast, missing labels, bad ARIA, broken heading order. They will never tell you the alt text is wrong, only that it exists.
• Manual — the high-value layer:
  • Unplug the mouse and Tab through everything.
  • Run a real screen reader (NVDA is free on Windows; VoiceOver ships on Mac/iOS; TalkBack on Android).
  • Zoom to 200% and 400%; check reflow and that nothing’s clipped.
  • Turn on reduced-motion and forced-colours / high-contrast mode.
  • Read your alt text and link text aloud, out of context.
• With disabled users — the only way to know if it’s genuinely usable, not just technically conformant. Nothing substitutes for watching a daily screen-reader user try your checkout.

Myths & mistakes

• “It’s a tiny minority.” One in six people, plus everyone ageing, plus everyone in a situational bind. It’s the largest minority there is, and one you’ll eventually join.
• “An overlay widget fixes it.” Those bolt-on “accessibility” toolbars are widely criticised by disabled users and have themselves drawn lawsuits. There is no magic script; access is built into the product.
• “Accessible means ugly.” Accessibility is about structure, contrast and behaviour — orthogonal to aesthetics. Some of the most beautiful sites on the web are also the most accessible.
• “We’ll add it at the end.” Retrofitting is slow and partial; baked in from the start it’s nearly free. Accessibility is a practice, not a phase.
• “Automated scan says 100%, so we’re done.” Scanners miss most issues. A clean axe report is the start line, not the finish.
• “ARIA makes things accessible.” ARIA changes only what’s announced; bad ARIA is worse than none. Semantics first.

Resources

• WCAG 2.2 — the standard itself, plus the friendly How to Meet WCAG quick-reference (filter by level and technology) and the WAI overview when the spec feels dense.
• WAI tutorials and the ARIA Authoring Practices Guide (APG) — copy-pasteable, tested patterns for menus, dialogs, tabs and comboboxes.
• MDN Accessibility — the developer’s working reference for the HTML/ARIA/CSS specifics.
• WebAIM and The A11y Project — plain-language articles, a community checklist, and WebAIM’s annual Million report on the state of the web.
• Platform docs — Apple Human Interface Guidelines (Accessibility) and Android accessibility.
• Tools — axe DevTools, WAVE, Lighthouse and Pa11y for scanning; NVDA (a free screen reader); and this site’s own contrast checker.

The whole field reduces to one habit: build with the grain of the platform — real elements, real labels, enough contrast, keyboard operable, motion optional — and test with the tools your users actually use. Do that, and accessibility stops being a checklist you dread and becomes just… building things properly.

Some of the figures in the charts and tables on this page were compiled with the help of AI tools and may contain errors or be out of date. They are shared in good faith for general interest only — not as professional, financial, investment or purchasing advice — and should be checked against the cited primary sources before you rely on them.