Who uses accessibility features
Before any rules or specs, meet the people you're building for.
Accessibility — often shortened to a11y because there are eleven letters between the a and the y — is the practice of building things people can actually use, no matter how they show up. Before we touch a single rule or guideline, you need to picture the people on the other side of the screen. Specs make a lot more sense once you can see a real face behind each one.
This lesson is a tour. No code yet. Just stories.
Screen-reader users
A screen reader is software that reads the page out loud (or sends it to a refreshable braille display). Think of it as a narrator. Popular ones include NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android.
Picture Amina. She's blind, and she's been using a computer for fifteen years. She's not slow at the web — she's fast. She tabs through links, jumps by heading with a single key, pulls up a list of all the buttons on a page. When she lands on your site, her screen reader announces things like:
"Main, navigation, list with five items, link, About, link, Pricing…"
If your "button" is actually a <div> with a click handler, her screen reader will announce it as plain text. She won't know it's interactive. She'll move on.
Screen-reader users don't read your page top-to-bottom. They scan with shortcuts — by heading, by landmark, by link. Good structure is what makes scanning possible.
<div onclick="...">Submit</div>. A screen-reader user lands on it. What's most likely to happen?Keyboard-only users
Some people can't use a mouse — maybe because of tremors, repetitive strain, a missing limb, or just personal preference. Power users often prefer the keyboard for speed. Keyboard-only means every interactive thing on your page must be reachable and operable using just keys: Tab to move forward, Shift+Tab to go back, Enter or Space to activate, arrow keys for menus and sliders.
Try this right now: press Tab on a page you're proud of. Can you see where you are? Can you reach the menu? Can you open a modal and close it without grabbing the mouse? If any answer is "no," that's a real bug for a real person.
Low-vision users
Low vision covers a huge spectrum. Some people zoom the browser to 200% or 400%. Some use OS-level magnifiers that zoom into a small square that follows the cursor. Some have a narrow field of view. Some have trouble with glare and need high-contrast modes.
Meet David. He has macular degeneration. He keeps his browser at 200% zoom permanently. When sites assume their layout will only ever be seen at 100%, his experience breaks: text overlaps, buttons run off-screen, modals get cut off so the close button is invisible. Designing flexibly — letting text reflow, avoiding fixed pixel widths on text containers — is a kindness to David and to anyone reading on a small phone.
Color-blind users
Roughly 1 in 12 men and 1 in 200 women have some form of color-vision deficiency. The most common type makes red and green look similar. So when your form says "fields in red are required" — and that's the only signal — a chunk of users won't notice anything red.
The rule isn't "don't use color." It's "don't use color alone." Pair color with text, an icon, an underline, or a shape. Then the color becomes a nice extra, not a load-bearing wall.
Motor-impaired users
Motor impairment is anything that makes precise, fast movements hard. Cerebral palsy, Parkinson's, arthritis, a temporary cast, or just an old trackpad on a moving train. These users may use a keyboard, a switch device (one button that cycles through choices), eye tracking, voice control, or speech-driven mouse software.
The thing they hate most is small targets and timeouts. A 12-pixel "X" in the corner of a modal is a nightmare. A "you have 30 seconds to confirm" countdown can lock them out of their own bank. Generous click targets (at least 24×24 CSS pixels, ideally bigger), and never punishing slow interaction, helps everyone — including anyone using your app one-handed while holding a baby.
Cognitive considerations
Cognitive accessibility is about how people understand, remember, focus, and process. It includes folks with ADHD, dyslexia, autism, anxiety, traumatic brain injury, and ordinary humans who are just tired. The fixes are usually about clarity:
- Plain language. Short sentences. One idea at a time.
- Predictable layouts — the menu is in the same place every time.
- Errors that explain what went wrong and how to fix it, not "Error 4017."
- Don't autoplay sound. Don't surprise people with motion.
Confusing UX isn't only an accessibility problem — it's just bad UX. But for someone with anxiety or a processing difference, "a little confusing" can become "I literally cannot complete this task."
It's actually everyone
A handy frame is the curb-cut effect. Curb cuts — those little ramps at the corner of a sidewalk — were fought for by wheelchair users. Now everyone uses them: parents with strollers, delivery folks with carts, kids on scooters, you with a suitcase.
Web accessibility is the same. Captions help in a noisy café. Big tap targets help on a bumpy bus. Reduced motion helps anyone with a headache. Permanent, temporary, and situational disabilities all benefit. You won't always know which one a user has, and you don't need to.
You've now met the people. The next lesson opens up the hood and shows you the data structure browsers build for assistive tech — the accessibility tree.