Web accessibility
3 checks, run against your own verified domain, reading real WCAG 2.1 A/AA violations directly from axe-core and real cookie behavior directly from a live page load. No provider API and no stored credential is involved in any of them.
webpage-accessibility-scan
Checks a domain's own pages for real, automatically-detectable WCAG 2.1 Level A and AA violations. A headless browser loads each page in an egress-restricted context (only the verified domain itself can ever be reached), runs axe-core against it, and reads the violations directly -- no provider API and no stored credential involved, since these are your own public pages.
- domain
- the domain to scan, proved via a DNS TXT record before any scan can be scheduled. No integration is required.
- pagePaths
- an explicit, bounded list of page paths on that domain (e.g.
/,/pricing) -- this check never crawls a site to discover pages itself, both to keep per-scan compute cost predictable and because scanning pages nobody named is a consent problem this check does not take on.
Reports fail when any violation found is axe-core's own critical or serious impact level, pass only when every listed page loaded successfully with zero violations, and needs-review otherwise -- including when any page failed to load at all, since an unscanned page proves nothing. A pass on this check is never claimed as full WCAG conformance: roughly half of the real WCAG 2.1 A/AA success criteria are structural or semantic issues axe-core can genuinely detect (missing alt text, insufficient color contrast, missing form labels, incorrect ARIA usage); the rest -- captions existing for a video, sensible focus order, legal/financial error-prevention wording -- require a human reviewer no automated scanner can replace. The full, honest breakdown of which of the 50 real criteria this check speaks to is generated per organization on its own VPAT/ACR export, never asserted as a blanket claim here.
webpage-accessibility-flow-scan
Checks a defined multi-step user journey on your own domain (for example open cart, click checkout, fill the shipping form, submit) for WCAG 2.1 A/AA violations that only appear after a specific interaction, not just on a page's initial load. A headless browser drives one persistent page through the journey's own explicit, bounded step list (click, type, or navigate), and axe-core re-scans the elements a realMutationObserver saw change after each step.
- domain
- the domain to scan, proved via the same DNS TXT record as the base scan.
- flow
- the journey's own recorded step list, configured once per check from the dashboard. No integration is required.
The very first step, and every fifth step after it, also gets a full, unscoped scan as a safety net, since a state change made with CSS alone (for example a hover or focus style) never touches the DOM and would otherwise go unseen between full scans. Reports fail on any critical or serious violation, matching the base scan's own thresholds.
webpage-cookie-consent-scan
Checks a domain's homepage against Article 5(3) of the EU ePrivacy Directive: no non-essential cookie is set, and a consent mechanism is present, before any consent action is taken. A headless browser loads the page once, takes no action of any kind, and reads every cookie the browser context holds, plus whether a known consent-management platform or a visible, pinned consent banner is present.
- domain
- the domain to scan, verified through the same DNS TXT record ownership proof as the base accessibility scan. No integration is required.
A cookie matching a named analytics or advertising vendor is a confirmed fail, regardless of whether a banner is also shown. An unrecognized persistent cookie is needs-review, never a guessed fail. With no non-essential cookie found, the check passes only when a consent banner or platform was also detected. No consent action is ever performed, so nothing is claimed about what happens after a visitor accepts or declines.