Strict Standards: CAPTCHA Accessibility Criteria and Web Standards Compliance

October 2013. by Matej Saric

After publishing a web form, webmasters are often surprised by the number of automated junk submissions from various bots attempting to compromise it for spam or other malicious purposes. In such a situation, Captcha validation remains a critical protection measure despite its general unpopularity in certain circles (whether rightfully deserved or not). But recognizing bots and keeping them out is only one of the criteria the form as a whole needs to meet – and Captcha protection should be implemented in a manner that least affects other functional requirements such as usability and accessibility.

CAPTCHA Accessibility to the Blind and Visually Impaired

The most important Captcha accessibility concerns stem from its reliance on the human sense of vision. But why do most Captcha implementations rely on that sense in the first place? The short answer is: because it provides the required security against automated analysis.

The Prevalence of Visual CAPTCHA

Security that works only as long as nobody actively tries to compromise it is not actual security at all – and Captcha "alternatives" which can be automatically bypassed as soon as a competent attacker bothers to do so (such as hidden field "honeypot" bot detectors and similar tricks) can hardly be considered safe enough for sites and forms that are high value targets for spam.

Most types of effective Captcha protection distinguish between human visitors and automated scripts based on capabilities of human vision that are still out of reach of current AI and OCR technology. If they are engineered properly, this makes them both secure against automated analysis and easy to read for human visitors.

Of course, if the Captcha implementation is incompetent, it will be possible to successfully analyze and break it often enough to present no real obstacle to spammers, or it could be hard to read even for human visitors with perfect vision – or it could suffer from both of those issues and deserve the bad reputation unfairly attached to all Captcha implementations.

The Accessibility Challenges of Visual CAPTCHA

Such implementation-specific concerns aside, visual Captcha types also introduce an important accessibility concern: if reading the Captcha is the only way for visitors to complete the form, they present an insurmountable barrier to the blind or otherwise visually impaired people. Since most individuals with such disabilities browse the web using assistive technology based on sound (e.g. screen readers which can pronounce web pages designed with accessibility in mind), an obvious solution is to present an alternative Captcha form which such visitors can hear.

Accessibility standards and best practices usually prescribe a plain text alternative to visual content (e.g. descriptive alt text for images, which conveys the same information and can be read by assistive technology). However, such a plain text alternative for visual Captcha is not an option – if assistive technology could read the Captcha solution from page source, so could malicious bots.

Using Audio CAPTCHA to Overcome Accessibility Pitfalls of Visual CAPTCHA

Accessibility imperatives can not override the fundamental purpose of Captcha challenges (stopping bots from automatically submitting the form), so a secure and accessible Captcha needs to be implemented: Captcha that can be heard by the blind, but can't be trivially bypassed by spam bots – in other words, audio Captcha. As the accessibility demand for audio Captcha article explains, pairing visual Captcha protection with a properly engineered audio Captcha alternative removes the main obstacle to the blind and visually impaired.

Having an audio Captcha alternative to visual Captcha challenges is necessary to meet web accessibility standards such as Section 508 (technical standards for web-based applications §1194.22 (a) "text equivalents for every non-text element" and §1194.22 (b) "synchronized multimedia alternatives", functional performance criterion §1194.31 (a) "functional without vision") and WCAG 2.0 (guideline 1.1 "text alternatives" and the related success criterion SC 1.1.1 "non-text content", general technique G144 "ensuring that the web page contains another Captcha serving the same purpose using a different modality").

Screen Reader Considerations

