Spam bots found your contact form, so someone added a CAPTCHA. The spam slowed down. What nobody noticed is that a few real customers stopped getting through as well: the blind visitor who could not see the traffic lights, the older customer who failed the wavy letters three times, the person with a hand tremor who could not drag the puzzle piece into place.
CAPTCHA accessibility is a real problem because the whole point of a CAPTCHA is to set a test that some visitors cannot pass. The trick is to make sure the visitors who fail are bots, not people. This post explains why the common puzzles block people, what WCAG says, and the accessible CAPTCHA alternatives that work on WordPress forms, logins and checkouts.
Why the usual puzzles shut people out
Each type of challenge fails a different group:
| Challenge | Who it blocks |
|---|---|
| Distorted text in an image | Blind and low-vision users, people with dyslexia, anyone using a screen magnifier on a blurry image |
| “Select all images with buses” | Blind users entirely; also people with low vision, cognitive disabilities, or anyone unsure whether the edge of a bus counts |
| Audio alternative | Deaf-blind users, people with hearing loss, anyone in a noisy place; the audio is often deliberately hard to understand |
| Drag the slider or puzzle piece | Keyboard users, switch users, people with tremors or limited movement, voice control users |
| Math question (“What is 7 + 4?”) | Some people with dyscalculia or memory difficulties; less of a barrier than the others, but still a test |
| Timed challenge | Anyone who reads, types or moves slowly, including many screen reader users |
A challenge that offers both an image and an audio version is better than an image alone, but it still leaves out deaf-blind users, and both versions are designed to be hard.
What WCAG says about CAPTCHAs
WCAG does not ban CAPTCHAs outright, but several criteria apply.
- 1.1.1 Non-text Content. A CAPTCHA is one of the listed exceptions, on conditions: there must be a text alternative that says what it is for, and there must be alternative forms that use different senses, so it does not rely on sight alone.
- 3.3.8 Accessible Authentication (Minimum), new in WCAG 2.2 at Level AA. Where a login or sign-up step asks people to solve, recall or transcribe something (a “cognitive function test”), there has to be another way through or a mechanism that helps. The AA version allows tests that ask people to recognize objects or to pick out content they supplied themselves. That means a “pick the buses” puzzle can technically meet this criterion while still blocking a blind visitor, which is why the image-only versions still fail on other grounds.
- 2.5.7 Dragging Movements, also new in 2.2. Anything you drag must also work with a single tap or click. Slider puzzles often have no such option.
- 2.1.1 Keyboard. The challenge, its refresh button and its audio button must all be usable from a keyboard.
The W3C has also written a separate note on the inaccessibility of CAPTCHA, and its Web Accessibility Initiative publishes the plain-language guidance around WCAG. The short version: the best CAPTCHA is one that people never see.
Accessible CAPTCHA alternatives that stop most form spam
A lot of the spam a small business site gets comes from crude scripts that stuff text into each box on the page and post it straight away. You can stop a large share of them without asking humans to prove anything.
Honeypot fields
A honeypot is an extra field that people never see but bots fill in. If it comes back with something in it, the submission is thrown away. Many WordPress form plugins include a honeypot option, and some turn it on by default.
Built carelessly, a honeypot can trip up assistive technology users. If the field is only moved off-screen with CSS, a screen reader may still reach it and a keyboard user may Tab into it. Hide it properly from everyone, and give it a label that tells anyone who does reach it what to do:
<div hidden>
<label for="website-url">Leave this field empty</label>
<input id="website-url" name="website-url" tabindex="-1" autocomplete="off">
</div>The hidden attribute removes it from the screen, the Tab order and the screen reader. The label is a fallback in case your theme’s styles override that.
Time-based checks
Bots tend to submit a form in a fraction of a second. A check that rejects anything submitted almost instantly catches many of them. Keep the threshold short, a few seconds at most, so that people using autofill or a password manager are not rejected for being quick.
Server-side spam filtering
Filtering services look at the content of a submission (links, known spam phrases, sending address reputation) after it is sent and quietly mark spam. In WordPress, Akismet is the best known and works with comments and several form plugins. The visitor sees nothing. The tradeoff is the occasional real message filed as spam, so check the spam folder now and then.
Invisible and score-based checks
Services such as Google reCAPTCHA v3 and Cloudflare Turnstile usually run in the background and decide whether a visitor looks human without showing a puzzle. For most people they are invisible, which is a big step up from an image grid. Two cautions:
- Some of these fall back to a visible challenge when they are unsure. Find out what that fallback is and test it with a keyboard and screen reader.
- They send visitor data to a third party. That is a privacy question for your policy, not an accessibility one, but worth knowing.
The older reCAPTCHA “I’m not a robot” checkbox sits in between: often a single click, but sometimes it escalates to an image challenge, which brings back every problem in the table above.
Rate limits and confirmation emails
For account sign-up and login, limiting the number of attempts from one address and confirming new accounts by email stop a lot of abuse without a puzzle. For checkout, payment providers have their own fraud checks that run without asking the shopper to do anything.
For the spam-fighting side of these layers, see our post on cutting contact form spam. Here the rule is simply to use the invisible layers first and a visible challenge last, if at all.
Where CAPTCHAs show up on a WordPress site
CAPTCHA accessibility problems turn up in four places on a typical WordPress site, and each has a different fix:
- Contact and quote forms. Usually a honeypot plus a spam filter is enough. Our post on accessible contact form plugins covers the rest of the form.
- Login pages. Security plugins sometimes add a CAPTCHA to the login screen. This is exactly where 3.3.8 applies. Prefer attempt limits and two-factor options that allow pasting codes or using a password manager.
- Comment forms. A spam filter usually does the job without a puzzle.
- Store checkout and registration. A CAPTCHA at the last step of a purchase is a hard stop for some shoppers. If card testing attacks are the reason, look at what your payment provider and security setup offer first; our post on WooCommerce store security covers protecting checkout more broadly.
If you must keep a visible challenge
Sometimes a visible check stays, perhaps because a vendor requires it. Then reduce the harm:
- Show it only after a suspicious sign, such as too many attempts, not to everyone.
- Make sure every part of it works from the keyboard, including refresh and audio buttons.
- Give it a text label that explains what it is for.
- Offer a non-visual and a non-audio route, such as a “contact us by phone or email instead” note with the details written out in text.
- Do not put a time limit on it.
- Test it with a screen reader before and after any plugin update.
Testing CAPTCHA accessibility on your own site
Open each form and the login page in a private browser window, which is more likely to trigger a challenge. Try to submit using only the keyboard. Then turn on a screen reader and try again. If you cannot get past a step, neither can a customer who browses the same way. Note which plugin adds the challenge, because that is where the setting or the replacement will be.
Spam checks are only one of the places a store or form can turn people away; the full journey from product to receipt is mapped in our ecommerce accessibility guide.
Frequently asked questions
Are CAPTCHAs an accessibility violation?
Not automatically. WCAG allows a CAPTCHA if it has a text alternative that explains its purpose and alternative forms for different senses, and if it can be used from a keyboard. Image-only puzzles, drag sliders without a click option and timed challenges usually fail one of those conditions and block real people.
Is an audio CAPTCHA enough of an alternative?
It helps blind users but leaves out deaf-blind users and many people with hearing or cognitive disabilities, and the audio is often deliberately hard to follow. It is better than an image alone, but invisible methods such as honeypots and spam filtering avoid the problem for everyone.
What is the most accessible way to stop spam on a WordPress form?
Combine checks that visitors never see: a properly hidden honeypot field, a short time-based check and a server-side spam filter. For most small business forms this stops the bulk of spam with no puzzle at all. Keep a visible challenge only for cases these layers cannot handle, and test it.
Does WCAG 2.2 change the rules on CAPTCHAs at login?
Yes. Criterion 3.3.8 Accessible Authentication (Minimum) says login and sign-up steps should not depend on solving or transcribing a puzzle unless there is another way through or help is provided. Object recognition puzzles are allowed at Level AA, but they still need alternatives under other criteria to work for blind users.
Replacing a CAPTCHA is usually a small change, but it touches form plugins, security settings and sometimes the store, so it is worth testing properly afterwards. Our accessible form fixes page explains how we handle forms, the WooCommerce accessibility fixes page covers checkout and accounts, and you can find wider ADA website accessibility help from the same place.
Next in this series: Accessible Product Pages: Images, Swatches, Add to Cart
