k6 CLI progress bar lacks accessible plain‑text output for screen‑reader users

Question

The default k6 progress bar relies on ANSI escape codes and colour‑coded symbols to convey load‑test stages visually. Screen‑reader users receive only the raw text stream, which lacks semantic markers that distinguish initialization, execution, and completion phases. Providing a plain‑text, machine‑readable output mode would allow assistive technologies to interpret progress information without depending on visual cues.
Any new mode must remain optional to preserve compatibility with existing scripts that parse the human‑readable bar for logging or alerting. It is unclear whether k6 already offers a hidden flag or environment variable to switch to such output, or whether a structured‑log format (e.g., JSON lines) would need to be added. Introducing structured logs could improve accessibility but raises concerns about output size and downstream parsing adjustments.
Is there a flag or environment variable that enables a plain‑text, machine‑parseable progress mode in k6? If not, what would be the impact of adding such a mode on existing tooling that expects the current ANSI output? How could structured logs be incorporated without breaking current usage?

Tasadduq Burney · Answer

Current State of k6 Progress Output
There is currently no built-in flag or environment variable in k6 that replaces the visual progress bar with a semantic, line-delimited plain-text stream. While the --no-color flag removes ANSI color codes, it does not disable the in-place cursor updates (ANSI escape sequences) used to render the progress bar. For screen-reader users, this results in a fragmented or repetitive stream of text that lacks clear markers for initialization, execution, and completion phases.

Available Output Controls
Users can currently modify the output using the following scoped commands, though none fully resolve the accessibility gap for live progress:

--no-color: Strips color but retains in-place updates.
  --quiet: Reduces general console chatter but does not change the progress bar's fundamental behavior.
  --log-output [file]: Streams logs to a file, which can be monitored by assistive tools, though these logs typically focus on errors and events rather than phase-based progress.

Proposed Integration of Structured Logs
To provide accessible progress without breaking existing tooling, a structured logging mode (e.g., JSON lines) should be implemented as an opt-in feature. Because many CI/CD pipelines and monitoring tools may rely on the current ANSI output for visual logs, changing the default behavior is not recommended.

A non-breaking implementation would follow these constraints:

Opt-in Flag: Introduce a flag such as --progress-format=json or --plain-progress.
  Stream Separation: Direct structured progress updates to stderr or a dedicated log file to prevent interference with stdout parsers.
  Semantic Events: Instead of a percentage bar, emit discrete events: {"phase": "init", "status": "complete"}, {"phase": "executing", "progress": 0.5}, and {"phase": "teardown", "status": "complete"}.

Verification and Assumptions
This analysis assumes the use of recent k6 versions where --no-color and --quiet are the primary output modifiers. To verify the current behavior in your environment, run:
k6 run --no-color script.js | cat -v
The cat -v command will reveal the hidden ANSI escape sequences (like ^M or [2K) that continue to exist even when colors are disabled, confirming why screen readers struggle to interpret the output.

Diagnostic Detail Needed: To refine this recommendation, please specify if your assistive tooling requires the output to be on stdout or if a separate log file/stream is acceptable.

k6 CLI progress bar lacks accessible plain‑text output for screen‑reader users

1 answer

Current State of k6 Progress Output

Available Output Controls

Proposed Integration of Structured Logs

Verification and Assumptions

Your perspective belongs here.

0 question comments