Check a fix before deploying it
validate_fixBefore 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 into a 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.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| rule | No | The rule the fix targets — the "ruleId" from a list_violations finding, e.g. "image-alt", "button-name", "label", "aria-hidden-focus", "tabindex". Required unless you pass "finding", which carries it: the same markup passes one rule and fails another, so there is no useful answer without it. | |
| after | Yes | The markup you intend to deploy, with your change applied. | |
| before | No | The original markup, normally the finding's htmlSnippet verbatim — or supplied by "finding". Optional but worth having: without it only absolute masking signals (aria-hidden, hidden, display:none) can be detected, and deletion, removed text and downgraded controls cannot. | |
| colors | No | For contrast rules only: the colour pair the fix proposes. With both colours the verdict is closed-form arithmetic rather than a refusal. Pass only the colour you are changing when you also pass "finding" — the rest comes from the measurement. | |
| finding | No | The "findingId" of a list_violations entry, e.g. "clx9f2k4b0001". Pass it and the rule, the original markup and — on a contrast rule — the measured foreground, background, font size and weight are read from the stored finding, so nothing has to be transcribed. Only findings on this website resolve. Anything you also pass explicitly wins over the stored value, field by field. | |
| website | Yes | The website domain as registered in Inclusify, e.g. "example.com". |