Which accessibility checks belong in a headless commerce release gate?

A headless commerce release gate should combine fast automated checks with keyboard, focus, form-error, and screen-reader tests on the customer journeys changed by the release.

Gate the shared components first

Run automated rules against navigation, dialogs, product cards, selectors, carts, forms, and other reusable components. A failure in a shared component can affect many routes, so block the release until the component passes.

Exercise changed journeys

Test the routes touched by the release from entry to completion. Verify logical focus order, visible focus, dialog focus management, accessible names, status announcements, and error recovery with the same APIs and feature flags used in production.

Keep a manual backstop

Automated tools cannot judge every interaction or the quality of alternative text and instructions. Define a short manual checklist for keyboard and screen-reader use, and save the result with the release evidence.