Mocha spec reporter accessibility: missing plain‑text mode for screen‑reader users

Question

Goal: enable screen‑reader users to perceive the hierarchical structure and results of Mocha test runs without relying on color codes or visual symbols.

Constraint/uncertainty: the built‑in spec reporter currently emits ANSI‑wrapped strings and Unicode check/mark characters. There is no plain‑text or JSON mode that includes descriptive labels, and the project has not decided whether to add a dedicated --reporter accessible option or to modify the spec reporter to output ARIA‑like semantics when --color=false is combined with an accessibility switch.

Should Mocha introduce an --reporter accessible reporter that outputs indented plain text with labels such as “pass” and “fail”? Alternatively, should the spec reporter be altered to emit ARIA‑like semantics when color is disabled and an accessibility flag is present? What impact would either approach have on existing scripts and tooling that consume Mocha’s output?

Tasadduq Burney · Answer

Recommendation
Add a new --reporter accessible that emits indented plain‑text with explicit labels (e.g., PASS, FAIL) rather than extending the existing spec reporter with an accessibility flag.

Why a New Reporter Is Safer

Separation of concerns – The spec reporter remains the default visual output; a dedicated reporter can be optimized for screen‑reader consumption without risking regressions for existing users.
No parsing breakage – Many CI/CD pipelines and custom tools parse the spec reporter’s current ANSI‑wrapped lines with regular expressions. Changing that format—even behind a flag—would break those scripts.
Clear maintenance boundary – A single reporter class for accessibility is easier to test (e.g., with NVDA/VoiceOver) and to evolve independently of the spec reporter’s visual features.

Impact on Existing Scripts and Tooling

ApproachRisk to Existing ParsersMaintenance Overhead

New accessible reporterZero – existing scripts continue to use spec unchangedOne additional reporter class; minimal
Flag on spec reporter (--color=false --accessible)High – any regex that expects Unicode checkmarks or ANSI codes will failSpec reporter must handle two output modes, increasing complexity

Verification Steps

Run current output without color to confirm the lack of descriptive labels:
mocha --reporter spec --color=false > spec-output.txt
cat spec-output.txt
Implement a prototype accessible reporter (or use a community fork) and capture its output:
mocha --reporter accessible > accessible-output.txt
cat accessible-output.txt
Test the plain‑text output with a screen reader (NVDA on Windows, VoiceOver on macOS) to verify that hierarchy (indentation) and labels are announced correctly.
Run your CI pipeline with both reporters to ensure no existing parsing step fails.

Open Question
Do you have any CI/CD jobs or custom tooling that currently parse the spec reporter’s output? If the answer is yes, the dedicated reporter is the only safe path. If no, a flag‑based modification could be considered, but the maintenance cost still favors a separate reporter.

Mocha spec reporter accessibility: missing plain‑text mode for screen‑reader users

1 answer

Recommendation

Why a New Reporter Is Safer

Impact on Existing Scripts and Tooling

Verification Steps

Open Question

Your perspective belongs here.

0 question comments

Approach	Risk to Existing Parsers	Maintenance Overhead
New `accessible` reporter	Zero – existing scripts continue to use `spec` unchanged	One additional reporter class; minimal
Flag on spec reporter (`--color=false --accessible`)	High – any regex that expects Unicode checkmarks or ANSI codes will fail	Spec reporter must handle two output modes, increasing complexity