Website accessibility API for rendered pages

The website accessibility API scans a public page in the state users receive. An isolated browser records the rendered result and fetch context, then returns findings your engineering workflow can locate.

For engineering, QA, and platform teams checking release candidates and public pages

Illustrative rendered-page findingIllustrative
Checkout email field has no accessible namecritical · certain
URL
shop.example/checkout
Locator
form#checkout input[type=email]
Observed
accessible_name: empty
Profile
wcag-2.2-aa-web@1.2.0
Render
Full browser with controlled egress
Wait
DOM ready · network ceiling · selector
Evidence
URL · selector · observed state

Describe the page state in the scan request.

Choose a viewport and a bounded wait strategy so the recorded result refers to an intentional rendered state.

Illustrative request
POST/v1/scans
              asset.type = url
asset.viewport = desktop
asset.wait.strategy = selector
asset.wait.selector = main
            

202 Accepted · scan queued

Record the browser state that made a finding true.

Useful evidence includes the rule name and the rendered context a frontend owner can reproduce.

URL

Location

Final URL after redirects

1440

Viewport

Requested render context

main

Wait

Bounded selector strategy

DOM

Locator

Selector plus observed state

Choose the technical profile behind this capability.

The rendered browser evidence stays the same shape while the selected profile defines the WCAG or policy target and its versioned coverage.

Rendered evidence reduces ambiguity, not the need for people.

The browser worker can observe many programmatic conditions. Complete task flows and assistive-technology usability still require deliberate evaluation.

Observed automatically

  • Rendered DOM and accessibility properties
  • Selected color and structural conditions
  • Fetch, redirect, viewport, and wait context
  • Machine-detectable rule outcomes

Reviewed deliberately

  • Full keyboard and screen-reader journeys
  • Meaning and usefulness of content alternatives
  • Authentication and error-recovery flows
  • Usability across the complete service

Test the rendered page your users actually receive.

Start with one public page, inspect the browser evidence, and add the API to a preview or publishing workflow after the result is understood.

Check a website freeCreate an account

Automated preflight is not an accessibility certification or legal determination.