Accessibility in pull requests: what's realistic?

"Catch accessibility issues in the PR" is one of those goals everyone nods along to and few teams make stick — because the naive version asks every reviewer to be an accessibility expert on every change, which is neither realistic nor sustainable. But the answer isn't to give up and leave it all to a manual audit at the end. It's to be honest about what a PR can reliably catch, automate that, and route the rest to where it actually works. Here's where I draw the line.

What's realistic in a PR

These are cheap, mechanical, and catch a real slice of issues without expecting reviewer expertise:

• Automated checks in CI. An axe-style scan on changed pages catches the machine-detectable issues — missing alt text, missing form labels, color-contrast failures, missing landmark/ARIA basics. This is the highest-leverage move: it runs on every PR, never gets tired, and never forgets.
• Lint-level rules. A JSX/HTML accessibility linter flags missing alt, a positive tabindex, a click handler on a non-interactive element, right in the editor and the PR. Cheap and immediate.
• Reviewer spot-checks of the obvious. Not an audit — just "is this new control a real <button>, does this image have alt text, does this input have a label?" Things a non-expert can see in the diff.

What isn't realistic in a PR

Be honest that the most important accessibility properties cannot be verified by reading a diff:

• Keyboard operability — does the whole flow work without a mouse? You can't tell from the code; you have to use it. Focus order and focus traps are the same — they need a running build and a Tab key.
• Screen-reader experience — does it announce sensibly, in the right order, with the right context? That requires actually testing with a screen reader, not a glance at markup.
• Whether the automated scan's "pass" is meaningful — axe catches maybe a third of issues. A green scan is necessary, not sufficient. A Lighthouse/axe score isn't a test; treating a passing scan as "accessible" is the trap.

Asking reviewers to verify those in a PR doesn't shift the work left — it just produces rubber-stamp approvals and a false sense of coverage.

A realistic PR accessibility line

• In the PR (automate): axe/lint checks for alt text, labels, contrast, landmarks, positive tabindex
• In the PR (spot-check): native vs faux controls, alt presence, label presence — diff-visible only
• Not in the PR (route elsewhere): keyboard operability, focus management, screen-reader experience
• Treat the automated scan as necessary-not-sufficient — never "green = accessible"
• Reserve real keyboard + screen-reader passes for QA on a running build, not code review
• Don't ask reviewers to certify things a diff can't show — it manufactures false confidence

My actual opinion

The realistic model is two layers, not one. The PR layer is automated-plus-obvious: scans and linters do the heavy lifting, reviewers catch the diff-visible basics, and nobody pretends that's the whole story. The QA layer — on a real build — owns the things that need interaction: keyboard, focus, screen reader, the login and checkout flows where it actually counts. Trying to cram the second layer into the first is the mistake; it overloads reviewers and still misses the interactive bugs.

So: yes, put accessibility in pull requests — but put the right accessibility there. Automate the mechanical, spot-check the obvious, and stop pretending a code review can replace using the thing with a keyboard. The goal is more issues caught earlier, not a checkbox that says "a11y reviewed" on changes nobody actually tested for access.