Cloudflare Turnstile invisible mode limits for accessible sign-up flows

Cloudflare Turnstile replaces image-based CAPTCHAs with a challenge widget that runs in managed, non-interactive, or invisible mode, embedded via a sitekey and verified server-side against the siteverify endpoint. For a public sign-up form that must pass a WCAG or EN 301 549 review, the mode choice is left to the integrator.

Invisible mode minimizes friction for keyboard and screen-reader users, but it is not guaranteed to be interaction-free for every visitor — an interactive challenge can still appear for some users. A visible widget makes the check explicit but adds an element that must be labeled, announced, and placed in the correct focus order. Tokens add a second constraint: they are single-use and short-lived (commonly cited around 300 seconds), so long or multi-step forms can expire a token before submission, and expiry messaging is the integrator's responsibility.

Before committing to a mode for the accessible workflow:

• Can invisible mode be treated as reliably non-interactive for assistive-technology users, or is an accessible fallback needed for cases where an interactive challenge appears?
• Should multi-step forms include a token-refresh path so slow completions do not fail server-side verification?
• Which mode holds up better in a WCAG or EN 301 549 audit, given that conformance testing of the embedded widget falls on the integrator?