Designing for Accessibility

What is it?

Designing for accessibility means creating products that work for people across the full spectrum of human ability — including those with visual, motor, cognitive, and auditory differences. It applies the principle that no user should be excluded from using a product because of how they interact with technology. Accessibility is not a feature set or a compliance checklist — it is a design discipline.

Why it matters

Approximately 1 in 4 adults in the US has some form of disability. Globally, that is over 1 billion people. Inaccessible products actively exclude this population. Beyond the ethical case, accessibility is legally required in many jurisdictions — the Americans with Disabilities Act (ADA), the European Accessibility Act (EAA), and EN 301 549 all mandate accessible digital products. Beyond compliance, accessible design benefits every user: captions help in noisy environments, high contrast helps in bright sunlight, and keyboard navigation helps power users.

Best Practices

• Start with WCAG 2.1 AA as your minimum standard — not a ceiling. AA is the legal and industry baseline across the US, UK, and EU.
• Integrate accessibility into design from day one. Retrofitting is 10–100× more expensive than building it in.
• Test with real assistive technology users, not just automated tools. Automated tools catch ~30% of accessibility issues — human testing finds the rest.
• Use semantic HTML. A <button> is inherently keyboard-accessible, focusable, and screen-reader-friendly. A <div> with an onClick handler is none of these things.
• Provide text alternatives for all non-text content: alt text for images, captions for video, transcripts for audio.
• Ensure all functionality is operable by keyboard alone. Not every user has a mouse or touch screen.
• Design visible focus indicators for every interactive element. Never use outline: none without providing a replacement.
• Do not rely on color alone to convey meaning. Always pair color with text, icons, or patterns.
• Ensure touch targets are at least 44×44px (Apple) or 48×48dp (Google). Smaller targets cause mis-taps and exclude motor-impaired users.
• Write error messages that identify the problem and explain how to fix it — not just "error occurred."

Common Mistakes

• Treating accessibility as a final QA checklist item rather than a design-phase concern.
• Using automated accessibility scanners as the only testing method — they miss context-dependent and user-flow issues.
• Removing CSS focus outlines without replacing them — the most common keyboard accessibility failure.
• Using placeholder text as form field labels — placeholders disappear when typing, leaving users without context.
• Building custom interactive components (dropdowns, modals, sliders) without ARIA attributes or keyboard support.
• Relying on hover states for critical functionality — keyboard and touchscreen users have no hover.
• Using color contrast ratios that "look fine" on a calibrated designer monitor but fail WCAG requirements.
• Providing PDFs as the primary accessible format — PDFs are consistently the hardest format to make truly accessible.

Checklist

Research & Theory

Real-World Examples