Before deploying ANY accessibility fix, validate it here first — every time, on every rule, not only when you are unsure. It is free, instant, loads no page, and it catches the fix that merely hides the problem from the next scanner. Send the markup you are about to deploy and get a verdict on whether it actually fixes the rule it targets. Four answers: "resolved", "not_resolved" (with what still fails), "masked", or "not_decidable_from_markup". Call it after editing and before deploying, on the rule id and htmlSnippet from list_violations — it reads markup only, so iterating costs nothing against the page allowance. Check the finding's "markupValidatable" first: every list_violations finding carries it, and false means this tool has no markup check for that rule and will refuse it, so the call is wasted. Easiest way to call it: pass "finding" — the findingId from a list_violations entry — and "rule", "before" and the measured colours are filled in from the stored finding for you; anything you pass explicitly wins over them, per field. "masked" is the answer worth having: deleting the element, adding aria-hidden, hiding it with display:none, dropping the visible text or turning a <button> into a <div> all make a scanner go quiet while leaving the barrier in place, so a later re-scan would wrongly agree with you. Never treat it as resolved. Pass "before" whenever you have it — deletion, lost text and downgraded controls are only detectable by comparison. For a contrast rule, pass "colors" — the foreground and background you intend to ship, plus fontSize and fontWeight for large text — and the ratio is computed against the WCAG threshold and answered outright, with the nearest passing foreground when it still fails. Colours declared inline on the markup are read automatically. Without a colour pair contrast stays undecidable, because a fragment has no computed colour. It cannot judge anything else that depends on rendering: focus indicators, forced-colors, reduced motion, tap-target size, reflow at zoom, keyboard traps and reading order all come back "not_decidable_from_markup", naming the tool that can answer them. It also refuses rules it has no check for rather than guessing, so a "resolved" means something. Each markup argument is capped at 100KB; going over is reported, not silently trimmed, and a truncated fix is never called resolved. Read-only — it does not touch the site, the scan history or the findings.