cypress-axe Test Runner Reporting Lacks Structured Violation Details

Context

Cypress delegates accessibility auditing to the cypress-axe plugin, which wraps axe-core. The standard workflow requires calling cy.injectAxe() once per test context before invoking cy.checkA11y() against the current DOM state. While the command executes and surfaces violations, the Test Runner presents them as generic assertion failures rather than structured, filterable reports.

Constraints

• Accessibility testing is not part of the core Cypress installation; it depends on a community-maintained plugin.
• Large DOM trees cause noticeable performance degradation during cy.checkA11y() execution.
• Only programmatic WCAG violations are detected; logical flow and screen-reader behavior require manual verification.

Open Questions

1. Is there a supported pattern to transform the raw axe-core results into a structured Cypress custom command that surfaces rule IDs, impact levels, and affected nodes in the command log?
2. Can the plugin’s terminal or verbose options be configured globally to avoid per-call boilerplate while preserving detailed output?
3. Are there plans to integrate a native accessibility reporting interface in Cypress that would supersede the current plugin-dependent approach?