One of the issues facing many website owners, especially those who encourage user engagement, is how to keep bots from hacking their website.

The most common way of preventing these bots is to use CAPTCHA. If, however, you are also aiming to comply with WCAG 2.0 guidelines, this in itself will bring you more hurdles.


CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart. CAPTCHA will ask the user to type in the characters they can see in a randomly generated image.

Chances are you’ve come across this feature numerous times. Usually the CAPTCHA images are squiggly and distorted, but a few more confusing versions have recently appeared. Moving CAPTCHA4D CAPTCHA and Motion CAPTCHA are just 3 of the recent horrendous versions.

However, whether you use the more readily available 'read the squiggly characters' or a fancier version, they all have the same common goal; to prevent a machine reading the text. The issue is that it also prevents blind or visually impaired users from accessing whatever is hidden behind the CAPTCHA firewall.


Google’s version of CAPTCHA, reCAPTCHA, is a supposedly a more secure, easier to use and accessible program.

Google attempts to achieve greater accessibility  with an audio challenge. This is so visually impaired people can choose to hear the Audio version. Sounds great, right? Wrong.

The problem is that Audio CAPTCHAs are harder to interpret than visual CAPTCHAS!

A few years ago, a group of hackers, C-P, Adam and Jeffball, were able to prove a machine could hack the audio descriptions by plotting the frequencies of each audio test on a spectrogram. Google then changed their audio descriptions so the words become part of the background noise and are so distorted they are no longer clear enough to comprehend. That poses an obvious problem for visually impaired people.

Having only visual OR audio description options also cuts out another group of users; those who are both hearing and vision impaired. These users can have text-to-Braille output but, again, would not be able to access website content.


So you’ve decided that you don’t want to subject your users to the pain of filling out a CAPTCHA to use your site. That’s wonderful news. But how do you stop those bots?

A very simple implementation would be an email notification system. Users submit their email address, receive a response email and activate a link. This can be worked around by computer systems, however, it does makes it harder for them to submit large quantities of information to your site.

Another alternative is Honeypot. The idea behind Honeypot is that bots love form fields and always try to fill them out. However, they tend to ignore CSS. The honeypot solution creates a form field that cannot be seen by human viewers but can be read by bots. On Submit, you check to make sure the form field is blank. To combat users who have CSS switched off, or using a screen reader, you can include include some text instructions to leave the field blank.

How about a mathematical equation? You don’t need to ask your users to calculate the speed of a moving train based on the distance its travelled.  Something simple, like “Spell out what is 3+3” or you could ask them to spell out “6”.

The question you need to ask yourself before implementing any security feature on your website is "Do I really need it?" If no, don’t use any. If yes, can ALL humans  use it?

Date posted:
21 August 2014
Authored by :
Jeannie Panting