Web Accessibility: Who It Really Serves and Where to Start

Part 1 of 8 in the "Accessible Web in Practice" series.

Accessibility is often treated as care for a small group of users. In reality almost everyone runs into interface barriers, and 95.9% of popular websites have errors that can be detected automatically. The first part of this series covers who accessibility affects, how people actually use websites, and how the WCAG 2.2 standard works.

Not "for disabled people" — for everyone

When developers hear "accessibility," they usually picture a blind user with a screen reader. Those users are real, and for them accessibility decides whether a site can be used at all. But that's only part of the picture.

According to the WHO, about 1.3 billion people — 16% of the world's population, one in six — live with significant disability (WHO, 2023). Those are permanent conditions. Add temporary and situational ones, and it turns out almost everyone runs into interface barriers at some point.

Microsoft's Inclusive Design toolkit describes this as a spectrum (Microsoft Inclusive Design):

Permanent	Temporary	Situational
One arm	Arm in a cast	Holding a baby
Blind	Dilated pupils after an eye exam	Bright sun on a phone screen
Deaf	Ear infection	Loud bar, muted video on a train
Tremor, cerebral palsy	Broken finger	Riding a bumpy bus
Dyslexia, ADHD	Concussion, fatigue, medication	Distractions, stress

That's the core idea of this guide: an accessible interface is simply a well-built interface. Field labels help both a screen reader user and someone who forgot what they were typing. A visible focus indicator serves a blind keyboard user and a developer filling in a form without a mouse. Enough contrast saves a low-vision user and everyone reading their phone outdoors.

How bad is it

Every year WebAIM tests the home pages of the top one million websites. The February 2026 report (WebAIM Million 2026):

• 95.9% of home pages had automatically detectable WCAG failures (94.8% in 2025);
• an average of 56.1 errors per page, up 10% from the year before;
• the six most common issues:

Issue	Share of pages
Low contrast text	83.9%
Missing alternative text for images	53.1%
Missing form input labels	51.0%
Empty links	46.3%
Empty buttons	30.6%
Missing document language	13.5%

Notice that all six are fixable with basic HTML and CSS. No advanced technology — just attention to detail. That's what this series is about.

How people actually use websites

Before writing code, it helps to understand which devices and input methods it has to work with.

Screen readers read the interface aloud or output it to a refreshable braille display. The main ones are NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. Screen reader users rarely read a page top to bottom: they jump between headings, landmarks, links and form fields, often pulling up lists of those elements.

Keyboard. Many people can't use a mouse, or simply prefer not to: motor impairments, tremor, blind users, and power users who are just faster on the keyboard. The essentials: Tab / Shift+Tab move between interactive elements, Enter and Space activate, arrow keys move inside composite widgets, Esc closes things.

Voice control. Voice Control on macOS and iOS, Voice Access on Android, Dragon on Windows. The user says "click Submit," and the software looks for an element with that accessible name. If the button visibly says "Submit" but its aria-label is "submit-btn," the voice command fails.

Magnification. Browser zoom up to 200–400%, screen magnifiers, larger system fonts. Layouts have to survive this without horizontal scrolling or overlapping text.

Alternative input devices: switch access, eye tracking, joysticks. Most of them emulate a keyboard one way or another — one more reason keyboard accessibility is critical.

The accessibility tree

From the DOM, the browser builds a separate accessibility tree and exposes it to assistive technology through operating-system APIs. Every node in that tree has:

• a role — what it is: button, link, heading, checkbox;
• a name (accessible name) — what it's called: "Submit," "Home";
• states and properties — pressed, expanded, checked, disabled;
• a value — for inputs and sliders.

You can inspect the tree right in DevTools: in Chrome, Elements → Accessibility tab (with the full accessibility tree toggle); in Firefox, the Accessibility panel. It's the best way to see what a screen reader "sees."

Nearly all accessibility work comes down to one thing: every element in the accessibility tree needs the right role, name and state. Semantic HTML handles that better than anything else.

WCAG 2.2 in five minutes

WCAG (Web Content Accessibility Guidelines) is the W3C standard most guidelines and audits refer to. The current recommendation is WCAG 2.2, published in October 2023 (W3C).

It's built on four principles, known as POUR:

1. Perceivable. Information can be perceived through at least one available sense: images have text alternatives, videos have captions, text has enough contrast.
2. Operable. The interface can be operated: everything works with a keyboard, there's enough time, nothing flashes dangerously, there are ways to navigate.
3. Understandable. Text is readable, behavior is predictable, and there's help with input errors.
4. Robust. Code is interpreted correctly by browsers and assistive technologies, including future ones.

Each success criterion has a level: A (minimum), AA (the standard target for most sites) and AAA (enhanced, usually not required in full). When people say a site "meets WCAG," they almost always mean level AA.

What's new in 2.2

The new criteria that matter most for developers:

Criterion	Level	What it means
2.4.11 Focus Not Obscured (Minimum)	AA	The focused element must not be fully hidden by a sticky header, cookie banner, etc.
2.5.7 Dragging Movements	AA	Any drag action needs a single-pointer alternative
2.5.8 Target Size (Minimum)	AA	Targets at least 24×24 CSS pixels (or with enough spacing)
3.2.6 Consistent Help	A	Help links in the same place on every page
3.3.7 Redundant Entry	A	Don't make people re-enter the same data in one process
3.3.8 Accessible Authentication (Minimum)	AA	No cognitive tests to log in: allow paste and password managers

Criterion 4.1.1 Parsing was removed in 2.2: modern browsers repair markup errors consistently, so it no longer made sense.

Reading the full standard straight through is hard going. It's easier to start with the WCAG Quick Reference, which filters by level and technology, and the "Understanding WCAG" explainer for each criterion.

The "Accessible Web in Practice" series

1. Web Accessibility: Who It Really Serves and Where to Start — you are here
2. Semantic HTML and Alt Text: The Foundation of an Accessible Website
3. Accessible Forms: Labels, Hints, Errors and Autofill
4. Keyboard and Focus: Building a Website You Can Use Without a Mouse
5. Contrast, Motion and Button Size: Visual Accessibility
6. ARIA and Dynamic Content: When Attributes Help and When They Hurt
7. Accessibility in React: IDs, Focus on Route Change and Announcements
8. How to Test Accessibility: Automation, Manual Checks and a Checklist

Next part: Semantic HTML and Alt Text: The Foundation of an Accessible Website

Agama Labs builds websites and web applications. Want to check how accessible your site is? Write to us: hello@agamalabs.com