Like it or hate it, CAPTCHA might be a website’s first defence against the robot spider invasion. Questions to ask are does it work for users (accessibility) and does it work for you (security)?
There’s nothing explicit in the current standards about CAPTCHA, but there will be in the standards released in March next year. Whatever form it takes, it’ll pretty strongly reflect the following advice from the W3C’s WCAG2.0:
CAPTCHA: If the purpose non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
To meet this, WCAG2 asks that developers:
- To provide a text alternative that describes the purpose of the CAPTCHA. The text alternative lets the user know that the CAPTCHA requires completing a task and what type of task it is
- ensure that the web page contains another CAPTCHA serving the same purpose using a different modality [ie audio, visual, etc ].
WCAG2 provides examples:
- A Web page that includes a CAPTCHA test that must be completed successfully before the user can advance to the next step in a process. The page includes both a visual task, such as typing words displayed in a image, and an audio task, such as typing letters spoken in an audio file. A user with hearing disabilities who cannot pass the audio CAPTCHA may be able to pass the video CAPTCHA.
- A blog comment form includes a visual CAPTCHA that must be completed before a user can submit comments. In addition to the visual CAPTCHA, it includes a CAPTCHA with a form field that asks, “What is two plus seven?” with a text entry field that allows users to enter the correct answer.
As general guidance, I like CAPTCHA: Telling Humans and Computers Apart Automatically, from Carnegie Mellon University, who invented the thing for Yahoo!. I’ve pasted an abbreviated version of their intro info below.
If your website needs protection from abuse, it is recommended that you use a CAPTCHA. There are many CAPTCHA implementations, some better than others. The following guidelines are strongly recommended for any CAPTCHA code:
- Accessibility. CAPTCHAs must be accessible. CAPTCHAs based solely on reading text — or other visual-perception tasks — prevent visually impaired users from accessing the protected resource.
- Image Security. CAPTCHA images of text should be distorted randomly before being presented to the user.
- Script Security. Building a secure CAPTCHA code is not easy. In addition to making the images unreadable by computers, the system should ensure that there are no easy ways around it at the script level.
- Security Even After Wide-Spread Adoption. There are various “CAPTCHAs” that would be insecure if a significant number of sites started using them. An example of such a puzzle is asking text-based questions, such as a mathematical question (”what is 1+1″).
- Should I Make My Own CAPTCHA? In general, making your own CAPTCHA script (e.g., using PHP, Perl or .Net) is a bad idea, as there are many failure modes. We recommend that you use a well-tested implementation such as reCAPTCHA.
