Is a CAPTCHA a problem for accessibility of my site?

A CAPTCHA can exclude screen reader and keyboard users

Yes, a CAPTCHA is often a real problem, and for a very practical reason: most CAPTCHAs are built for the eye. Typing in distorted text, clicking on pictures of traffic signs, or solving a sliding puzzle — all of these require being able to see what is happening on the screen and being able to drag or click with a mouse. For a customer using a screen reader, that distorted text is invisible or unusable, and for someone using only the keyboard, a puzzle designed for dragging is often simply impossible to complete. The CAPTCHA sits precisely where things go wrong: when finalizing an order or submitting a contact form.

This does not mean that every CAPTCHA is necessarily inaccessible. There are variants with an audio alternative, a logical puzzle in text, or checks that run in the background without the customer having to do anything. Whether a CAPTCHA is a bottleneck depends on which variant is used and whether a usable alternative is available alongside it. This touches on a broader pattern: just as with the checkout process for a customer using a screen reader the problem often lies not on the main page but in a small component along the way that gets overlooked, and the same applies to keyboard operation of the entire checkout — a CAPTCHA that cannot be controlled with tab and enter blocks the entire flow even though the rest of the site is working properly.

Where this appears in WCAG

WCAG 2.1 sets requirements for precisely this type of component: content must be perceivable to those who cannot see, and operable to those who cannot use a mouse. A CAPTCHA that can only be controlled via a visual image and offers no alternative conflicts with these principles. An automated scan can signal that there is a CAPTCHA on a page, but cannot always assess whether the chosen type is truly usable for a screen reader — this is exactly the kind of assessment where an automated test reaches its limits.