Accessibility ≠ Overlay: when a CAPTCHA blocks access to a website
A CAPTCHA may protect a form against abuse, but it can also become a locked door. Security should work without forcing people to pass tests they cannot perceive or complete.
The problem is the barrier, not security
Selecting traffic lights in pictures, deciphering distorted letters or solving visual puzzles can block blind people. Audio challenges are not universally accessible either: they may exclude deaf users, people with comprehension difficulties, or those in noisy environments.
A barrier at a critical moment
The impact is particularly serious when a CAPTCHA appears during registration, sign-in, appointment booking, contacting an organisation or checkout. If passing the test is the only way forward, some people cannot use the service.
What accessibility guidance says
WCAG does not ban every CAPTCHA. Success criterion 1.1.1 calls for text alternatives identifying its purpose and alternative forms for different sensory modes. Authentication flows also need to consider WCAG 2.2 accessible authentication requirements, depending on the challenge and applicable exceptions.
Alternatives that reduce friction
Prefer security measures that do not require perceptual puzzles: rate limiting, server-side abuse detection, risk-based checks and proportionate verification. When a challenge is unavoidable, provide an alternative that is genuinely accessible and tested, rather than adding an audio button as a token gesture.
Test the whole journey
Verify keyboard operation, screen-reader support and mobile use. Check instructions, focus, error messages, timeouts and retry paths. An accessible alternative that fails when the form is submitted is not an effective solution.
How Blind Reader can help
Blind Reader helps users understand the page, find the form and navigate its fields and actions. It can also correct certain interaction barriers in the browser. These features improve access to the journey, while an inaccessible CAPTCHA still requires the website owner to provide accessible verification. No assistant should be presented as solving every external challenge.
Make it possible to complete the task
A secure, accessible form does not force a choice between protecting a service and making it usable. People should be able to contact, buy or sign in without being stopped by an unnecessary test.
Sources and references
Security and accessibility belong together. A CAPTCHA should never be the reason someone cannot use a website.
Issue 17 · Accessibility ≠ Overlay