Accessibility
Meticulous runs an accessibility scan at every screenshot it compares 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.

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 made informational only: every new violation is then reported as a warning and the accessibility status check never fails, so you can see what it finds without blocking any pull request.
By default, a violation is treated as pre-existing if it appears in any session's base replay in the base run (not only the same session's). That avoids reporting long-standing issues as new when a head replay reaches a screen its own base replay did not. You can turn this off in project settings to require a same-session match.
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 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), and issues introduced by third-party components or injected markup. 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.