CAPTCHA under WCAG2.0
Overview
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)?
Using this transitional guide
This is only a transitional guide to WCAG2.0. Developers must be familiar with WCAG2.0 (AA) itself.
Related
- The Technical standards section shows how the standards work.
- The Technical web guides explain how to use WCAG2.0 with summaries and guides.
What the standards say
WCAG2.0 offers clear advice on CAPTCHA:
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.0 asks that developers:
- 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 ].
It 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.
CAPTCHA from the source
As general guidance, see CAPTCHA: Telling Humans and Computers Apart Automatically, from Carnegie Mellon University, who invented the CAPTCHA for Yahoo!. An abbreviated version of their introduction information follows.
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.
