Linting and CI Gates for Accessibility

Tests run after code is written, but a linter flags problems as you type. The earlier you catch an issue, the cheaper it is to fix.

For React projects, the eslint-plugin-jsx-a11y ESLint plugin checks your JSX for common accessibility mistakes right in your editor.

jsx-a11y catches things like an image with no alt prop, an anchor without an href, or a click handler on a non-interactive element.

Add the alt prop and the warning disappears. The fix is tiny, and you saw it before the code ever shipped.

A linter reads source code, not the rendered page. It cannot measure contrast or focus order, so it complements, not replaces, axe scans.

A CI gate is a check that must pass before code can merge. If your accessibility test fails, the pull request is simply blocked.

Without a gate, a failing audit is just a warning everyone ignores. A gate turns accessibility into a requirement, not a polite suggestion.

A CI workflow installs dependencies, then runs your lint and test commands. A non-zero exit code automatically fails the job.

When the build goes red, the author sees the exact failing rule and element in the log. The feedback loop is minutes, not weeks.

A gate that breaks for the wrong reasons gets disabled. Keep tests stable and scoped so the team trusts a red build to mean a real problem.

The strongest setup stacks them: lint while coding, axe in tests, and a CI gate on merge. Each layer catches what the others miss.

Think about what a code linter can and cannot see.

Lint as you code, run axe in your tests, and gate merges in CI. Stacked together, these guardrails keep accessibility regressions from ever shipping. 🚦