Start with clear language
Describe why a step is needed, what it asks the person to do, and what will happen next. Avoid making users guess what a spinner or icon means.
Use a brief headline and plain-language supporting instructions.
Support more than one input mode
Pointer-only interactions, timed gestures, and low-contrast puzzles can exclude users. Evaluate keyboard, touch, screen readers, low-vision modes, and reduced motion.
Complete the flow using only a keyboard and a screen reader.
Design for interruptions
People may lose connectivity, switch devices, or need extra time. Explain expiry and offer a safe retry rather than silently restarting an entire workflow.
State whether restarting changes an underlying operation or only the verification attempt.
Avoid shame-based failure copy
Messages such as “You are not human” are harmful and often inaccurate. Describe the actual technical outcome instead: “We could not complete this check.”
Provide a concrete retry or support action with the message.
Measure real exclusion
Track completion time, abandonment, error categories, and support requests with minimal personal data. Listen to users who are affected by the flow.
Test across assistive technologies before promoting the flow as accessible.
Accessibility must be part of the threat model
Security reviews often focus on attackers and forget that an inaccessible system denies service to legitimate people. A method that requires precise motor input, rapid visual recognition, or sound without an equivalent alternative will produce failures unrelated to malicious behavior. Those failures can be misread as evidence of automation, making the system less accurate as well as less inclusive.
Bring accessibility specialists and affected users into design reviews early. Test the experience at high zoom, with system color preferences, with screen readers, and with keyboard-only navigation. Make interactive targets large enough to use reliably on touchscreens. If the product depends on a verification vendor, inspect the vendor's methods and support paths rather than assuming an accessibility statement guarantees a usable end-to-end workflow.
Include a user who cannot complete the default visual method in your threat-model scenarios and define the safe alternative.
A good failure message gives agency back
Imagine someone being told “You failed the human test” after a network interruption. The wording is inaccurate, insulting, and does not help the person recover. A better message distinguishes what happened: “This check expired before we received a result,” or “We couldn't complete the connection. Please try again.” For repeated failures, provide a different path rather than an endless loop.
A strong error state answers three questions: what happened, whether the underlying action was completed, and what the user can do next. The last point matters in agent workflows where a request might still be pending. If the system is unsure whether an operation was executed, it should not imply success or ask for blind repeated approval. Clear status and safe recovery are accessibility features as well as engineering safeguards.
Rewrite error messages so they describe technical outcomes and provide an explicit next step without blaming the person.
Test the journey beyond the challenge
The complete experience begins before the verification screen and ends after the relying application handles the result. A keyboard-accessible challenge still fails users if the parent application never returns focus to the approval dialog. A screen reader may lose context if the result changes silently. A reduced-motion preference matters only if animations can be slowed or removed without hiding instructions.
Document focus placement, announcement of state changes, error descriptions, navigation away and back, time extensions, and fallback methods. Test with real browsers and assistive technologies in addition to automated checkers. Track completion and abandonment without turning accessibility analytics into invasive user profiling. Design for the person completing the full task, not just the component receiving the verification input.
Trace focus and status announcements from the initial request through success, failure, retry, and return to the relying application.
Turn the idea into a practice.
Use the companion activity to apply this topic to a real workflow or design problem.
Open the matching activity