Approximately one in five people lives with some form of disability. Vision impairments, motor limitations, cognitive differences, hearing loss — these aren't edge cases. They're core users. When we build for accessibility, we're not adding a feature for a minority audience; we're building for a fifth of the population, and we're building something that works better for everyone.
The curb cut effect is the canonical illustration of this principle. Curb cuts were added to sidewalks for wheelchair users, but they're used constantly by people with strollers, delivery workers with carts, cyclists, and anyone carrying heavy bags. Accessible design almost always benefits all users, not just those with disabilities.
Starting with Semantic HTML
Accessibility starts before any CSS or JavaScript is written. The foundation is semantic HTML — using elements for their intended purpose. A <button> element is focusable by default, responds to keyboard events, and communicates its role to assistive technologies. A <div> styled to look like a button does none of these things without additional work.
Heading hierarchy matters more than most designers realize. Screen reader users frequently navigate by headings — they're the page's structural outline. A heading hierarchy that skips levels, uses headings for visual sizing rather than semantic meaning, or crams everything into a single <h1> creates genuine navigation barriers.
Color and Contrast
WCAG 2.1 specifies minimum contrast ratios for text: 4.5:1 for normal text, 3:1 for large text. These thresholds exist because contrast directly affects readability for people with low vision, but contrast also affects readability in bright sunlight, on cheap displays, and when the viewer is fatigued. Good contrast is good design, full stop.
"Accessibility is not a feature. It's a property of good design — invisible when done well, glaring when neglected."
Color alone should never be the only means of conveying information. If your form uses red to indicate errors, a user with red-green color blindness may miss them entirely. Pair color cues with icons, labels, or text descriptions that communicate the same information through a different channel.
Keyboard Navigation
Every interactive element on your page should be reachable and operable using a keyboard alone. This matters for people who cannot use a pointing device, but also for power users who prefer keyboard navigation, for users of switch access devices, and for anyone who accidentally broke their trackpad (more common than you'd think).
Focus management in single-page applications requires particular care. When a modal opens, focus should move into it. When it closes, focus should return to the element that triggered it. When content updates dynamically, relevant changes should be announced to screen readers. These behaviors are the invisible scaffolding that makes complex interfaces navigable.
Cognitive Accessibility
Cognitive accessibility is often underrepresented in accessibility discussions, but it encompasses a wide range of considerations: plain language that doesn't require specialized knowledge, consistent navigation that doesn't change location or behavior unexpectedly, adequate time limits (or no time limits) for completing tasks, and error messages that explain what went wrong and how to fix it.
The WCAG Success Criterion 3.3.4 — Error Prevention — is one of my favorites. It requires that for important submissions (legal, financial, data deletion), users can either review and correct, reverse, or confirm before final submission. This protects everyone, but it particularly protects users who are more likely to make errors — which, on a bad day, is any of us.
Tags
