Monitoring reCAPTCHA and Bot Checks That Lock Out Keyboard Users
If your checkout or account page puts a puzzle CAPTCHA in front of a login with no alternative, it fails WCAG 2.2 criterion 3.3.8 at Level AA. Monitor for it the way you monitor anything else: a scheduled check that a keyboard-only tester can get through the flow, and an alert when the check appears with no alternative path.
The check your scanner never runs
Automated scanners test pages, not flows. They will flag a missing label on the login form and call the page clean, while the CAPTCHA sitting between the password field and the submit button goes untested. That is the gap. A puzzle CAPTCHA is a cognitive function test under WCAG 2.2 criterion 3.3.8, Accessible Authentication, and the criterion is explicit: no step of authentication may require remembering a password, transcribing a code, or solving a puzzle unless that step also offers an alternative method or a mechanism that helps the user complete it. A password field that accepts paste and works with a password manager passes, because the tool does the remembering. A CAPTCHA with no alternative does not.
The monitoring angle is simple. Your scanner checks the login page for labels and contrast. Your monitoring should also check the flow: can a keyboard-only tester reach the submit button, and is there a path through that does not demand a puzzle? If the answer to either is no, that is a Level AA failure on a page every customer touches, and it should page someone the way a checkout outage would.
What to watch after every deploy
Three changes break this most often. A fraud vendor update swaps in a new challenge with no accessible alternative. A theme update adds a bot check to the account creation page that never had one. A checkout extension inserts its own verification step mid-flow, after the password, where the original audit never looked. None of those show up in a page scan, because the page itself is unchanged and the failure lives in the sequence.
So the monitor is a sequence, not a snapshot. Once a week, a tester runs the login and account creation flows with keyboard only, with paste blocked and allowed, and notes whether any step demands a memory or puzzle test with no way around it. When a new challenge appears, the alert goes to the person who owns fraud tooling, not to the accessibility backlog, because the fix is a vendor configuration, not a code change. Passkeys, magic links, and a CAPTCHA with an audio or alternative path are the usual answers. The point of the monitor is that the question gets asked before a customer is the one asking it. Scanner disagreement is the same class of problem: when Axe, WAVE, and Lighthouse disagree, and an alert with no owner is what happens when the finding never gets assigned.
Frequently asked questions
What does WCAG 3.3.8 actually forbid?
It forbids requiring a cognitive function test, remembering a password, transcribing a code, solving a puzzle, at any step of authentication unless that step also offers an alternative method, a mechanism to help, or an object recognition option. A password field that accepts paste passes because the password manager does the remembering.
Does a CAPTCHA always fail 3.3.8?
No. An image-selection CAPTCHA can pass at Level AA through the object recognition exception, and a CAPTCHA with a non-puzzle alternative, like a magic link or passkey path, passes. A distorted-text CAPTCHA with no alternative is the failure.
Why does my scanner miss this?
Scanners test pages, not flows. The CAPTCHA appears mid-flow, after the login page loads, and the criterion is about the sequence of steps. A flow test with a keyboard is the only check that catches it.
Who should own the alert?
The person who owns fraud tooling, not the accessibility backlog. The fix is usually a vendor configuration, switching the challenge type or adding an alternative path, not a code change.