Why Accessibility Matters
Building for accessibility isn't just about compliance -- it's about reaching everyone. Around 15% of the world's population lives with some form of disability. When we build inaccessible interfaces, we exclude a massive portion of potential users.
The good news? Most accessibility wins are straightforward to implement once you know the patterns.
Semantic HTML First
Before reaching for ARIA attributes, start with the right HTML elements. A button element already comes with keyboard support, focus management, and screen reader announcements built in.
Here's what proper semantic markup looks like:
- Use
navfor navigation blocks - Use
mainfor your primary content area - Use
headerandfooterfor page landmarks - Use
h1throughh6in proper order for heading hierarchy - Use
ulandolfor lists of items
Keyboard Navigation Patterns
Every interactive element must be reachable and operable with a keyboard alone. The key patterns to implement:
- Tab order -- Ensure logical tab flow through interactive elements
- Arrow keys -- Use for navigating within composite widgets like menus and tabs
- Escape -- Close modals, dropdowns, and popovers
- Enter/Space -- Activate buttons and links
ARIA When Needed
ARIA attributes fill the gaps when native HTML isn't enough. The most useful ones:
- aria-label -- Provides an accessible name when visible text isn't sufficient
- aria-expanded -- Tells screen readers whether a collapsible section is open
- aria-live -- Announces dynamic content changes to assistive technology
- role -- Defines the purpose of an element when semantic HTML can't
Focus Management
When content changes dynamically (modals opening, pages navigating), you need to manage focus manually. Move focus to the new content so keyboard and screen reader users aren't left behind.
The key principle: focus should always follow the user's intent. If they opened a modal, focus the modal. If they submitted a form, focus the success message.
Testing Your Work
Use a combination of automated tools and manual testing:
- axe DevTools for catching common issues automatically
- Screen readers like VoiceOver or NVDA for real-world testing
- Keyboard-only navigation to verify all interactions work without a mouse
Accessibility is a journey, not a destination. Start with these fundamentals and iterate from there.