Handbook
/
Design & UX
Accessibility: Why It Matters and How to Start
Building accessible products isn't just ethical—it's good business. Here's how to get started without being overwhelmed.
Accessibility (a11y) means making products usable by people with disabilities. This includes visual, auditory, motor, and cognitive disabilities. About 15% of the world’s population has some form of disability.
Accessibility isn’t charity—it’s good design that benefits everyone.
Why Accessibility Matters
The Numbers
•
15% of the global population has a disability
•
8% of men have color blindness
•
By age 65, most people have some form of impairment
•
Many disabilities are temporary (broken arm) or situational (loud environment)
The Business Case
Larger market: Accessible products reach more customers.
Legal requirements: ADA, WCAG, and regional laws require accessibility. Lawsuits are increasing.
Better UX for everyone: Accessibility improvements help all users. Captions help in noisy environments. Clear navigation helps confused users.
SEO benefits: Many accessibility practices improve search rankings (alt text, semantic HTML, page structure).
The Ethical Case
People with disabilities deserve equal access to digital products. Full stop.
The Basics: WCAG
Web Content Accessibility Guidelines (WCAG) is the standard. It has three levels:
Level A: Minimum accessibility. Basic requirements.
Level AA: Target for most organizations. Required by many laws.
Level AAA: Highest level. Not always achievable.
Most companies target WCAG 2.1 Level AA.
Quick Wins
You can improve accessibility significantly with these changes:
Color Contrast
Text must have sufficient contrast with its background:
•
Normal text: 4.5:1 ratio minimum
•
Large text (18pt+): 3:1 ratio minimum
Tools:
•
Contrast checker in browser dev tools
•
Coolors Contrast Checker
•
WebAIM Contrast Checker
Common violations:
•
Gray text on gray backgrounds
•
Brand colors that don’t contrast
•
Placeholder text too light
Alt Text for Images
Images need alternative text that conveys their meaning:
<!-- Good -->
<img src="chart.png" alt="Sales increased 40% from Q1 to Q2">
<!-- Bad -->
<img src="chart.png" alt="Chart">
<!-- Decorative image - empty alt is correct -->
<img src="decorative-line.png" alt="">
Tips:
•
Describe the content and function, not the appearance
•
For charts, describe what the data shows
•
For decorative images, use empty alt (alt="")
Keyboard Navigation
Everything should be usable with keyboard alone:
•
Tab through interactive elements
•
Enter/Space to activate
•
Escape to close modals
•
Arrow keys for menus
Test it: Navigate your product using only keyboard. Can you do everything?
Common issues:
•
Focus not visible (add focus styles)
•
Can’t reach elements with Tab
•
Modal trap (can’t escape)
•
Skip to content link missing
Semantic HTML
Use HTML elements for their semantic meaning:
<!-- Good -->
<button>Submit</button>
<nav>...</nav>
<main>...</main>
<h1>Page Title</h1>
<!-- Bad -->
<div onclick="submit()">Submit</div>
<div class="nav">...</div>
<div class="main">...</div>
<div class="title">Page Title</div>
Semantic HTML gives assistive technology context.
Form Labels
Every input needs a label:
<!-- Good -->
<label for="email">Email</label>
<input type="email" id="email">
<!-- Also good -->
<label>
Email
<input type="email">
</label>
<!-- Bad - placeholder is not a label -->
<input type="email" placeholder="Email">
Focus Indicators
Focused elements must be visually indicated:
/* Don't remove focus outlines */
*:focus {
outline: none; /* DON'T DO THIS */
}
/* Do style them appropriately */
*:focus-visible {
outline: 2px solid #3b82f6;
outline-offset: 2px;
}
Skip Links
Let keyboard users skip navigation:
<body>
<a href="#main" class="skip-link">Skip to main content</a>
<nav>...</nav>
<main id="main">...</main>
</body>
.skip-link {
position: absolute;
left: -9999px;
}
.skip-link:focus {
left: 0;
}
Common Accessibility Issues
Issue 1: Non-Text Content
Problem: Images without alt text, icons without labels.
Fix: Add alt text to images, aria-label to icon buttons.
Issue 2: Color as Only Indicator
Problem: Using color alone to convey meaning (red = error).
Fix: Add icons, text, or other indicators alongside color.
Issue 3: Missing Form Labels
Problem: Inputs without associated labels.
Fix: Use <label> elements properly.
Issue 4: Poor Heading Structure
Problem: Skipped heading levels, headings for styling.
Fix: Use headings hierarchically (h1 → h2 → h3).
Issue 5: No Keyboard Access
Problem: Click-only interactions.
Fix: Ensure keyboard handlers, use proper interactive elements.
Issue 6: Auto-Playing Media
Problem: Video/audio that plays automatically.
Fix: Don’t auto-play, or provide easy controls to stop.
Issue 7: Time Limits
Problem: Sessions that expire, countdowns that can’t be extended.
Fix: Allow extending time, warn before expiration.
Testing Accessibility
Automated Testing
Run automated checks:
•
Lighthouse (built into Chrome DevTools)
•
axe DevTools browser extension
•
WAVE (web accessibility evaluator)
Automated tools catch ~30% of issues. They’re a starting point, not complete.
Manual Testing
Automated tools can’t catch everything:
•
Navigate with keyboard only
•
Use a screen reader (VoiceOver, NVDA)
•
Zoom to 200% and check layout
•
Test with color blindness simulators
User Testing
Include users with disabilities in your user testing. Their feedback reveals issues you won’t find otherwise.
ARIA When Needed
ARIA (Accessible Rich Internet Applications) adds accessibility information when HTML isn’t enough:
<!-- Button that's not a button -->
<div role="button" tabindex="0" aria-pressed="false">Toggle</div>
<!-- But better: just use a button -->
<button aria-pressed="false">Toggle</button>
ARIA rules:
1.
Don’t use ARIA if HTML can do it
2.
Don’t change native semantics
3.
All interactive ARIA controls must be keyboard accessible
When you need ARIA:
•
Custom components (tabs, accordions)
•
Live regions (notifications)
•
Complex widgets
Building an Accessible Culture
Make It Part of Process
•
Include accessibility in design reviews
•
Add accessibility checks to QA
•
Test with screen readers before launch
•
Include a11y in definition of done
Train Your Team
•
Share resources with designers and developers
•
Include accessibility in onboarding
•
Celebrate a11y improvements
Start Small
You don’t need to fix everything at once:
1.
Audit current state
2.
Prioritize by impact
3.
Fix high-impact issues first
4.
Improve incrementally
Resources
•
WebAIM – Excellent guides and tools
•
A11y Project – Community-driven accessibility checklist
•
MDN Accessibility – Technical documentation
•
Deque University – In-depth training
•
axe DevTools – Browser testing extension
Key Takeaways
•
Accessibility benefits 15%+ of users and improves UX for everyone
•
Quick wins: color contrast, alt text, keyboard navigation, semantic HTML
•
Automated tools catch ~30% of issues—manual testing is essential
•
Use ARIA only when HTML semantics are insufficient
•
Build accessibility into your process, not as an afterthought
•
Start small and improve incrementally
AIMake has access to all of this
Our AI has access to the entire Startup Handbook. Ask it anything about building your startup.
Get started →
Next →
How to Give Design Feedback That Helps