Accessibility

Meticulous runs an accessibility scan on every screenshot taken during replay of your application, then reports the new accessibility regressions introduced by the change under test. Pre-existing issues never fail the check; only freshly introduced violations are surfaced.

The accessibility check in the Meticulous UI: a failed check reporting new violations, each with its rule, severity, the failing element, fix guidance, and links to the sessions where it was seen

Verdicts and CI

By default, new critical and serious violations mark the Meticulous accessibility status check as failed on the pull request and require a reviewer to acknowledge them in Meticulous, while moderate and minor ones are reported as warnings that leave the check passing. The check can also be configured so that every new violation is reported as a warning only, so the accessibility status check never fails.

Why this complements static analysis

Static analyzers and linters inspect your source code, so they only see accessibility issues that are visible in the markup you wrote. Meticulous scans the actual rendered DOM at every screenshot as it replays real user flows, so it catches problems that only exist at runtime: dynamically rendered content, state that appears after interaction (modals, menus, expanded panels), issues introduced by third-party components or injected markup, and colour-contrast failures that depend on the computed styles a browser actually applies. Because it works from real sessions rather than source code, it surfaces regressions in the states your users actually reach — a layer of coverage a source-only tool cannot provide.