How to get developers to take accessibility seriously

The framing that developers need to be convinced to care about accessibility is already a concession. It implies they're resistant to something obvious, and that the problem is attitude. In my experience the problem is almost never attitude. Most developers I've worked with genuinely don't want to ship things that don't work. The problem is that the feedback loop for accessibility failures is broken in ways that make the failures invisible until they're expensive.

Fixing the feedback loop is more effective than any training program.

Why the current feedback loop fails

Accessibility problems are usually caught in one of three places: a formal audit, a QA pass just before release, or a user complaint after release. All three of these are too late to be cheap to fix. By the time an audit finds that your modal focus management is wrong, that behavior is in a shared component used across 30 screens, and "fix it" means touching everything.

The developer who built that modal three months ago wasn't trying to get it wrong. They didn't know what correct focus management looks like, because no spec told them, no reviewer caught it in PR, and no automated test failed. The signal they got from the system was: this is fine. It shipped. Nobody said anything.

The question to ask isn't "how do we make developers care?" It's "how do we make accessibility failures visible earlier?"

What earlier looks like

Linting catches a meaningful slice of issues at write-time, before anything is reviewed. eslint-plugin-jsx-a11y for React projects flags missing alt attributes, incorrect ARIA usage, non-interactive elements with click handlers, inputs without labels. The rules don't cover everything (they can't know whether your focus management is correct), but they catch the obvious failures before the PR is even opened. Adding this to a project's linting config is a half-hour task.

PR review is the next intervention point. Most teams don't review for accessibility because no one is specifically looking for it. Adding a short checklist to the PR template ("does this component work with keyboard navigation? Does every interactive element have a label? If this is an overlay, does focus management match the spec?") takes 30 seconds per PR and surfaces issues when they're cheapest to fix. It also signals to developers that this is something the team actually checks.

Automated accessibility tests in CI catch a different class of issues: page-level structure problems, rendering failures, attribute combinations that are invalid. axe-core integrated into a Cypress or Playwright test suite runs against your actual rendered pages, not just a linting rule against JSX. It doesn't catch everything either, but the combination of linting, PR review, and automated tests in CI closes a large portion of the most common bugs.

The specificity problem

The single most common thing I hear from developers about accessibility feedback is that it isn't specific enough to act on. "This should be more accessible" is not a bug report. "This modal doesn't trap focus. Tab should cycle between the close button and the form fields while the modal is open" is a bug report.

The difference between those two is on the design and accessibility side, not the engineering side. Developers need the behavior specified to implement it correctly, the same way they need interaction design specified. If the spec says "modal, accessible" and nothing else, they'll implement the modal the way they know how to implement a modal, which may or may not include correct focus trapping, focus restoration, Escape key handling, and scroll lock.

Writing a focus management spec for a dialog is not complicated. It's maybe 200 words if you've done it once. Having that spec on every dialog in the product means every developer implementing a dialog knows exactly what "correct" looks like, can verify their work against the spec, and can write a test that fails when the behavior regresses. The investment in the spec pays back across every instance.

What actually changes behavior

Training sessions and talks about why accessibility matters have a short half-life unless they connect to the developer's actual workflow. Someone who attends an accessibility training and then goes back to a codebase with no linting, no PR checklist, no component specs, and no way to test will apply what they learned for roughly one ticket before the friction of the new workflow causes them to revert.

What sticks is when accessibility becomes part of the normal workflow: the linting rule that fails locally before CI, the PR template that asks the question, the component documentation that includes the keyboard behavior, the shared example of a correctly implemented dialog that can be copied.

The shortcut to getting developers to take accessibility seriously is making it concrete, specific, and cheap to get right. Vague, late feedback about abstract principles produces defensiveness. A failing lint rule, a specific spec, and a test that catches regressions produces a fixed bug.

The conversation that doesn't get had

There's a version of this where a developer ships an accessible component and nobody says anything. And a version where they skip the focus management because the spec was silent on it, it ships, and six months later an audit finds it.

Those two outcomes look the same from inside the team. Neither produces a visible feedback signal that behavior changed. The accessibility work that doesn't ship doesn't generate a complaint; it generates silence. Silence looks like success.

The teams that get this right have made the absence of accessibility a visible failure state: a failing test, a blocked PR, a definition of done that something doesn't meet. Once a developer has had the experience of a test failing because focus wasn't restored to the trigger element, they learn what focus restoration means in a way that no training session produces.

The feedback has to reach them at the moment they can act on it.