Accessibility Is a Baseline, Not a Feature
Roughly one in six people worldwide lives with some form of disability that can affect how they use the web. Accessibility work isn’t an optional enhancement for a subset of users — it’s fixing barriers that shouldn’t exist in the first place, and it frequently improves usability for everyone.
Semantic HTML Is Your First Line of Defense
Using a <button> instead of a styled <div> gets you keyboard focus, screen reader announcement, and correct semantics for free. Reaching for ARIA attributes to patch over non-semantic markup should be a last resort, not a first instinct — the platform already solved most of these problems if you use the right elements.
Keyboard Navigation
Every interactive element needs to be reachable and operable via keyboard alone. Try navigating your own app using only Tab, Shift+Tab, Enter, and Space — you’ll quickly find focus traps, invisible focus indicators, and interactive elements that mouse users can reach but keyboard users can’t.
Color Contrast and Not Relying on Color Alone
WCAG requires a minimum contrast ratio (4.5:1 for normal text) between foreground and background colors. Beyond contrast, never use color as the only signal for meaning — a red border on an invalid field needs an accompanying icon or text, since color-blind users and screen reader users won’t perceive color alone.
Meaningful Alt Text
Alt text should describe the purpose of an image in context, not just its literal content. A decorative image should have an empty alt="" so screen readers skip it entirely, while a functional image (like an icon button) needs alt text describing what the button does, not what the icon looks like.
Form Labels and Error Messages
Every form input needs a properly associated <label>, and validation errors need to be announced to screen readers, typically via aria-live regions, not just displayed visually. A form that’s usable for sighted mouse users but silent for screen reader users on error is a common, easily fixed failure.
Testing Tools Worth Using
- axe DevTools — catches a meaningful share of automated-detectable issues directly in the browser.
- Screen readers (VoiceOver, NVDA) — nothing replaces actually navigating your app with one.
- Keyboard-only testing — free, fast, and catches an enormous class of real issues.
Automated tools catch maybe a third of real accessibility issues — actual testing with assistive technology, or with users who rely on it, remains irreplaceable.