Skip to main content

Issues & Accessibility Scanning

Beyond a simple pass/fail per step, every run produces a list of issues: plain-English findings meant to read like something a thorough human tester would write up, each tagged with a category and a severity. This list appears on both the private run detail page and the public shareable report, in an "Issues found" section, and is counted in the summary stats at the top of the report (Steps / Passed / Failed / Issues found).

There are four issue categories, generated by three different mechanisms.

Failed steps (category: bug)

Every step that fails generates a bug issue at high severity automatically, with a summary in the form:

Step 3 (click) failed: on my credit balance in the top nav

and a detail line with the exact underlying error (almost always could not find an element matching "..."; see Step Types & AI Resolution for why a step fails to resolve). This is a direct, mechanical translation of a failed step into an issue. There's no additional judgment call being made here beyond "this step didn't succeed."

Console errors (category: bug)

If the browser's JavaScript console logged any errors at all during the run (across every step, combined), a single bug issue at medium severity is added summarizing the count:

3 browser console error(s) logged during the test

This is a count, not a full dump of each individual error's message and stack trace on the report page itself. It exists to flag that something threw client-side, prompting you to open your browser's own devtools console against the same flow if you need the specific error text and stack trace.

Slow steps (category: usability)

Any step whose execution took longer than 3 seconds is flagged as a usability issue at medium severity:

Step 4 (the checkout button) took 4.2s. Slow interactions like this
frustrate users on mobile or a weak connection.

wait steps are deliberately excluded from this check. A wait step's duration is intentional (you asked it to pause), not a symptom of the page being slow, so it would be misleading to flag it as a usability problem.

Accessibility scan (category: a11y)

At the very end of a successful run (specifically, only if at least one navigate step actually succeeded during the run; a run that never successfully loaded the target page at all skips this step, since there's no page state left to scan), VeriWasp injects axe-core, the same open-source accessibility testing engine used by many commercial and open tools, into the page and runs a full WCAG scan against whatever page the browser was on when the run finished.

Each violation axe-core reports becomes one a11y issue, with:

  • A summary in the form <rule description> (<N> elements), for example "Elements must meet minimum color contrast ratio thresholds (11 elements)."

  • A detail line with axe-core's fuller description of the rule being violated.

  • A severity derived from axe-core's own impact rating for that violation:

    axe-core impactVeriWasp severity
    critical or serioushigh
    moderatemedium
    minor (or anything else)low

Because this scan only runs against the page state at the end of the run, it reflects whatever page your last step left the browser on. If your scenario ends on a confirmation page, that's what gets scanned, not the homepage or any intermediate page visited earlier in the run. If you specifically want accessibility findings for a particular page, make sure your scenario's last step (or an assert immediately before the end) leaves the browser there.

Reading severities

Severities (high, medium, low) are rendered with color-coded badges wherever issues are listed:

  • High: red badge. Failed steps and serious/critical accessibility violations.
  • Medium: amber badge. Console errors and slow steps, plus moderate accessibility violations.
  • Low (and anything else): neutral badge. Minor accessibility findings.

There's no numeric score or overall grade computed from these. The report's top-line stats are simple counts (total steps, passed, failed, and total issues found across all four categories combined), and the issue list itself is where the actual substance lives.