Screen readers that blind people use use present a drastically different medium: assistive technology can only reliably handle text-based content (that doesn't convey important information or structure using visual information such as color, CSS declarations, visual proximity incidental to a certain layout etc.). Furthermore, web pages read to the visitors are strictly sequential, so for example any updates to page state before the current "point" of reading progress will be imperceptible to the visitor until they re-read the whole form from the start, etc.

Making web forms adaptable enough to handle such a different presentation and truly accessible to screen readers goes beyond just Captcha considerations. Making sure Captcha validation and the form as a whole works well on assistive technology such as screen readers is necessary to meet web accessibility standards such as Section 508 (technical standards for web-based applications §1194.22 (n) "form accessibility to assistive technology" and §1194.22 (d) "readability without style sheets") and WCAG 2.0 (guideline 1.3 "adaptable" and the related success criteria SC 1.3.1 "info and relationships", SC 1.3.2 "meaningful sequence" and SC 1.3.3 "sensory characteristics", as well as guideline 2.1 "keyboard accessible" and the related success criteria SC 2.1.1 "keyboard accessible", SC 2.1.2. "no keyboard trap", SC 2.1.3 "keyboard (no exception)").

Visual CAPTCHA Legible to Low-Sighted Visitors

Not all visually impaired visitors are fully blind or use screen readers to access web content: low-sighted visitors can browse the web using high levels of browser zoom, screen magnifiers, or user-defined stylesheets which enlarge web content enough to make it readable to them. Visual Captcha is no exception, and shouldn't present an unfair obstacle to such visitors.

A properly implemented visual Captcha that is easily decipherable to most visitors will also generally be fair enough to low-sighted ones. As long as visitors can request a different Captcha challenge if the current one is too difficult, they'll have a fair chance of completing the Captcha challenge and won't be unfairly prevented from and submitting the form. Making the visual Captcha implementation legible to low-sighted visitors is necessary to meet web accessibility standards such as Section 508 (functional performance criterion §1194.31 (b) "functional with low vision").

People whose vision is bad are also more likely to have issues successfully solving a video Captcha challenge or any animated visual Captcha. A static Captcha image gives visitors as much time as they need to read the embedded code: some visitors might take 2 seconds while other might take 20, and the Captcha image will let them read at their own pace. It will be loaded with the form, and will generally remain the same until the user finishes filling it out.

Animated or video Captcha introduces an additional time-based constraint, and doesn't automatically accommodate different reading speeds. Of course, video Captcha might provide additional playback speed controls for such a purpose, but since even then it requires additional user interaction to provide a decipherable challenge, video Captcha and animated Captcha implementations are clearly less accessible to low-sighted visitors than image Captcha implementations.

Visual CAPTCHA Legible to Color-Blind Visitors

To make the visual Captcha implementation readable by color-blind visitors, Captcha challenges should avoid relying on the ability to distinguish colors. This won't always be possible, but generally color-independent Captcha presentation that works just as well when converted to greyscale will suffice when combined with the ability to request a different Captcha challenge (if the current one is indecipherable). This applies equally to image Captcha, video Captcha and other types of visual Captcha challenges.

Implementing visual Captcha that is legible to color-blind visitors is necessary to meet web accessibility standards such as Section 508 (technical standards for web-based applications §1194.22 (c) "use of color to convey information") and WCAG 2.0 (guideline 1.4 "distinguishable" and success criterion SC 1.4.1 "use of color").

[back to the top of the page]

Other CAPTCHA Accessibility Concerns and Criteria

Visual impairments are not the only type of disability that can make users' interaction with Captcha unfairly difficult, and a detailed examination of Captcha accessibility criteria must consider all aspects of web content accessibility.

CAPTCHA Accessible to Physically-Impaired Visitors

People with physical impairments might not be able to use input methods that require fine motor control, simultaneous or closely-timed actions, or a certain amount of physical reach and strength. They will navigate the form (including the Captcha challenge) using assistive technology that is mostly based on keyboard input or input that gets transformed into an equivalent of keyboard input (voice-controlled input, pointer-based on-screen keyboards, etc.)

When solving the Captcha challenge involves only typing (or using assistive technology to emulate keyboard input), disabled users won't face a challenge unfairly harder than the rest of their web browsing experience. To make Captcha accessible to such visitors, web form developers must ensure that 100% of the Captcha validation workflow (switching between Captcha elements, user input of the Captcha challenge, submitting the user input to the server for validation, Captcha error feedback and re-tries) can be operated using keyboard input only.

Highly interactive or dynamic forms of "Captcha" which rely on fine motor control (Captcha that requires precise pointer-based input) or timed actions (Captcha that requires time-sensitive input) – such as slider Captcha, drag 'n' drop Captcha, Captcha games etc. – will be less accessible to physically-impaired visitors than Captcha forms which require only simple, relatively imprecise, and timing independent keyboard input.

Implementing a keyboard-operable, timing-independent Captcha is necessary to meet web accessibility standards such as Section 508 (technical standards for web-based applications §1194.22 (n) "form accessibility to assistive technology" and §1194.22 (p) "timed response extension", functional performance criterion §1194.31 (b) "functional with low motor ability") and WCAG 2.0 (guideline 2.1 "keyboard accessible" and the related success criteria SC 2.1.1 "keyboard accessible", SC 2.1.2. "no keyboard trap", SC 2.1.3 "keyboard (no exception)", as well as guideline 2.2 "enough time" with the success criteria SC 2.2.1 "timing adjustable", SC 2.2.2 "pause, stop, hide", SC 2.2.3 "no timing", SC 2.2.4 "interruptions").

CAPTCHA Accessible to Seizure-Prone Visitors

Certain forms of dynamic visual content are known to induce dangerous and potentially life-threatening seizures in a number of individuals. To achieve basic Captcha accessibility and eliminate the risk for web page visitors, such "flashing" content that causes dangerous "flicker" must be avoided. Classic image-based Captcha implementations don't cause any noticeable screen flicker at all – however, Captcha protection which uses animated images or Captcha video can potentially cause screen flicker or flashes, and might be problematic to seizure-prone individuals.

Implementing a seizure-free Captcha is necessary to meet web accessibility standards such as Section 508 (technical standard for web-based applications §1194.22 (j) "avoiding screen flicker") and WCAG 2.0 (guideline 2.3 "seizures" with its success criteria SC 2.3.1 "three flashes or below threshold" and SC 2.3.2).

CAPTCHA Accessible to People with Cognitive Impairments

Captcha implementations that require complex interaction, comprehension of potentially ambiguous instructions, or a highly developed reading or abstract thinking ability can unnecessarily reduce the accessibility of the form – and consequentially, the user base that can successfully complete it. To maximize web form accessibility, the Captcha challenge should be as simple to solve as possible (to human visitors, of course). Everybody who can read the alphabet can also retype a Captcha image, so image Captchas are among the most accessible implementations even according to this criterion.

[back to the top of the page]

CAPTCHA Accessibility Criteria: Conclusions & Further Reading

A truly accessible Captcha implementation should be accessible to blind visitors using screen readers, to low-sighted or color-blind visitors, to physically impaired visitors, to seizure-prone visitors, and simple enough for people with cognitive impairments. Many Captcha implementations fail at least some of these criteria of accessibility.

While image Captcha protection is often derided as inaccessible due to a number of bad implementations, a properly designed image Captcha paired with an audio Captcha alternative is actually one of the most accessible forms of Captcha that also meets adequate Captcha security standards.