ADA Compliance for Ecommerce Checkout: What Overlays Miss and How to Gather Evidence

The pages where a customer enters payment details are the same pages that appear most often in ADA demand letters aimed at ecommerce businesses. The pattern is not accidental. Checkout flows are built by multiple teams across multiple sprints, revised constantly, and tend to carry form controls — inputs, selects, error messages, confirmation dialogs — that interact poorly with keyboard navigation and screen readers. An accessibility overlay installed at the site level rarely changes how those controls behave at the actual point of purchase.

Why checkout pages attract the most demand letters#

When a plaintiff's firm evaluates an ecommerce site, the checkout flow receives the closest scrutiny because it is where the transactional relationship is established. A sighted user can click a payment button. A keyboard-only user who cannot reach that button cannot purchase at all. That is the definition of discriminatory access under ADA Title III as courts have applied it to online retail: if the core service — buying something — is unavailable to a user with a disability, the accommodation argument fails regardless of what toolbar widget is installed on the homepage.

Checkout pages are also the pages most stores update most frequently — new shipping tiers, promotional code fields, guest-versus-account flows, loyalty point integrations, payment provider swaps. Each of those changes is a potential accessibility regression, introduced by an engineer who was not thinking about keyboard navigation, in a part of the site that carries the most legal exposure.

Keyboard access through the checkout funnel#

WCAG 2.1 Success Criterion 2.1.1 requires that all functionality be operable through a keyboard interface. For a checkout flow, that means a user must be able to tab into every field in the cart summary, the shipping address form, the payment card entry, and the order confirmation step — and activate every button — without a mouse. The rule is straightforward; the implementation is not.

Cart pages often include quantity adjusters, remove-item buttons, and apply-coupon fields built as custom elements with no keyboard event handlers. Shipping calculators add dynamic regions that shift focus unpredictably after an async update. Payment iframes from third-party processors sometimes trap focus entirely, leaving a keyboard user unable to exit. An overlay that injects a toolbar advertising "keyboard navigation enhancements" rarely repairs these per-component failures because they live inside the application logic, not in the static HTML the overlay inspects at load time.

• Quantity controls built as styled divs with no role attribute or keydown handler
• Apply-coupon buttons that respond only to mouse click, not keyboard activation
• Address-validation and card-error modals that do not move focus to the dialog on open
• Custom state and country dropdowns that respond to click but not arrow keys
• Multi-step shipping radio groups where only the first option receives keyboard focus
• Order confirmation pages that land focus at the top of the document instead of the confirmation heading

Form labels, error messages, and the payment step#

WCAG 1.3.1 and 3.3.2 require that form inputs have programmatically determinable labels. WCAG 3.3.1 requires that errors be identified in text. Payment forms frequently fail both. Placeholder text is not a label: when a user begins typing in a card number field, the placeholder disappears and the field becomes anonymous to a screen reader. Error messages rendered as red helper text beneath a field are often not associated with the control via aria-describedby, so a screen reader user who navigates back to fix a validation error has no way to know the error message is there.

These are not cosmetic issues. A checkout form where a screen reader user cannot reliably understand what each field expects — or learn which field caused a payment decline — is a checkout form they cannot complete. The accessible checkout flow requirement is not satisfied by adding a toolbar; it requires that every label, every error, and every success state be programmatically surfaced to assistive technology.

What an overlay actually changes at checkout#

OverlayRiskWitness loads the checkout page twice in a real browser. The first pass blocks the overlay script at the network layer so axe-core evaluates the unmodified application. The second pass allows the overlay — accessiBe, UserWay, or whichever vendor is installed — to inject its runtime changes; axe-core runs again on the result. The per-rule diff shows exactly what moved between the two states.

In practice, overlays tend to improve color-contrast scores on static text — areas where they can override CSS — while leaving structural violations in place. keyboard-trap failures, missing form labels on dynamic inputs, and focus-order problems in multi-step flows typically produce the same axe-core violation counts with the overlay on as with it off. The diff does not claim to know why; it records what changed and what did not.

Each rule's outcome is recorded as a finding state. Held up means the overlay made no net difference to a passing rule. Did not hold up means the rule was still failing after the overlay had its chance to fix it. Not testable means the rule could not be evaluated in that pass — a common result for rules that require human judgment or that depend on page state a headless browser cannot reliably reach. All three states are observations about what the engine saw, not legal conclusions.

Teams turning this into a repeatable review can pair checkout testing with the WCAG 2.2 AA checklist for sites running an accessibility overlay. It separates the criteria a two-pass witness can verify from the manual keyboard, focus, and form checks checkout flows still need.

Checkout accessibility drifts after every deploy#

A site that passes a witness run in May is not guaranteed to pass one in August. Ecommerce checkout flows are updated continuously — new payment providers, A/B tests on the shipping step, seasonal promotional banners, cart redesigns. Each deploy introduces the possibility of an accessibility regression. The overlay does not update with the application; it runs on its own versioned script regardless of what changed underneath.

Drift monitoring re-runs the same witness on a fixed schedule and diffs each run against the prior baseline. When a finding state changes — a rule that held up now does not — the change is flagged with the exhibit attached. The practical value is in catching the silent failure: a deploy that breaks keyboard access to the card entry field while the site's accessibility statement still promises full keyboard support.

Gathering timestamped evidence on your checkout pages#

The free witness at overlayrisk.com covers one public URL and surfaces one finding — enough to confirm the tool is detecting your overlay, running real axe-core passes, and producing a diff. A Risk Packet at $49 covers 5 to 10 pages and is the right scope for a complete checkout funnel: cart, guest-checkout entry, shipping address, payment, and confirmation. Each page gets its own exhibit with a timestamp, the overlay vendor detected, the per-rule diff, and the finding states across both passes.

If checkout pages are being updated regularly, Drift Monitor at $99 per month re-runs up to 20 pages on a schedule and sends a notification when a finding state changes. Agency Watch at $249 per month extends that to parallel monitoring across multiple client sites — useful for agencies that manage accessibility compliance for ecommerce retailers and need a continuous evidence record for each account.

The evidence OverlayRiskWitness captures is a record of what the axe-core engine observed on those pages at that timestamp. It is not a legal opinion and not a compliance certificate. Whether a gap between a public accessibility claim and a live finding is actionable is a determination for counsel. The value of having the evidence in hand is that the conversation can happen on specific facts — this rule, this page, this date — rather than on a vendor's general claim that their script makes the site compliant.