Why Accessibility Matters
Over one billion people worldwide live with some form of disability. Building accessible web applications is not just a legal requirement under ADA and EAA—it is good engineering. Accessible apps are more usable for everyone, rank better in search engines, and reach a wider audience. When you build for accessibility, you build a better product for all users.
Accessibility also has direct business impact. Companies face lawsuits for inaccessible websites—web accessibility litigation has increased year over year. Beyond legal risk, accessible products reach a larger market. Screen reader users, keyboard-only navigators, users with low vision or color blindness—these are real customers you lose when your application is not accessible.
Semantic HTML First
Before reaching for ARIA attributes, use the correct HTML elements. A <button> is inherently focusable and responds to keyboard events. A <div onClick> does not. Use <nav>, <main>, <article>, and <aside> to give screen readers structural context. These landmark elements create a navigable outline of your page that assistive technology users rely on.
In React, this means being intentional about your JSX. Replace generic <div> wrappers with semantic elements wherever possible. Use <section> with an aria-labelledby pointing to its heading. Use <ul> and <li> for lists, not styled divs. The browser gives you accessibility features for free when you use the right elements.
Keyboard Navigation
Every interactive element must be reachable and operable with a keyboard. Test your app by unplugging your mouse: can you Tab through all controls, press Enter to activate buttons, and Escape to close modals? If not, you have work to do. Keyboard navigation is the foundation of accessibility—if it works with a keyboard, it likely works with screen readers and other assistive technologies.
Manage tab order with tabIndex. Use tabIndex={0} to add non-interactive elements to the tab order (sparingly). Use tabIndex={-1} to make elements programmatically focusable without adding them to the tab order. Never use positive tabIndex values—they create a confusing custom tab order that breaks user expectations.
Focus Management in SPAs
When React navigates between routes, the browser does not announce the new page. Move focus to the main heading of the new route using useRef and useEffect. Use an aria-live region to announce route changes to screen readers. Without focus management, screen reader users land on a new page with no indication that anything changed.
Modal dialogs require careful focus trapping. When a modal opens, move focus to the first interactive element inside it. Prevent Tab from escaping the modal. When the modal closes, return focus to the element that triggered it. Libraries like Radix UI and Headless UI handle this correctly—use them instead of building focus traps from scratch.
ARIA Attributes Done Right
ARIA should supplement, not replace, native semantics. Common patterns: aria-expanded on accordion triggers, aria-label on icon-only buttons, role="dialog" with aria-modal="true" on modals. Avoid role="button" on divs—just use a button element. The first rule of ARIA is: do not use ARIA if a native HTML element can do the job.
Automated Testing with axe-core
Integrate @axe-core/react in development to log violations to the console. Add jest-axe to your test suite to catch regressions. Run Lighthouse accessibility audits in CI to enforce a minimum score. Automated tools catch about 30% of issues—manual testing with a screen reader like VoiceOver, NVDA, or JAWS catches the rest.
Color Contrast and Motion
Ensure a minimum 4.5:1 contrast ratio for normal text and 3:1 for large text. Respect prefers-reduced-motion to disable animations for users who experience motion sickness. Tailwind CSS makes this straightforward with motion-reduce: variants. Never convey information through color alone—always pair color with text, icons, or patterns.
Conclusion
Accessibility is not a feature you add at the end—it is a practice you embed from the start. Use semantic HTML, test with a keyboard, manage focus in your SPA, and automate what you can. The result is an application that works for everyone, not just users who happen to use a mouse and have perfect vision.
0 Comment