Understanding Reports
Conalyz Runtime generates two report files at the end of every session.
HTML Report
conalyz_report.html is a self-contained visual report that opens in any browser — no server required.
What it contains
- Device information — model, screen resolution, pixel density
- Per-screen summary — violation counts by check type for each screen
- Violation details — every violation with:
- The check that failed and its severity
- The accessible label of the affected element
- The element's position and size on screen
- The specific reason it failed (e.g. contrast ratio, exact dimensions)
- Screenshot with highlights — click any violation row to open a modal with the screenshot and a red highlight over the exact element. In automated mode with scrollable screens, the modal shows the screenshot from the scroll pass where that violation was found — so elements that only appear after scrolling are shown in their actual visible position, not on a blank area of the initial screenshot
- Full-size screen preview — click a screen's preview thumbnail itself (not a specific violation) to open a plain, full-size view of that screenshot, with the vision simulation controls below available right there too
Colour vision simulation
Every screenshot in the report can be viewed through a colour vision deficiency (CVD) simulation. A Colour vision toggle — Normal, Deuteranopia, Protanopia, Tritanopia — appears in the report header. Switching modes re-renders every screenshot, sidebar preview and detail/preview modal included, as it would appear to a user with that form of colour vision deficiency.
This is useful for catching reliance on colour alone to convey information — for example an error state shown only as red text, or a chart that distinguishes data series only by hue — a WCAG 1.4.1 (Use of Color) concern that automated contrast checks alone don't catch.
Low-vision blur
Alongside the colour toggle, a Blur — low vision control — Sharp, Mild, Moderate, Severe — softens every screenshot to simulate reduced visual acuity (cataracts, aging eyes). It combines with the colour vision toggle, so you can view a screen as a user with both conditions would.
Use it to test visual hierarchy: if the primary action can't be located when the screen is blurred, the design is relying too heavily on fine detail or weak contrast to stand out.
Screen reader simulation
Each analysed screen includes a Screen Reader Transcript panel showing the sequence of announcements TalkBack (Android) or VoiceOver (iOS) would make while swiping through that screen — label, role, state, and the secondary hint (e.g. "double tap to activate").
A play button per screen steps through every announcement automatically, synced to a screenshot with a focus ring showing which element is being read, and speaks each announcement aloud using the browser's built-in text-to-speech — no plugins or device connection required. For scrollable screens, the simulation continues through every scroll position the screen covers, not just what's visible without scrolling. Click any row in the transcript to hear just that one announcement in isolation.
This is a simulation derived from the same accessibility tree Conalyz analyses, not a recording from a real device — exact wording can vary by OS version and device. Use it to catch likely problems (unlabelled elements, confusing reading order, missing context) before confirming with a real screen reader on a real device.
Severity levels
| Severity | Meaning |
|---|---|
| Critical | Blocks access entirely for some users |
| High | Significantly impairs usability for some users |
| Medium | Causes friction; workarounds may exist |
| Low | Best-practice violation; minor impact |
JSON Report
conalyz_report.json contains the same data in a structured format, suitable for:
- CI pipeline integration (fail the build if violations exceed a threshold)
- Custom dashboards and tooling
- Tracking violations over time
Top-level structure
{
"generatedAt": "2026-05-25T10:30:00.000Z",
"device": {
"model": "sdk_gphone16k_arm64",
"densityDpi": 480,
"pixelRatio": 2.625,
"physicalWidth": 1080,
"physicalHeight": 2400,
"logicalWidthDp": 411,
"logicalHeightDp": 914
},
"screens": [
{
"name": "Login",
"totalViolations": 4,
"screenshotCount": 1,
"violations": {
"touchTargets": [],
"contrast": [...],
"focus": [...],
"labels": [],
"vagueLabels": [],
"disabled": [],
"sliders": []
}
}
]
}
screenshotCount reflects how many screenshots were captured for that screen. Most screens have screenshotCount: 1. Screens with long scrollable content captured in --auto mode may have more — one screenshot per scroll position.
Controlling report output
Use CLI flags to control which reports are generated and where they are saved:
# Write both reports to a specific directory
conalyz auto --output ./reports
# JSON only
conalyz auto --no-html
# HTML only
conalyz auto --no-json
See the CLI Reference for the full list of flags.