Meteor isobuild pipeline and frontend framework a11y tooling: where does accessibility auditing belong?

Recommendation

Accessibility auditing belongs beside Meteor's isobuild pipeline, not inside its compilation step. Use framework linting for source-level issues, one shared browser-audit suite for rendered pages, and explicit keyboard tests for focus behavior; make CI the release gate.

Established boundary and uncertainty

Isobuild compiles and bundles application code. Accessibility auditing is a separate policy check: it may inspect templates or source, or require a rendered DOM and user interaction. A build failure should therefore mean the application could not be produced, not that a team chose a stricter WCAG threshold.

This answer assumes a Meteor 2.x or 3.x application mixing Blaze and React. Exact behavior of meteor lint, available extension points, and the maintenance status of community packages are version-sensitive and were not live-verified here. Do not assume that meteor lint automatically discovers eslint-plugin-jsx-a11y.

Likely explanation

The likely reason for the integration gap is that compilation and accessibility enforcement have different contracts. Compilation is deterministic, while accessibility policy depends on the frameworks, pages, environments, and risk tolerance of each project. That is an architectural inference, not a claim about Meteor maintainers' intent.

Layer	Appropriate responsibility
Meteor isobuild	Compile and package the application
Framework linting	Detect source and template patterns
Browser auditing	Inspect the rendered DOM with axe-core
Interaction testing	Verify keyboard traversal and focus behavior

Should Meteor expose a standardized hook?

Yes, as an opt-in extension point, but not as a built-in universal accessibility gate. A hook should call a repository-owned command and propagate its exit status. Meteor should not hard-code React, Vue, Blaze, or Svelte rules because those rules and their configuration are application concerns. Until local help or release documentation confirms a supported hook, invoke the accessibility command directly from CI.

How Blaze and React can share a strategy

Keep framework adapters thin while sharing policy and rendered-page tests. React can use JSX lint rules; Blaze needs whatever template linting the project can reliably maintain. Both should feed the same severity mapping, documented exclusions, and waiver process. Run one axe-core audit suite against representative rendered routes, then aggregate failures into a single CI report. This avoids duplicated policy without pretending that static template linting is equivalent across frameworks.

Should axe-core run during hot-module replacement?

Not as the enforcement point. HMR can trigger a debounced, development-only audit after the DOM settles, but transient update state can create noise. More importantly, axe-core does not prove correct focus order. Use deterministic browser tests against a known local server: navigate, wait for the expected UI, run axe-core, and assert a keyboard traversal sequence. CI remains authoritative; an HMR overlay is optional feedback.

Minimal implementation

1. Confirm the installed CLI surface:

   meteor --version
   meteor lint --help
   meteor build --help

2. Define one project-owned accessibility command that runs applicable static linting.
3. Add shared browser audits and focused keyboard tests to CI after a successful build.

This division keeps isobuild deterministic, gives Blaze and React one regression policy, and catches issues that either static linting or axe-core alone would miss.