Discourage Bots Not Humans - CAPTCHA Challenges to Accessibility

The Completely Automated Public Turing Test to tell Computers and Humans Apart – otherwise known as CAPTCHA – is the bane of my online existence.

This is not to say I object to securing one's own digital presence – spam is a real problem in all settings online. On a personal blog it is a nuisance but on a secure platform with financial transactions involved it can be much more dangerous.

What I have a problem with is CAPTCHA inaccessibility.

The distorted images are meant to be unreadable by computer systems, which means my screen reader is intentionally blocked from their access. This means that no optical character recognition software can interpret them for me, even if the screen reader I was using had instant access to this technology (a new feature in some models). I also could not copy and paste the image into a specialized program for interpretation. This, of course, makes sense for security purposes, but it is nonetheless frustrating.

Responding to the need for non-visual CAPTCHA, audio versions have been introduced. But they were designed to be as difficult to decipher as their visual counterparts. Distorted human speech reading digits aloud with plenty of background garble is annoying for me, but utterly unusable for someone who is hard of hearing who also lacks the vision to complete the visual ones.

The most recent iteration of CAPTCHA was released in December by Google and is called the "No CAPTCHA reCAPTCHA". Initially I was enthused -- it claimed that all a user had to do to validate themselves as human was to check a box to confirm his or her humanity and no disfigured characters nor distorted audio need apply.

Unless the system thought a user was using a script to check this box, or getting a computer to do it for them. Then it would fall back to the familiar CAPTCHA we all know and loathe.

That last point is important, as I discovered while listening to respected accessibility researcher and consultant Sina Bahram's audio post titled "Explaining the Fundamental Accessibility Challenge of CAPTCHA." As I learned, screen readers operate the same way robot scripts do. So if one was to block a robot script, screen reader access would also be lost. This means that even if a screen reader user were to check this box, they'd still be forced to interpret a conventional CAPTCHA.

I had thought that CAPTCHA consisting of single-digit addition or similarly basic questions would solve this problem, as computers wouldn't have these answers. Mr. Bahram's post proved me wrong – this is apparently easy to code for in a few lines of Pearl script.

I began to look for other alternatives. It looks as though, with a bit of PHP code, a developer can successfully create accessible CAPTCHA. For instance, creating form fields that are invisible to most users (with clear instructions to be left blank) can keep bots out, who would fill all fields by default. Detecting commonly-used spam text or URLs is effective, as is checking for identical content in multiple fields. These are not by any means the only methods, but I am happy to see so many exist.

Here at Echidna we have other means to verify our users are human, but fortunately CAPTCHA is not one of them. In short, security is important. But so too is accessibility. Why not try to marry the two?

After all, it's the bots you want to discourage -- not your human consumers!