Experience—2025-09-12 • 6 min read

Accessibility Is a Frontend Skill, Not a Compliance Checkbox

Building accessible interfaces makes you a better frontend engineer — not because it's the right thing to do, but because it forces you to understand how the web actually works.

The word "accessibility" tends to land in engineering conversations in one of two ways: as a legal requirement someone in compliance brought up, or as a sprint item that gets deprioritized when timelines get tight. In neither case is it treated as something frontend engineers should actually care about as engineers. That's a problem — not primarily an ethical one, though it is that too, but a technical one.

The engineers I've worked with who take accessibility seriously tend to have a much deeper understanding of how browsers work, how semantics translate to user experience, and what the DOM is actually doing beneath the framework abstractions. That knowledge bleeds into everything else they build. Accessibility work is HTML and browser mechanics work in disguise.

When you build for a screen reader, you're forced to think about what your UI means, not just what it looks like. That discipline improves everything.

Semantic HTML is the 80% solution

A depressingly large percentage of accessibility issues in modern web apps come down to using the wrong HTML element. Clickable divs instead of buttons. Links that are really buttons (and vice versa). Form inputs without labels. Headings that are just bold text. Lists that are styled divs.

This matters because browsers and assistive technologies derive their understanding of your UI from its semantics. A <button> is keyboard focusable, activatable with Enter and Space, and announced as "button" to screen readers — for free, with no JavaScript. A <div onClick> is none of those things unless you manually add role, tabIndex, and keyboard event handlers. You're doing extra work to get worse results.

// This requires manual ARIA and keyboard handling to be accessible <div onClick={handleSave} className="btn">Save</div> // This is accessible by default, keyboard-navigable, and screen-reader friendly <button type="button" onClick={handleSave} className="btn">Save</button> // For navigation: <a> goes to a URL, <button> performs an action // Getting this distinction right matters for both accessibility and SEO <a href="/dashboard">Go to Dashboard</a> <button type="button" onClick={openModal}>View details</button>

Focus management in SPAs

Single-page applications create accessibility problems that static sites don't have. When a user navigates to a new route, a screen reader on a traditional website gets a page load event and announces the new page title. In a SPA, the URL changes and the content re-renders, but none of that triggers the browser's native accessibility announcements. From the perspective of a screen reader user, nothing happened.

The solution is to manage focus explicitly on route changes. The common approach is to move focus to the main content area (or a visible heading) after navigation, and to use a live region to announce the new page title. It takes about ten lines of code and makes a significant difference for users navigating by keyboard or screen reader.

Accessibility wins that require minimal effort

Use the correct semantic element for every interactive component
Every image needs alt text (empty string for decorative images)
Every form input needs an associated <label>
Color contrast meets WCAG AA at minimum (4.5:1 for normal text)
Tab through your UI yourself — if you get lost, so will keyboard users

ARIA: the last resort, not the first

There's a tendency, once engineers discover ARIA attributes, to reach for them as the primary accessibility tool. It's understandable — aria-label and role feel like the explicit, code-like solution to an accessibility problem. But the first rule of ARIA is that you shouldn't use it if there's a native HTML element that does the same thing.

ARIA is for patterns that HTML doesn't have native semantics for: complex custom widgets like comboboxes, tab panels, tree views, date pickers. For those cases, it's essential. But adding role="button" to a div when you could use a button, or aria-label on an input when you could use a visible label, is solving the symptom instead of the cause. And incorrect ARIA is often worse than no ARIA at all, because it actively misleads assistive technologies.

Testing accessibility without specialized tools

You don't need a screen reader to catch most accessibility issues. Two tests that take less than five minutes will surface the majority of problems: navigate through your UI using only the Tab key, and run it through the axe DevTools browser extension. The first tells you whether keyboard navigation is logical and complete. The second catches semantic and contrast issues automatically.

If you want to go further, actual screen reader testing — with VoiceOver on macOS, NVDA on Windows, or TalkBack on Android — will surface things that automated tools miss. It's worth doing at least once per major feature, not to achieve perfection, but to develop an intuition for how the tools interpret your markup.

Conclusion

Accessibility work, at its core, is about building things that behave correctly — in all the environments and modalities your users interact with, not just the one you tested on. That's not a special requirement. That's just engineering.

The frontend engineers who make accessibility a habit tend to write cleaner HTML, think more carefully about interaction design, and understand browser behavior at a level that makes them better at their job across the board. It's one of the few areas where doing the right thing and becoming more skilled are exactly the same activity.

Tags:

AccessibilityUXFrontendInclusive DesignStandards