jsx-a11y and Component-Level Guardrails

Many accessibility mistakes are easy to spot in code. A linter can flag them as you type, long before a real user ever hits the barrier. 🛡️

The eslint-plugin-jsx-a11y package adds accessibility rules to ESLint for JSX. It checks your components for common, well-known a11y errors.

Extend the plugin's recommended config to enable a solid baseline of rules at once, instead of switching each one on by hand.

The plugin warns when an img has no alt attribute. That single rule prevents a very common and high-impact accessibility failure.

Putting onClick on a div without keyboard support triggers a warning. The fix is to use a real button, which is focusable and keyboard ready.

Rules verify that form controls have an associated label. A field without a label is flagged so it never reaches users unnamed.

The plugin checks that ARIA attributes and roles are real and used correctly. Typos like aria-lable or invalid roles get caught immediately.

A linter sees only your static code. It cannot judge if your alt text is meaningful or if focus order makes sense, so manual testing still matters.

Bake accessibility into shared components. A reusable Button that always renders a real button element spreads good behavior across the whole app.

Run ESLint in your pipeline so a11y warnings fail the build. This stops regressions from slipping past code review and into production.

With the ESLint editor extension, warnings appear right in your code. This fast feedback teaches the team accessibility patterns as they write.

Your team adds eslint-plugin-jsx-a11y to the project. What should you still not expect it to do?

Use jsx-a11y to catch common errors, build accessible shared components, and gate it in CI, while still relying on manual testing for the rest. ✅