Is eslint-plugin-jsx-a11y actually catching real accessibility problems here?

[mikiyas-biniyam]

I saw the recent addition of eslint-plugin-jsx-a11y and I’m wondering how much of the project’s accessibility quality is coming from that versus manual review. With a lot of dynamic Next.js components and i18n content, are there cases where the linter passes but the UI is still not accessible in real usage (like screen readers or keyboard navigation)?

[Binivert]

Good question—and honestly, yes, that can happen. The jsx-a11y plugin is mainly a safety net. It’s great at catching obvious issues early, like missing alt text, incorrect ARIA roles, or non-interactive elements pretending to be buttons. But it doesn’t understand runtime behavior, translated content, or how components actually feel when navigated with a keyboard or screen reader.

That’s why this project treats the linter as a baseline, not the finish line. The content, examples, and components are still reviewed with real accessibility use cases in mind—focus order, semantic structure, and how things behave once everything is rendered. The plugin helps keep contributors from introducing basic mistakes, but the learning value and accessibility accuracy come from deliberate design choices and human review, not just passing ESLint.