Accessibility in practice
Make an accessibility scan repeatable with a website profile
Connect a website target, portable JSON settings and the effective configuration recorded in your accessibility report.
By A11y Scan editorial team
Published
Updated
Two accessibility reports are difficult to compare when nobody can explain how their settings differed. One may use a different WCAG target, heuristic selection, width or crawl scope. Before interpreting a change in findings, establish what the scanner was actually asked to evaluate.
Start with the site and task
Suppose you are reviewing a shop's checkout. Record the intended origin, the pages in scope and the task. A scan of a product listing does not include every checkout error state, and a crawl does not enter every combination of form values or open every dialog.
Open A11y Scan's free configuration builder and enter the website target. Choose a WCAG version and level, rule selection and a supported mode. The controls produce a versioned JSON configuration shared with the extension. A profile is a declarative recipe for shipped scanner behavior; it is not a place to run arbitrary JavaScript.
Keep the check selection explicit
A WCAG target selects applicable axe tags. Separately enabled heuristic checks can add contextual findings for human review. Record both choices. Selecting a level does not turn every heuristic observation into a proven failure at that level, and a clean report does not establish WCAG conformance.
For a single checkout state, a page scan may be easier to interpret than a broad crawl. For a bounded site review, specify crawl seeds, scope and page limits deliberately. Movie and Crawl cannot currently be combined with multi-viewport scanning; unsupported combinations are rejected rather than silently dropping a mode.
Export, import and check the target
Download the JSON and inspect it before sharing. Import it into the extension on the intended site. Confirm the target matches the active page and review the effective settings before running. A mismatch is a reason to navigate to the intended site or deliberately revise the profile, rather than assume it applies to any open tab.
Exporting from the extension and importing into the website builder provides the reverse path. Keep the file with the report and record the state you opened yourself. The JSON preserves scan settings; it does not replay manual interactions that opened a menu, submitted a form or revealed an error.
Use executed settings as evidence
After the run, export the JSON report. Its provenance records the effective configuration and omitted private fields alongside the page, time and viewport context. Compare that execution evidence with the profile you intended to run. Settings edited after a scan are not evidence of what an earlier run executed.
Retest comparable scope, content state and viewport conditions. Local run comparison helps identify new, persistent and resolved findings, but cannot explain a changed state on its own. Note meaningful differences such as a different account role, expanded navigation or invalid form values.
Review the privacy boundary
Passwords and session credentials do not belong in a public recipe. The extension separates local session secrets from portable configuration and redacts known credential fields from public exports. That does not make every free-text value safe: URLs, custom headers, mock bodies, screenshots and page HTML can contain private information. Inspect files before sharing them.
Retain the profile, relevant report, reproduction steps and limitations together. This makes a defined review repeatable with known settings. Interaction, assistive-technology and content judgments remain necessary, and reproducibility is not a conformance certificate.
Sources and next steps
Build a website-specific JSON profile