Web Accessibility: It’s Not Charitable, It’s The Law
Domino’s Pizza got sued for millions because their website wasn’t compatible with screen readers. How to code for WCAG 2.1 AA compliance. A11y is ROI.
Accessibility (A11y) is often treated as “Nice to have.” It is not.
- Legal Risk: The ADA (Americans with Disabilities Act) applies to websites. Lawsuits are up 300%.
- Market Size: 15% of the world has a disability. That is a huge customer segment.
- SEO: A11y and SEO overlap 90%. Semantic HTML wins both. If you block a blind user, you block GoogleBot.
Why Maison Code Discusses This
We don’t do it just for the lawsuits. We do it because the “Purple Pound” (spending power of disabled households) is worth $274 Billion in the UK alone. We do it because “Curb Cut Effects” exist. (Curb cuts were made for wheelchairs, but they help strollers and suitcases). Captions were made for the deaf, but they help people watching videos on the Metro. A11y improves the experience for everyone.
1. Semantic HTML: The Foundation
Stop using <div> for everything.
- Button:
<button>, not<div onClick>. - Heading:
<h1>, not<div class="text-3xl">. - Navigation:
<nav>, not<div>. Screen readers rely on these tags to navigate. If you use adivbutton, a blind user cannot “Tab” to it. They cannot click it. It is a wall.
2. The “Focus Ring” Style
Designers hate the blue outline: outline: none.
NEVER remove the outline unless you replace it.
Keyboard users (Motor impaired) rely on the focus ring to know where they are.
Use :focus-visible to only show it for keyboard users, not mouse users.
/* Good UX */
button:focus {
outline: none; /* Hide default */
}
button:focus-visible {
outline: 2px solid var(--color-electric);
outline-offset: 2px;
}
3. ARIA Labels (Bridging the Gap)
When visual cues fail, use ARIA.
Example: An “X” icon to close a modal.
Visually: It’s obvious.
Audibly: It reads “Image”.
Fix: <button aria-label="Close Modal">X</button>.
Rule: Use Native HTML first. Use ARIA only when HTML is not enough.
Don’t use role="button" on a div if you can use a <button>.
4. Color Contrast (The #1 Failure)
Grey text on a slightly lighter grey background looks “Modern”. It is unreadable for low-vision users (and people looking at their phone in the sun). You need a contrast ratio of 4.5:1 for body text. Use the Chrome DevTools “CSS Overview” to check all colors. Also, support Dark Mode correctly. High Contrast Mode is critical for the elderly.
5. Automated Testing (The Pipeline)
We integrate Axe-core into the dev process. A human cannot catch everything.
- Linting:
eslint-plugin-jsx-a11ycatches<img>missingalttags. - Runtime:
@axe-core/reactlogs errors to the Console during development. - CI/CD: Pa11y runs in the pipeline. If accessibility drops below 90%, the build fails.
# Running Pa11y on CLI
npx pa11y https://maisoncode.paris
6. The “Skip to Content” Link
A blind user doesn’t want to listen to your Mega Menu (50 links) on every page load.
Add a hidden link at the top: “Skip to Main Content”.
It becomes visible on Focus.
<a href="#main" class="sr-only focus:not-sr-only">Skip to Content</a>
This is the hallmark of a professional site.
7. Motion Sensitivity (Vestibular Disorders)
Some animations cause nausea.
Respect the user’s OS setting: prefers-reduced-motion.
@media (prefers-reduced-motion: reduce) {
* {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
}
}
If they ask for stillness, give them stillness.
8. Screen Reader Testing (Manual)
Automation catches 30% of errors. You must test manually. Turn on VoiceOver (Mac) or NVDA (Windows). Close your eyes. Try to buy a product on your site. If you can’t… you are broken. This empathy exercise changes how you code.
10. The Cognitive Load (Neurodiversity)
Accessibility isn’t just physical. It’s mental. For users with ADHD or Autism, a chaotic interface is overwhelming. Guidelines:
- Consistency: Navigation should be in the same place on every page.
- Clarity: No jargon. Use plain language.
- Calm: Avoid auto-playing videos. Avoid flashing lights (Epilepsy risk). A calm interface is a high-converting interface.
11. The Voice Control Revolution (Siri / Dragon)
Users with motor impairments use Voice Control.
“Click Add to Cart.”
If your button is coded as <div onClick=...>, the voice software cannot see it.
It looks for “Buttons”.
If you use semantic HTML, Voice Control works out of the box.
“Scroll down. Click Checkout.”
This is the future of “Hands-free” commerce (Driving, Cooking).
A11y enables Voice Commerce.
12. The Zoom Proofing (Low Vision)
Users with low vision zoom in to 200% or 400%.
Does your layout break?
Do the letters overlap?
Fluid Typography: Use rem units, not px.
font-size: 1rem respects the user’s browser setting.
font-size: 16px forces your setting.
Test your site at 200% zoom.
If the menu disappears, you have failed.
13. The Legal Case Study (Domino’s)
In Robles v. Domino’s Pizza, the Supreme Court denied Domino’s petition. The ruling stands: The ADA applies to the digital world. Domino’s argued: “The law was written in 1990 before the web.” The Court said: “The intent is equal access. The medium doesn’t matter.” The Lesson: Waiting for a specific “Web Law” is a losing strategy. The risk is retroactive. You can be sued today for a site you built 3 years ago. Remediation is 10x more expensive than building it right the first time.
14. The Audit Checklist (WCAG 2.1 AA)
Don’t guess. Follow the list.
- Perceivable: Alt text, Captions, Contrast.
- Operable: Keyboard nav, No flashing, Time limits adjustable.
- Understandable: Consistent nav, Error identification, Predictable.
- Robust: Compatible with assistive tech (ARIA). Print this list. Tape it to your monitor. Every PR must pass this checklist.
15. The Future of A11y (AI Assistance)
AI will Transform accessibility. Generative Alt Text: Models like GPT-4 Vision can auto-caption 10,000 images in 1 hour. Real-time Simplification: AI can rewrite complex legal text into “Plain English” for users with cognitive disabilities. Voice Navigation: “Agent, buy me the red shoes.” We are building these features today. Accessibility is moving from “Compliance” to “Assistance”.
16. The Developer Experience (DX)
Writing accessible code is cleaner code.
Semantic HTML is easier to read than div soup.
button is clearer than div class="btn".
Enforcing A11y improves the codebase health.
It reduces technical debt.
It makes onboarding new developers faster.
Good DX = Good UX.
17. The Tab Index Trap (Dont use positive integers)
A common mistake is tabindex="1".
This forces the order.
If you rearrange the DOM, the tab order breaks.
Rule:
tabindex="0": Make a div focusable (in natural order).tabindex="-1": Make it focusable programmically (JS), but skip via Tab.tabindex="1": NEVER USE THIS. It fights the browser. Let the DOM dictate the order.
18. The Valid HTML Requirement (Parsing)
Screen readers are browsers. They parse your HTML. If you have unclosed tags or duplicate IDs, the parser guesses. Sometimes it guesses wrong. Rule: Your HTML must validate. Use the W3C Validator. Broken HTML = Broken Accessibility. It is the unexpected error that kills the experience. Write valid code.
19. The Maintenance Cost (Clean Code)
Accessible code is cheaper to maintain.
Why? Because it forces structure.
If you use <div> everywhere, your CSS becomes a nightmare of nested selectors .card div div span.
If you use <article> <h1> <p>, your CSS is simple.
It decouples style from structure.
This makes refactoring safer.
A11y is technically a Code Quality metric.
Invest in it.
20. Conclusion
Accessibility is empathy encoded. It means you care about all users, not just the ones with perfect vision and fine motor control. It protects you from lawsuits. It improves your SEO. It opens your market. There is no downside.
Get sued recently?
We audit and remediate accessibility violations.