Use this when the ask is to fix, remediate, prioritise or cost accessibility, a11y, WCAG or ADA failures on a site — 'what is broken', 'where in our code is it', 'give me a remediation plan'. It is the free, no-page-load record of what the static scanner found, and the place remediation starts; it is not the whole audit, and what it cannot see is named at the end. The fix list for a website, from its current scan only — not its whole history. One entry per axe rule, worst impact first, not one entry per page: a rule is listed once with "totalElements" (how many elements across the site fail it) and "pages" (each failing page with its own element count). Grouping is by rule rather than by selector because axe writes a different selector for the same element on every page — the same button can be "button[data-product-id=13914]" on one page and ".add-to-wishlist-button" on the next — so selectors cannot identify a shared component. Each entry carries what you need to act: impact, rule id, WCAG criterion, the help text and its documentation URL, and — from ONE example page, named in "examplePage" — the failing HTML, that page's selectors, the computed foreground/background/ratio for a contrast failure, and the AI's suggested fix where one was generated and is trustworthy. For a contrast failure, "contrastData.minimumPassing" is the nearest colour that clears the threshold, with the ratio it achieves — derived arithmetically from the measured colours, so prefer it over any suggested hex. Where a suggestion is held back, "suggestionWithheld" says why rather than leaving the field silently empty. Each entry also carries "grepFor": strings taken from the failing elements across every affected page — ids, distinctive non-utility classes, visible text, image filenames — that are likely to appear verbatim in your source, most widespread first. Search your own codebase for those to find the template. "grepTargets" is the same list tagged with what each string is and how much weight it carries: a "strong" target is content-derived or a distinctive authored name, a "weak" one is a generic class kept only because the element offered nothing better. "nextStep" is built from strong targets alone, and when only weak ones exist it says so instead of naming one — a one-word class can be produced at render time or held in a CMS or configuration value, so it is corroboration and not a location. The CSS selectors describe the rendered DOM and appear in no source file; they are capped at 3 per entry because ten selectors differing only by a product id carry one bit of information. A rule failing on many pages is usually one shared component, but this tool does not claim to know that: it gives you the pages and the example markup so you can check before fixing page by page. What it does give you is an estimate — "distinctCauses", with the shapes themselves in "causes" — computed by normalising each element's selector (attribute values and :nth-child indices removed) and counting the distinct shapes, so 88 failing buttons that differ only by product id come back as roughly one cause. Treat it as an UPPER BOUND on the number of templates and not a measurement: two shapes can be one component that axe named differently on two pages, and one shape can be two components that render alike. Every entry in "causes" carries its OWN evidence — examplePage, htmlSnippet, findingId and, on contrast rules, contrastData with its own minimumPassing — because the rule-level example fields describe one cause and the others routinely differ: a six-cause contrast failure is usually not six instances of one colour. Fix and validate each cause, not the majority one. "totalDistinctCauses" sums them over the entries returned, which is the number that sizes the work; totalElements sizes the symptom. Use it to decide what to fix and where; then validate_fix on the markup you write, before deploying. Each entry says in advance whether that will work: "markupValidatable" false means validate_fix has no markup check for the rule and will refuse it, and "confirmWith" names the check that CAN confirm the fix once it is live — for a keyboard or focus rule that is keyboard_walk, not a rescan, which is the substitution to avoid. "scan" says which run these findings come from and how much of the site it covers: its date, the pages it scanned, and how many pages are monitored against the plan's allowance. Not the tool for alt-text quality (list_alt_findings covers the AI pass) and not the tool for anything only visible in a render — keyboard behaviour, focus visibility, zoom reflow, tap-target size, forced colours and reading order come from keyboard_walk, simulate_condition and screen_reader_transcript, and reading this has run none of them. Reads stored scan results, so it loads no pages and costs nothing against the monthly page allowance. Read-only.