Common myths

You now have the full beginner toolkit: the people, the tree, the spec, semantic HTML, contrast, focus, and preferences. To wrap up, let's pull out a few persistent myths that keep accessible work from happening — even on teams that want to do the right thing.

When you hear these in a meeting, you'll know what to say.

Myth 1: "ARIA fixes it"

There's a tempting belief that when something isn't accessible, you can sprinkle ARIA on it and call it done. role="button" here, aria-label there, ship it.

ARIA does not add behavior. Repeat that to yourself: ARIA does not add behavior. ARIA only changes how an element is described in the accessibility tree (lesson 2). A <div role="button"> is still a div — keyboard users can't tab to it, can't activate it with Enter or Space, and don't get any focus styles for free. You'd have to manually:

1. Add tabindex="0" so it's reachable.
2. Listen for keydown on Enter (call the handler, allow default).
3. Listen for keydown on Space (call the handler, prevent default so the page doesn't scroll).
4. Add a focus style.
5. Manage aria-disabled yourself.
6. Re-test every browser.

Or you could write <button> and get all six for free. Use ARIA to enhance native semantics, not replace them.

Myth 2: "Screen readers ignore CSS"

This one comes up when teams want to hide things visually but assume "the screen reader still gets it." Reality is more nuanced. Screen readers read the accessibility tree, which is built from the DOM after CSS is applied — and several CSS properties affect what ends up there.

Things that remove content from the a11y tree:

• display: none — gone for everyone.
• visibility: hidden — gone for everyone.
• aria-hidden="true" (technically not CSS, but often confused) — visually present, gone from a11y tree.
• Some assistive tech respects content: '' and pseudo-element CSS to read out generated content; some don't. Don't put load-bearing meaning in ::before or ::after.

Things that stay but become weird:

• A button you've shrunk to 1px with negative margins is still focusable, still in the tab order, and still announced — but invisible. This is how keyboard traps form.
• Text with color: transparent is still read.
• An element hidden by clip-path or clip (the visually-hidden pattern) is still read — that's deliberate.

The takeaway: CSS and the a11y tree are deeply linked. "Screen readers see what you see" isn't quite right, but "they ignore CSS entirely" is even further off. Test your assumptions in DevTools.

Myth 3: "We'll do a11y later"

The classic. Schedule pressure shows up, accessibility gets bumped to "phase 2," and "phase 2" never arrives.

The honest case against "later" is cost and reach. Accessibility done at build time is a small ongoing tax: pick the right element, label the form, check a contrast ratio. Accessibility added after the fact often means rebuilding components from scratch — replacing div-soup buttons with real buttons, untangling focus order, redoing color tokens, retesting with real users. A first-time audit on an inaccessible app routinely turns up hundreds of issues.

The reach side is just as real. The World Health Organization estimates 1 in 6 people globally have a significant disability. Add temporary and situational impairments and the number swells higher. Inaccessible work is shipped exclusion — every release builds more of it.

The myth's cousin is "we don't have those users." You probably do — they just left without filling out a survey.

Myth 4: "It's a small niche"

People sometimes assume accessibility is for "blind users" — and that there aren't many of them. Both halves are wrong.

• Blind and low-vision users together are tens of millions globally. Color-blindness alone is roughly 8% of men.
• Keyboard-only users include power users, people with motor impairments, and anyone whose mouse just died.
• Captions are used by deaf and hard-of-hearing users and by anyone in a noisy gym, a quiet library, or learning a second language.
• Cognitive accessibility — clear language, predictable layouts — helps people with ADHD, dyslexia, autism, brain injury, anxiety, and every tired human who reads your site at 11 PM.

The numbers add up to most of your audience, most of the time. The curb-cut effect we met in lesson 1 is real and operating constantly.

Myth 5: "Our automated tests pass"

We touched this in lesson 3. Tools like axe DevTools, Lighthouse, and Pa11y are wonderful — they catch missing alts, empty buttons, low contrast, broken structure. They miss anywhere from 60% to 70% of issues, including the most important ones:

• Whether your alt="logo" actually conveys what the logo means in context.
• Whether your tab order makes sense (it might pass "all elements are reachable" but still feel chaotic).
• Whether your error messages are useful, not just present.
• Whether your custom widget's keyboard interactions feel right.
• Whether the page makes sense at 200% zoom on a phone.

Automated checks belong in your CI. They are necessary and not sufficient. Pair them with manual keyboard passes, screen-reader spot checks, and — when budget allows — testing with real users with disabilities.

Habits that scale

You don't need to be an accessibility expert to ship accessible work. You need a small set of habits:

1. Pick the right element first, every time. (Lesson 4.)
2. Label every form field with a real <label>. (Lesson 4.)
3. Check contrast in your color picker as you design. (Lesson 5.)
4. Tab through the page before merging. (Lesson 6.)
5. Honor user preferences in your tokens. (Lesson 7.)
6. Run an automated check in CI as a regression net. (This lesson.)
7. When in doubt, ask "what would a screen reader say here?" — and check in the a11y tree devtools panel. (Lesson 2.)

That's the whole job, at this stage.

You're done with the foundations. From here, the natural next step is Keyboard and focus — the practical course on managing tab order, focus traps, and skip links in real apps. See you there.