ZemDomu and eslint-plugin-jsx-a11y: when to use each
ZemDomu and eslint-plugin-jsx-a11y are both static accessibility linters, but they enter a project through different workflows and do not have identical coverage. Choose from documented capabilities and a reproducible fixture instead of treating either rule catalog as a universal replacement for the other.
Start with what both tools are
eslint-plugin-jsx-a11y describes itself as a static AST checker for accessibility rules on JSX elements. Its official documentation recommends combining static checks with rendered-DOM and assistive-technology testing.
ZemDomu also checks source before rendering. It supports HTML, JSX, TSX, and Vue, and exposes the same semantic rule catalog through VS Code, the CLI, and GitHub Actions. Its project-aware mode follows supported imported components for checks whose answer depends on composition.
A diagnostic from either tool means a supported source pattern matched a rule. A clean lint run does not establish WCAG conformance or prove that a completed interaction is accessible.
Compare the documented scope
Use eslint-plugin-jsx-a11y when JSX already runs through ESLint and you want its recommended or strict configuration, JSX interaction rules, role checks, and custom-component or polymorphic-component mappings.
Use ZemDomu when the repository also contains supported HTML or Vue templates, when headings, landmarks, sections, or ids need import-aware project context, or when you want one ZemDomu rule system in the editor, local scripts, and GitHub Actions.
The catalogs overlap on patterns such as alternative text, labels, link and button names, iframe titles, document language, ARIA values, and positive tabindex. Exact rule semantics differ. eslint-plugin-jsx-a11y also documents JSX interaction and role rules that ZemDomu does not claim, while ZemDomu documents page-structure and cross-component checks that are not listed as eslint-plugin-jsx-a11y rules.
Reproduce a cross-component heading check
In this fixture, each heading has content, but the page assembled through the import skips h2. Run a ZemDomu workspace or CLI scan with cross-component analysis enabled, then run eslint-plugin-jsx-a11y with a pinned version and configuration.
The eslint-plugin-jsx-a11y catalog documents heading-has-content; its current official rule list does not document heading-order analysis across imported files. That statement describes the published catalog, not undocumented internal behavior, so save the actual diagnostics with the fixture.
// ReportsPage.tsx
import { ReportCard } from "./ReportCard";
export function ReportsPage() {
return (
<main>
<h1>Reports</h1>
<ReportCard />
</main>
);
}
// ReportCard.tsx
export function ReportCard() {
return (
<section>
<h3>Weekly report</h3>
</section>
);
}Make the comparison testable
Pin both tool versions, publish the full configurations and source commit, run both tools without suppressions, and record their rule names, messages, and exit codes. Change one defect at a time so a result can be tied to a documented rule.
Do not convert one fixture into an effectiveness percentage or claim that either catalog is a superset. A fair comparison reports what the pinned configurations observed and keeps rendered behavior outside the static result.
- Run npx zemdomu "src/**/*.{jsx,tsx}" --cross --cross-depth 3.
- Run ESLint with the pinned eslint-plugin-jsx-a11y configuration against the same source commit.
- Save the enabled rules, diagnostics, tool versions, and exit codes with the fixture.
- Follow both static runs with rendered browser and assistive-technology testing.
Use both when both scopes matter
In a React project, using both can be reasonable when both rule catalogs provide relevant checks. This is an inference from their documented scopes, not a claim that every project needs two linters.
Expect some overlapping findings. Pin versions, decide which tool owns suppressions and CI failure policy, and keep browser, keyboard, visual, and assistive-technology tests for outcomes neither static tool can prove.