WCAG CAPTCHA: How to Make CAPTCHA Conform to W3C WCAG 2.0 Standards
Unlike Recaptcha the Stalker -- BotDetect CAPTCHA works in China! Licensable source-code; self-hosted -- doesn't stalk -- nor does it slurp your form-data! Think: GDPR & LGPD!
October 2013. by Matej Saric
Among web accessibility standards, W3C Web Content Accessibility Guidelines (WCAG) are the most commonly used and (in version 2.0) the most detailed. When evaluating the accessibility of a web form which includes Captcha validation to only allow submissions from verified human visitors, checking WCAG conformance is a logical choice for most websites.
However, WCAG is also the most complex web accessibility standard, and requires careful consideration to meet. To make WCAG-conformant Captcha implementation as easy as possible, we'll examine WCAG implications for Captcha validation in detail.
Following the W3C guidelines is important to make an accessible Captcha implementation – but it should be noted that only a web page as a whole can be said to either conform or not conform to WCAG. To make this distinction clear, we'll consider both WCAG conformance of core Captcha features and the necessary WCAG conformance of Captcha-related form elements.
Table of Contents
- WCAG 2.0 in a nutshell
- WCAG 2.0 conformance requirements which apply to Captcha
- Captcha & WCAG 2.0 principle 1: Perceivable
- Captcha & WCAG 2.0 principle 2: Operable
- Captcha & WCAG 2.0 principle 3: Understandable
- Captcha & WCAG 2.0 principle 4: Robust
- Conclusions & further reading
WCAG 2.0 in a Nutshell
Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these. Following these guidelines will also often make your Web content more usable to users in general.
WCAG 2.0 is based on 4 core accessibility principles. Each principle determines a number of accessibility guidelines as basic objectives that need to be met by web pages. Each guideline can be evaluated through a number of accessibility success criteria which test page conformance. Each individual success criterion can be met by applying a number of accessibility techniques.
WCAG 2.0 Conformance Requirements Which Apply to CAPTCHA
Since the use case we are interested in is a web form protected with Captcha validation to prevent automated submissions, we'll only examine the WCAG 2.0 standards with this scenario in mind. While all 4 WCAG principles and most of the 12 WCAG guidelines apply to Captcha, not all 61 WCAG success criteria are meaningful in the context of a Captcha-protected form. For those that don't apply, we'll also explain why that is the case.
Legend
| Element | Meaning |
|---|---|
| BotDetect Techniques | WCAG 2.0 techniques implemented by BotDetect Captcha to facilitate WCAG 2.0 conformance of your Captcha-protected forms. |
| Your Form Techniques | WCAG 2.0. techniques your form should implement on top of BotDetect functionality to achieve WCAG 2.0 conformance. |
| - | The given success criterion does not apply to Captcha protection or doesn't need special handling for Captcha purposes (see full text and commentary below). |
| WAI WCAG 2.0 Level A conformance | |
| WAI WCAG 2.0 Level AA conformance | |
| WAI WCAG 2.0 Level AAA conformance |
CAPTCHA and the WCAG 2.0 Accessibility Principle 1: Perceivable
Information and user interface components must be presentable to users in ways they can perceive.
When a visitor browses to a web page, they have to be able to perceive its content and functionality through their senses. Since some visitors will have disabilities related to one or more of their senses (for example, the blind), web pages which exclusively convey information through a single sensory channel (for example, through visual representation in an image) can not meet web accessibility standards.
To make a web form accessible to perceptual needs of disabled visitors, important page content should be available in a format that can be used or transformed by assistive technology. The form also needs to preserve necessary information, structure and functionality when adapted to the visitor's particular needs (if the form layout is changed because the visitor uses a very high level of zoom, when CSS layout is not used at all, when the visitor cannot perceive color, ...)
Since Captcha challenges are often designed to distinguish between human visitors and automated bots by testing for unique properties of human senses (most commonly, vision), it is very important to consider Captcha designs that won't prove unfairly hard or impossible for individuals with sensory disabilities of any kind. Simply put, Captcha that can't be perceived by disabled users – and therefore prevents them from completing the protected form – can never be accessible or conform to WCAG requirements.
CAPTCHA and the WCAG 2.0 Accessibility Principle 1 Guidelines
- Captcha & WCAG 2.0 guideline 1.1 – Text Alternatives
- Captcha & WCAG 2.0 guideline 1.2 – Time-based Media
- Captcha & WCAG 2.0 guideline 1.3 – Adaptable
- Captcha & WCAG 2.0 guideline 1.4 – Distinguishable
CAPTCHA and the WCAG 2.0 Accessibility Guideline 1.1 – Text Alternatives
Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
To allow individuals with disabilities access to Web content, different forms of assistive technology have been developed to facilitate modes of interaction suited to their particular needs. For example, visually impaired persons can use screen readers to convert textual web content they can't see into an audio pronunciation they can hear.
But all types of assistive technology can only convert web pages into accessible alternatives if they start with appropriate input. For example, screen readers can only read text aloud, but can't deal with images (how could any software less capable than true AI possibly pronounce an image?). Since most types of assistive technology are designed to work with text input, having appropriate text alternatives for all non-text content is an obvious accessibility objective – and necessary for WCAG conformance.
As we will see, Captcha presents a unique challenge for this accessibility guideline, since it almost always uses non-text content to prove a human interaction – but can't easily provide a plain text alternative suited for assistive technology use. After all, using a machine-readable text alternative of the Captcha challenge would make it readable not only to assistive technology, but also to malicious bots it is designed to hinder. Because defeating the very purpose a Captcha is used for would make it futile, a different approach needs to be taken.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 1.1 Success Criteria
CAPTCHA and the WCAG 2.0 Success Criterion 1.1.1 – Non-text Content
All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)
- ...
- CAPTCHA: If the purpose of 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.
- ...
Considering a typical Captcha implementation that uses images of distorted text to confirm a human visitor, this success criterion can be met by providing an alternative form of Captcha suitable for visually impaired individuals (most commonly, an audio Captcha), and ensuring all non-text elements other than Captcha challenges have appropriate text alternatives.
CAPTCHA Implementation Satisfying the the WCAG 2.0 Conformance Success Criterion 1.1.1
This general WCAG technique is important when choosing which short text to use as an alternative for non-text content. BotDetect includes short text alternatives for Captcha images and the icons controlling Captcha sound playback and reloading, and allows you to customize them to follow this WCAG technique according to the requirements (language, reading level, purpose) of your Captcha-protected form.
Each developer will write appropriate Captcha challenge instructions as part of adding Captcha protection to the form. These same instructions can then be configured as the BotDetect Captcha image text alternative as recommended by this WCAG technique.
BotDetect provides out-of-the-box audio Captcha functionality engineered to be accessible and easily understandable, compatible with a wide range of client browsers and devices, and secure against automated analysis.
All images used in BotDetect-generated markup follow this WCAG technique and include fully customizable alt attributes.
All textual link elements used in BotDetect-generated markup follow this WCAG technique and include customizable link text.
When adding BotDetect Captcha protection to a form, the Captcha solving instructions should be provided in a label element associated with the Captcha code textbox to follow this WCAG technique.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 1.2 – Time-based Media
Provide alternatives for time-based media.
Time-based or synchronized media (video or audio) can present an obstacle to visitors with perceptual (visual or auditory) disabilities, and needs alternative forms they can perceive according to their needs.
Most Captcha implementations don't use time-based (synchronized) media, so this WCAG guideline doesn't apply to them. If your Captcha implementation or form does use time-based media for some reason, you should of course consider it carefully to achieve WCAG conformance.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 1.2 Success Criteria
- Captcha & WCAG 2.0 SC 1.2.1 – Audio-only and Video-only
- Captcha & WCAG 2.0 SC 1.2.2 – Captions (Prerecorded)
- Captcha & WCAG 2.0 SC 1.2.3 – Audio Description or Media Alternative (Prerecorded)
- Captcha & WCAG 2.0 SC 1.2.4 – Captions (Live)
- Captcha & WCAG 2.0 SC 1.2.5 – Audio Description (Prerecorded)
- Captcha & WCAG 2.0 SC 1.2.6 – Sign Language (Prerecorded)
- Captcha & WCAG 2.0 SC 1.2.7 – Extended Audio Description
- Captcha & WCAG 2.0 SC 1.2.8 – Media Alternative (Prerecorded)
- Captcha & WCAG 2.0 SC 1.2.9 – Audio-only (Live)
CAPTCHA and the WCAG 2.0 Success Criterion 1.2.1 – Audio-only and Video-only (Prerecorded)
For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such: (Level A)
- Prerecorded Audio-only: An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.
- ...
Prerecorded audio is usually not used for Captcha purposes, since a proper Captcha implementation should be able to generate a near-infinite number of different challenges. Any Captcha using a limited pool of challenges (including all implementations that can be described as "prerecorded") can be compromised by simply collecting a large enough sample (or all) of the available challenges. High-security Captcha will remain an obstacle to automated solving even when its source code and resources used are available to the attacker – which "prerecorded" media clearly fails to achieve.
The same reasoning applies to prerecorded video, and affects video Captcha implementations. Since fundamental Captcha requirements eliminate prerecorded media of any sort, this WCAG success criterion rarely applies to Captcha functionality. Of course, if your Captcha implementation does use prerecorded audio or video, you should consider this criterion for WCAG conformance – and possibly fundamental Captcha security as well.
Of course, making Captcha audio perceivable by deaf individuals (or video Captcha perceivable by blind individuals) is mandatory for WCAG Captcha implementation, and handled by providing an alternative Captcha modality which doesn't depend on the same (possibly impaired) sense as the primary form.
CAPTCHA and the WCAG 2.0 Success Criterion 1.2.2 – Captions (Prerecorded)
Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such. (Level A)
As explained above, prerecorded audio content should not factor in proper Captcha implementations, so audio captions don't affect Captcha WCAG conformance.
CAPTCHA and the WCAG 2.0 Success Criterion 1.2.3 – Audio Description or Media Alternative (Prerecorded)
An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such. (Level A)
As explained above, prerecorded video content should not factor in proper Captcha implementations, so audio or other alternatives for the video don't affect Captcha WCAG conformance.
CAPTCHA and the WCAG 2.0 Success Criterion 1.2.4 – Captions (Live)
Captions are provided for all live audio content in synchronized media. (Level AA)
While Captcha audio could conceivably be considered "live audio content", it should never be time-based (require user interaction at a precise moment of time identified by the media, or depend on timing synchronized with other formats). Even if this fact didn't disqualify audio Captcha from WCAG criteria for time-based media, the fact that it's impossible to provide a machine readable text caption for Captcha audio without undermining basic Captcha security would.
Finally, Captcha audio should be perceivable by aurally impaired individuals by being paired with an alternate Captcha modality which doesn't depend on the sense of hearing. People who are deaf or have a hearing loss won't be excluded by a Captcha implementation as long as it includes a visual representation they can read (image or video Captcha).
CAPTCHA and the WCAG 2.0 Success Criterion 1.2.5 – Audio Description (Prerecorded)
Audio description is provided for all prerecorded video content in synchronized media. (Level AA)
As explained above, prerecorded video content should not factor in proper Captcha implementations, so video descriptions don't affect Captcha WCAG conformance.
CAPTCHA and the WCAG 2.0 Success Criterion 1.2.6 – Sign Language (Prerecorded)
Sign language interpretation is provided for all prerecorded audio content in synchronized media. (Level AAA)
As explained above, prerecorded audio content should not factor in proper Captcha implementations, so audio representation with sign language doesn't affect Captcha WCAG conformance.
CAPTCHA and the WCAG 2.0 Success Criterion 1.2.7 – Extended Audio Description (Prerecorded)
Where pauses in foreground audio are insufficient to allow audio descriptions to convey the sense of the video, extended audio description is provided for all prerecorded video content in synchronized media. (Level AAA)
As explained above, prerecorded video content should not factor in proper Captcha implementations, so extended audio descriptions for video don't affect Captcha WCAG conformance.
CAPTCHA and the WCAG 2.0 Success Criterion 1.2.8 – Media Alternative (Prerecorded)
An alternative for time-based media is provided for all prerecorded synchronized media and for all prerecorded video-only media. (Level AAA)
As explained above, prerecorded content should not factor in proper Captcha implementations, so its alternatives don't affect Captcha WCAG conformance.
CAPTCHA and the WCAG 2.0 Success Criterion 1.2.9 – Audio-only (Live)
An alternative for time-based media that presents equivalent information for live audio-only content is provided. (Level AAA)
As explained above, live audio content should not factor in proper Captcha implementations, so its alternatives don't affect Captcha WCAG conformance.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 1.3 – Adaptable
Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
Web content designed for non-disabled visitors won't necessarily be suitable for visitors with disabilities, since their unique needs might require drastically different forms of presentation. Low sighted visitors might enlarge text sufficiently to break form layout, some assistive technologies won't interpret CSS rules or will override page settings to make it easier to perceive to users with special needs, etc.
A well-designed web form or Captcha implementation will handle such transformations as gracefully as possible, and will use well-known techniques to ensure that important information, structure or functionality is not lost in the process. If information is embedded in a particular presentation and cannot be programmatically determined by assistive technologies, then it cannot be rendered in other formats as needed by the user.
Since disabled visitors might need those alternate formats to perceive the content at all, adequate adaptability of web content is an accessibility objective necessary to make it perceivable – and Captcha implementations that need to conform to WCAG accessibility standards are no exception.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 1.3 Success Criteria
- Captcha & WCAG 2.0 SC 1.3.1 – Info and Relationships
- Captcha & WCAG 2.0 SC 1.3.2 – Meaningful Sequence
- Captcha & WCAG 2.0 SC 1.3.3 – Sensory Characteristics
CAPTCHA and the WCAG 2.0 Success Criterion 1.3.1 – Info and Relationships
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
When adapting page presentation to a different representation suited to disabled individual needs, important page structure and relationships between related page elements need to be preserved. This means such info can not be implicit from a side-effect of a particular representation format (such as the relatedness of two page elements being implied only through their visual proximity in the default page layout) – it needs to be explicit from machine-readable, semantic markup and textual content that assistive technology can process.
When adding Captcha protection to a web form, relatively few form elements are usually involved (Captcha solving instructions, the Captcha image and related controls, a textbox for user input, required field and error indicators). WCAG conformance requires that these elements be associated in a manner which won't suffer from being adapted to an alternate representation for disabled individuals. Captcha description or instructions should remain obviously related to the Captcha challenge and the associated user input elements, just like any error or progress feedback. Since the instructions and feedback will vary significantly between different forms and websites, web form developers should take care to follow this WCAG criterion.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 1.3.1
When adding BotDetect Captcha protection to a form, the Captcha solving instructions should be provided in a label element associated with the Captcha code textbox to follow this WCAG technique.
CAPTCHA and the WCAG 2.0 Success Criterion 1.3.2 – Meaningful Sequence
When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)
In Captcha implementations, element sequence is mostly important in providing Captcha solving instructions before the actual challenge (since giving users instructions after it would be more confusing). While other page elements involved in presenting and validating the Captcha challenge will naturally fall in a sequence that makes the most sense and is easily readable, they will only rarely depend on that particular sequence to be properly perceivable. The behavior of the Captcha-protected form when adapted by assistive technology needs to be tested for this WCAG criterion of page adaptability to ensure conformance.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 1.3.2
All Html elements in BotDetect-generated markup follow this WCAG technique, and their DOM order matches the visual one.
CAPTCHA and the WCAG 2.0 Success Criterion 1.3.3 – Sensory Characteristics
Instructions provided for WCAG 2.0 Compliance and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. (Level A)
Any instructions describing the purpose and interaction options of the implemented Captcha challenge should be written in a manner which adapts to various content variations produced by assistive technology. Captcha-specific instructions usually have no special requirements notably different than other form operating instructions, so they should be made adaptable (and consequently, perceivable) alongside them when checking WCAG conformance.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 1.4 – Distinguishable
Make it easier for users to see and hear content including separating foreground from background.
Making web page content and functionality available in formats that assistive technologies can easily transform into alternatives disabled individuals can perceive is necessary for accessibility – but it is not enough. Truly accessible web content must also be easily perceivable in its default presentation.
For example, the fact that blind visitors can use screen readers to transform page content into an audible equivalent doesn't mean the page can neglect readability for visitors whose sight is "merely" bad. After all, requiring people who can see but whose sight has slightly deteriorated with age to use screen readers is an unnecessary obstacle – when they could easily read the page if it used a design with sufficient contrast, readable fonts and a decent color scheme by default.
Implementing distinguishable visual Captcha validation is mostly about making it legible: Captcha images that are too small, too distorted, use unnecessarily long Captcha codes, or fail to account for character shape ambiguity (e.g. "1", "l", "7", "I" should never be used together) can all fail to meet this WCAG accessibility objective.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 1.4 Success Criteria
- Captcha & WCAG 2.0 SC 1.4.1 – Use of Color
- Captcha & WCAG 2.0 SC 1.4.2 – Audio Control
- Captcha & WCAG 2.0 SC 1.4.3 – Contrast (Minimum)
- Captcha & WCAG 2.0 SC 1.4.4 – Resize text
- Captcha & WCAG 2.0 SC 1.4.5 – Images of Text
- Captcha & WCAG 2.0 SC 1.4.6 – Contrast (Enhanced)
- Captcha & WCAG 2.0 SC 1.4.7 – Low or No Background Audio
- Captcha & WCAG 2.0 SC 1.4.8 – Visual Presentation
- Captcha & WCAG 2.0 SC 1.4.9 – Images of Text (No Exception)
CAPTCHA and the WCAG 2.0 Success Criterion 1.4.1 – Use of Color
Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)
This rule is clearly written with accessibility to color-blind individuals in mind, and mostly applies to status indicators such as required field markers, error and success indicators etc. When implementing your web form, a good way to test this rule would be to take a screenshot of the form and convert it to grayscale, and check that no information necessary for form functionality gets lost in the conversion. Of course, more detailed checks would involve testing how the form functions for disadvantaged individuals according to their specific type of color-blindness.
Captcha images often use different color schemes and may rely on the visitors' ability to distinguish colors. There are several ways to mitigate this and make Captcha protected forms accessible to the color-blind:
- Audio Captcha functionality provides an alternative that is accessible to color-blind individuals, and allows them to use form functionality (similarly how it ensures other types of visually impaired individuals are not unfairly challenged by Captcha images).
- Captcha image challenges can be designed not to rely solely on the ability to distinguish colors.
- If some Captcha images rely on color recognition ability, the Captcha test can still be solvable by the color-blind if they can request a different Captcha image – as long as not all Captcha images require that ability.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 1.4.1
If any part of the Captcha user interaction workflow uses color to convey information (for example, using a red error indicator when Captcha validation fails, and a green success indicator when it succeeds), web form developers should follow this WCAG technique and make sure that the same information is available to color-blind visitors.
The BotDetect stylesheet includes style declarations which add a thin grey outline to focused elements the user can interact with (BotDetect links/icons). Each form developer can also customize the appearance of this indicator by overriding the BotDetect stylesheet.
CAPTCHA and the WCAG 2.0 Success Criterion 1.4.2 – Audio Control
If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)
Captcha audio is typically not used as the primary Captcha modality triggered by default (like Captcha images are automatically loaded and shown with the form), so it should never be played automatically on page load. And even then, Captcha sounds are usually short enough not to exceed the threshold duration of 3 second, making this Captcha accessibility criteria easy to meet.
Automatic sound playback longer than a few seconds would negatively affect page usability for all users, but would be particularly problematic to screen reader visitors who rely on having the page pronounced to them. Any background sounds which could interfere with screen reader pronunciation of page elements need to be strictly avoided to help visually impaired visitors perceive page content. And even when Captcha sounds are only played on user request (as they should be), testing whether they clash with screen reader pronunciations is needed to meet this WCAG criteria of distinguishability.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 1.4.2
BotDetect Captcha only plays Captcha sounds when users activate the audio Captcha icon/link, as specified by this WCAG technique.
Since JAWS for example will also pronounce the Captcha textbox label when the Captcha sound icon is activated (by default, the autoFocus setting is enabled to make it easier for visitors to input the Captcha code as it is being pronounced – otherwise, blind visitors would have to remember the pronounced Captcha code, navigate to the textbox themselves, and then input it), BotDetect also implements a configurable sound playback delay to avoid overlapping pronunciation of the audio Captcha and the Captcha label.
CAPTCHA and the WCAG 2.0 Success Criterion 1.4.3 – Contrast (Minimum)
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)
- ...
- Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
- ...
Captcha images obviously qualify as "images of text" – and while they should be designed to meet minimum readability standards, they can't always satisfy this precise contrast requirement – because it could compromise their resilience against automated analysis. Besides, background and foreground noise, clutter and effects Captcha images use to confound OCR technology qualify as "significant other visual content" and could exclude Captcha images from meeting this WCAG criterion.
High contrast between text and other elements in a Captcha image wouldn't necessarily make it legible to low-sighted visitors, since text distortion and segmentation challenges (overlapping text with background and foreground noise) will affect Captcha image readability much more than simple contrast. If text was distinguishable from the image based on contrast requirements only, it could also be recognized by OCR technology and the Captcha challenge nullified. And even extremely high levels of contrast wouldn't guarantee that distorted and segmented text is easily distinguishable by the visually impaired. In other words, contrast levels are not an appropriate readability measure for visual Captcha challenges, and can't guide their design.
This doesn't mean Captcha challenges should not be accessible to individuals with low visual acuity this rule is intended to help: if Captcha images are configured for appropriate readability (large enough images, containing short enough Captcha codes, properly designed and generated to be indecipherable by bots but easily legible to humans) they'll still have a good chance of solving them. The ability to request a different picture when the current one is indecipherable is helpful for all visitors (since given a high level of randomization necessary for proper Captcha security, the result may be unpredictable enough to occasionally produce highly challenging images), but is particularly necessary for visitors with low vision.
Furthermore, such visitors won't be unfairly prevented from using form functionality as long as the Captcha challenge contains a Captcha audio alternative or other modality suitable for the visually impaired. A non-visual alternative is the most important element of Captcha WCAG conformance.
Captcha-related elements other than Captcha images (such as the text labels with Captcha instructions and similar) can meet this WCAG criterion depending on the overall form design, so their WCAG conformance is fully controlled by the form developer.
CAPTCHA and the WCAG 2.0 Success Criterion 1.4.4 – Resize text
Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)
Visitors suffering low visual acuity can drastically improve their web browsing experience by using browser features such as user-defined font sizes and stylesheets, as well as modern browser full page zoom. While assistive technology such as screen magnifiers is available for more demanding users, general form functionality should meet this WCAG requirement for the majority of cases.
There is no type of Captcha challenge that is likely to have problems meeting this criterion, but web form developers should always test form appearance and functionality when zoomed to twice the perceived width and height. A WCAG-conformant form and Captcha implementation should remain perfectly distinguishable and readable when resized.
CAPTCHA and the WCAG 2.0 Success Criterion 1.4.5 – Images of Text
If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: (Level AA)
- ...
- Essential: A particular presentation of text is essential to the information being conveyed.
While Captcha images are essentially "images of text", they are always designed in such a manner that their particular, machine-unreadable presentation is essential to their function. Using plain text to present a Captcha challenge would make it machine-readable and allow bots to automatically submit the form, so Captcha implementations are excluded from this WCAG criterion.
CAPTCHA and the WCAG 2.0 Success Criterion 1.4.6 – Contrast (Enhanced)
The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following: (Level AAA)
- ...
- Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
- ...
Just like the WAI Level A criterion, this high contrast requirement can not be universally applied to visual Captcha implementations.
CAPTCHA and the WCAG 2.0 Success Criterion 1.4.7 – Low or No Background Audio
For prerecorded audio-only content that (1) contains primarily speech in the foreground, (2) is not an audio CAPTCHA or audio logo, and (3) is not vocalization intended to be primarily musical expression such as singing or rapping, at least one of the following is true: (Level AAA)
- ...
Audio Captcha is clearly excluded from satisfying this particular WCAG success criterion, so WCAG conformance of Captcha-protected forms only depends on whether any other audio content is present and meets its requirements.
CAPTCHA and the WCAG 2.0 Success Criterion 1.4.8 – Visual Presentation
For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)
- ...
Most Captcha implementations don't use any kind of "blocks of text", so this WCAG criterion doesn't apply. If your Captcha implementation or form does use blocks of text for some reason, you should of course consider it carefully to achieve WCAG conformance.
CAPTCHA and the WCAG 2.0 Success Criterion 1.4.9 – Images of Text (No Exception)
Images of text are only used for pure decoration or where a particular presentation of text is essential to the information being conveyed. (Level AAA)
Just like the WAI Level A criterion, this requirement can not be applied to visual Captcha implementations.
CAPTCHA and the WCAG 2.0 Accessibility Principle 2: Operable
User interface components and navigation must be operable.
When a visitor interacts with web page functionality, he depends on the user interface implemented by the page. While most well-designed pages will be easily operable by non-disabled visitors, accessibility requires that the user interface also accommodates visitors whose disabilities prevent them from engaging in a particular kind of UI actions. For example, visitors with physical disabilities might not be able to complete tasks which require high levels of precision or rapid reactions.
Implementing an operable Captcha doesn't usually require special handling different from other form fields – except in the case of highly dynamic variants such as "drag & drop Captcha", "Captcha slider" or "Captcha game". Unless they provide a suitable alternative for visitors with physical disabilities, such Captcha implementations may have trouble meeting accessibility requirements of WCAG conformance.
CAPTCHA and the WCAG 2.0 Accessibility Principle 2 Guidelines
- Captcha & WCAG 2.0 guideline 2.1 – Keyboard Accessible
- Captcha & WCAG 2.0 guideline 2.2 – Enough Time
- Captcha & WCAG 2.0 guideline 2.3 – Seizures
- Captcha & WCAG 2.0 guideline 2.4 – Navigable
CAPTCHA and the WCAG 2.0 Accessibility Guideline 2.1 – Keyboard Accessible
Make all functionality available from a keyboard.
Different disabled visitors will be able to use various input methods as suited to their special needs. Therefore, relying on any particular individual input method could make a web page inoperable to a subset of users whose disabilities prevent them from using that input method – unless the page also supports keyboard input.
Keyboard is the most widely supported input method, which can be used not only with an actual hardware keyboard, but also with speech input, mouse- or touch-operated on-screen keyboards, and many other assistive technologies which can emulate it.
Making the web form and all steps of Captcha validation fully operable with keyboard input only (and testing form functionality in such a manner) is an accessibility objective necessary to achieve Captcha WCAG conformance.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 2.1 Success Criteria
- Captcha & WCAG 2.0 SC 2.1.1 – Keyboard
- Captcha & WCAG 2.0 SC 2.1.2 – No Keyboard Trap
- Captcha & WCAG 2.0 SC 2.1.3 – Keyboard (No Exception)
CAPTCHA and the WCAG 2.0 Success Criterion 2.1.1 – Keyboard
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
Most Captcha implementations won't use path-dependent input, and all page elements involved in the user's interaction with the Captcha challenge can easily be made keyboard-operable to meet this WCAG success criterion.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 2.1.1
Interactive elements generated as part of the BotDetect Captcha markup can all be navigated using keyboard navigation. The element tabindex values automatically follow their logical and visual order, and the starting value can be easily customized by form developers.
Each Captcha-protected form should be implemented to follow this WCAG technique.
CAPTCHA and the WCAG 2.0 Success Criterion 2.1.2 – No Keyboard Trap
If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)
The only type of Captcha that is likely to have trouble meeting this WCAG success criterion are plugin-dependent interactive Captcha implementations like Flash Captcha, Java applet Captcha, Silverlight Captcha or Unity Player Captcha. Such Captcha implementations should rarely be used as the default Captcha modality, since the plugin requirements can significantly reduce the supported user base. Most Captcha-protected forms will therefore be operable enough to easily meet this WCAG requirement.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 2.1.2
Each Captcha-protected form should be implemented to follow this WCAG technique.
CAPTCHA and the WCAG 2.0 Success Criterion 2.1.3 – Keyboard (No Exception)
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)
Just like the WAI Level A criterion, properly implemented Captcha validation will meet this operability requirement.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 2.2 – Enough Time
Provide users enough time to read and use content.
Some web page interactions can only be completed in a limited time period – and their time limits are often set with average human ability or response time in mind. However, many disabled individuals need more time to complete such tasks: their physical speed and reaction time might be reduced, their reading ability might be impaired enough to make timed task comprehension harder, their low vision may make them take longer to find or read required information, or they may be accessing content through an assistive technology that requires more time.
To make web pages operable by visitors with special needs, such timed interactions need to provide an option to adjust or extend the timeout enough to allow successful task completion. Of course, not all interactions (such as strictly timed tests) will be able to do so without changing the fundamental nature of the task. However, user interaction with Captcha validation will typically never require strict time limits that would conflict with this WCAG accessibility objective.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 2.2 Success Criteria
- Captcha & WCAG 2.0 SC 2.2.1 – Timing Adjustable
- Captcha & WCAG 2.0 SC 2.2.2 – Pause, Stop, Hide
- Captcha & WCAG 2.0 SC 2.2.3 – No Timing
- Captcha & WCAG 2.0 SC 2.2.4 – Interruptions
- Captcha & WCAG 2.0 SC 2.2.5 – Re-authenticating
CAPTCHA and the WCAG 2.0 Success Criterion 2.2.1 – Timing Adjustable
For each time limit that is set by the content, at least one of the following is true: (Level A)
- ...
- Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
- Essential Exception: The time limit is essential and extending it would invalidate the activity; or
- 20 Hour Exception: The time limit is longer than 20 hours.
This Success Criterion applies only to time limits that are set by the content itself. For example, if a time limit is included in order to address security concerns, it would be considered to have been set by the content because it is designed to be part of the presentation and interaction experience for that content. Time limits set externally to content, such as by the user agent or by factors intrinsic to the Internet are not under the author's control and not subject to WCAG conformance requirements. Time limits set by Web servers should be under the author's/organization's control and are covered.
Common forms of Captcha challenges are usually not strictly timed, and should not present an unfair obstacle to disabled individuals (who might require significantly more time to complete the form than visitors without disabilities). However, some aspects of Captcha protection might have an associated time limit depending on the implementation, and should then be designed to accommodate individuals with disabilities and evaluated against this WCAG success criterion.
BotDetect Captcha is not inherently timed, but Captcha challenges it generates aren't valid indefinitely either. Since Captcha codes are persisted in Session state by default, if a visitor's time to complete the form exceeds the Session timeout – Captcha validation will fail even when the user enters the correct Captcha code. Also, the Captcha code timeout configuration option allows developers to specify an even shorter window of Captcha validity (to increase security against Captcha reuse attacks).
BotDetect tries to prevent the case when a visitor fails Captcha validation even when the correct code is input by using a "heart-beat" client-side script that keeps the Session alive (by automatically reloading Captcha images containing expired codes). Also, manually reloading the Captcha image (using the reload icon) will postpone the Session timeout, so visitors can use it to extend their time on form. And even if that doesn't help, visitors won't be prevented from completing the form – they'll just have to suffer the inconvenience of solving a new Captcha challenge.
Since the requirements for timed parameters affecting the Captcha window of validity will vary from form to form (depending on the level of Captcha security required, the number of other form fields and the expected time visitors will spend filling out the form etc.) – the desired Session timeout setting, Captcha code timeout, and automatic reloading of expired Captcha codes should be carefully considered and configured separately for each individual application.
In general, all time limits should be adjusted so even the slowest individuals with disabilities have plenty of time to fill out the form. Visitors might need more time because their physical speed and reaction time are reduced, their reading ability is impaired enough to make timed task comprehension harder, their low vision makes them take longer to find or read required information, or their assistive technology might be introducing a delay (hearing a web page pronounced takes longer than looking at it and reading). This WCAG success criterion is another standard that can only be met by web form developers – and BotDetect gives you all the options required to achieve the highest level of WCAG 2.0 conformance.
CAPTCHA and the WCAG 2.0 Success Criterion 2.2.2 – Pause, Stop, Hide
For moving, blinking, scrolling, or auto-updating information, all of the following are true: (Level A)
- Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
- Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
Only video Captcha or animated Captcha implementations are likely to need adjustment according to the "moving, blinking, scrolling" requirement.
Auto-updating is only likely to concern automatic reloading of expired Captcha codes, where it could be considered "essential" and therefore allowed – or BotDetect could be configured not to automatically reload expired Captcha images (but the significant degradation of the user experience for users spending more time on the more than the configured Session timeout should be noted and considered first – since it primarily helps exactly those visitors whom the "enough time" WCAG guideline is written to accommodate).
CAPTCHA and the WCAG 2.0 Success Criterion 2.2.3 – No Timing
Timing is not an essential part of the event or activity presented by the content, except for non-interactive synchronized media and real-time events. (Level AAA)
Just like the WAI Level A success criterion, this stricter requirement can only be met by web form developers and web server administrators – at increased risk of "Captcha reuse" attacks.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 2.2.3
To follow this WCAG technique, web form developers should carefully consider and configure their application Session timeout, as well as BotDetect code timeout and automatic expired Captcha reloading.
CAPTCHA and the WCAG 2.0 Success Criterion 2.2.4 – Interruptions
Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency. (Level AAA)
The intent of this Success Criterion is to allow users to turn off updates from the author/server except in emergencies. Emergencies would include civil emergency alert messages or any other messages that warn of danger to health, safety, or property, including data loss, loss of connection, etcetera.
A properly designed Captcha challenge will only interrupt the user when data loss is imminent – for example automatic reloading of expired Captcha codes will prevent the user from failing Captcha validation and possible data loss, as well as keep the visitors Session alive to prevent guaranteed data loss (which would require the user to re-fill the form and any possible previous ones from the start).
CAPTCHA and the WCAG 2.0 Success Criterion 2.2.5 – Re-authenticating
When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating. (Level AAA)
While important for general form accessibility, this WCAG criterion usually doesn't apply to Captcha challenges themselves. Captcha codes are by their nature one-off challenges, so the user input for the previous and possibly expired Captcha challenge won't be valid for a new one – and it makes no sense to preserve it.
Captcha challenge visitor status on the other hand, can be preserved: if the form security requirements allow it, web form developers can easily have the form remember that the user already solved the Captcha challenge and proved they are human (or, in more complicated scenarios, has a higher probability of being human), and not display new Captcha challenges for a certain period of time or number of interactions (to prevent automated abuse and a large number of interactions after human solving of a single Captcha challenge, using browser automation tools).
Furthermore, since the purpose of Captcha is to distinguish between human visitors and automated form submissions, in most cases successful visitor authentication will be sufficient to recognize human visitors. If bots using stolen user credentials are an issue, other types of form and application protection complementary to Captcha can be used (such as monitoring the number of actions each visitor performs and temporarily throttling access to suspicious visitors, similar to techniques used for DoS and DDoS protection).
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 2.2.5
If Captcha protection is added to a form that can invalidate the submission because of an expired authentication session, the form should remember user input and prevent data loss according to this WCAG technique.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 2.3 – Seizures
Do not design content in a way that is known to cause seizures.
Flashing visual content is known to induce dangerous and possibly life-threatening seizures in certain people, so WCAG conforming web pages must avoid the types of flash or screen flicker that are most likely to cause seizures. Typical Captcha implementations based on Captcha images are perfectly safe, but more dynamic forms of visual Captcha (such as animated Captcha or video Captcha) are potentially problematic – and must meet this WCAG objective to achieve conformance.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 2.3 Success Criteria
- Captcha & WCAG 2.0 SC 2.3.1 – Three Flashes or Below Threshold
- Captcha & WCAG 2.0 SC 2.3.2 – Three Flashes
CAPTCHA and the WCAG 2.0 Success Criterion 2.3.1 – Three Flashes or Below Threshold
Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. (Level A)
...
- "Blinking" refers to content that causes a distraction problem. Blinking can be allowed for a short time as long as it stops (or can be stopped)
- "Flashing" refers to content that can trigger a seizure (if it is more than 3 per second and large and bright enough). This cannot be allowed even for a second or it could cause a seizure. And turning the flash off is also not an option since the seizure could occur faster than most users could turn it off.
- Blinking usually does not occur at speeds of 3 per second or more, but it can. If blinking occurs faster than 3 per second, it would also be considered a flash.
CAPTCHA and the WCAG 2.0 Success Criterion 2.3.2 – Three Flashes
Web pages do not contain anything that flashes more than three times in any one second period. (Level AAA)
Each Captcha-protected form should be implemented to follow this WCAG technique.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 2.4 – Navigable
Provide ways to help users navigate, find content, and determine where they are.
Properly designed navigation mechanisms are necessary for all website visitors, but they are especially important when accommodating people with disabilities. Information about the visitor's current location on the site and possible destinations needs to be presented clearly, and conveniently available at all times.
Special care needs to be taken to make the navigation friendly to screen reader users, since converting site navigation information and links to speech presents unique challenges (repetitive navigation links and blocks which would get pronounced over and over again need to be easily skippable, links to available destinations need to be pronounced sequentially, etc.)
Captcha validation does not usually interact with site navigation in any manner, but care should be taken that the Captcha-protected form is easily navigable according to this accessibility objective. And of course, intra-form navigability is as important to achieving WCAG conformance as inter-page navigation of the entire site.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 2.4 Success Criteria
- Captcha & WCAG 2.0 SC 2.4.1 – Bypass Blocks
- Captcha & WCAG 2.0 SC 2.4.2 – Page Titled
- Captcha & WCAG 2.0 SC 2.4.3 – Focus Order
- Captcha & WCAG 2.0 SC 2.4.4 – Link Purpose (In Context)
- Captcha & WCAG 2.0 SC 2.4.5 – Multiple Ways
- Captcha & WCAG 2.0 SC 2.4.6 – Headings and Labels
- Captcha & WCAG 2.0 SC 2.4.7 – Focus Visible
- Captcha & WCAG 2.0 SC 2.4.8 – Location
- Captcha & WCAG 2.0 SC 2.4.9 – Link Purpose (Link Only)
- Captcha & WCAG 2.0 SC 2.4.10 – Section Headings
CAPTCHA and the WCAG 2.0 Success Criterion 2.4.1 – Bypass Blocks
A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)
Most Captcha implementations won't use repeating blocks of content, and will be operable enough to screen reader visitors to meet this WCAG success criterion. Of course, the website and form the Captcha challenge is placed on must still meet it to achieve WCAG conformance.
CAPTCHA and the WCAG 2.0 Success Criterion 2.4.2 – Page Titled
Web pages have titles that describe topic or purpose. (Level A)
This WCAG success criterion doesn't apply to Captcha protection, but to the page it is placed on. Consequentially, it will only be relevant to Captcha protection when the Captcha challenge is placed on a separate page of its own for some reason. Either way, providing a page title appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer.
CAPTCHA and the WCAG 2.0 Success Criterion 2.4.3 – Focus Order
If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)
Captcha validation placed on a form should meet the requirements of an operable focus order, just like all other form elements should preserve their logical sequence. This keeps the form accessible to users navigating the form using sequential interaction modes (such as keyboard or voice input).
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 2.4.3
All Html elements in BotDetect-generated markup follow this WCAG technique, and their DOM order matches the visual one.
When Captcha protection is added to a form, it should be tested to have a logical tab order allowing convenient form navigation. BotDetect implements a customizable starting tabindex for interactive Captcha elements, making it easy to follow this WCAG technique.
CAPTCHA and the WCAG 2.0 Success Criterion 2.4.4 – Link Purpose (In Context)
The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)
Any links involved in the user's interaction with Captcha should meet this navigability criterion. Examples include links to Captcha-specific instructions on a separate page, or action links such as Captcha controls.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 2.4.4
- G91: Providing link text that describes the purpose of a link
- H30: Providing link text that describes the purpose of a link for anchor elements
All textual link elements used in BotDetect-generated markup follow this WCAG technique and include customizable link text.
All link elements used in BotDetect-generated markup follow this WCAG technique and include customizable link titles.
CAPTCHA and the WCAG 2.0 Success Criterion 2.4.5 – Multiple Ways
More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. (Level AA)
This WCAG success criterion doesn't apply to Captcha protection, but to the page it is placed on – so providing multiple navigation mechanisms appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer.
CAPTCHA and the WCAG 2.0 Success Criterion 2.4.6 – Headings and Labels
Headings and labels describe topic or purpose. (Level AA)
Appropriate page headings will rarely factor in Captcha accessibility evaluation, but must be considered for the Captcha-protected forms. On the other hand, an appropriate label for the Captcha user input is crucial to achieving Captcha WCAG conformance.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 2.4.6
When adding BotDetect Captcha protection to a form, the Captcha solving instructions should be provided in a label element associated with the Captcha code textbox to follow this WCAG technique.
CAPTCHA and the WCAG 2.0 Success Criterion 2.4.7 – Focus Visible
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)
After ensuring the visitor can fully interact with the Captcha challenge and successfully complete it using only the keyboard, this further improvement should be considered to maximize accessibility of the Captcha implementation.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 2.4.7
- G149: Using user interface components that are highlighted by the user agent when they receive focus
- G165: Using the default focus indicator for the platform so that high visibility default focus indicators will carry over
- C15: Using CSS to change the presentation of a user interface component when it receives focus
The BotDetect stylesheet includes style declarations which add a thin grey outline to focused elements the user can interact with (BotDetect links/icons). Each form developer can also customize the appearance of this indicator by overriding the BotDetect stylesheet.
CAPTCHA and the WCAG 2.0 Success Criterion 2.4.8 – Location
Information about the user's location within a set of Web pages is available. (Level AAA)
This WCAG success criterion doesn't apply to Captcha protection, but to the page it is placed on – so providing a site location indicator appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer.
CAPTCHA and the WCAG 2.0 Success Criterion 2.4.9 – Link Purpose (Link Only)
A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general. (Level AAA)
Just like the WAI Level A success criteria, this stricter requirement must be considered for any links used as part of the Captcha challenge and visitor interaction.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 2.4.9
- H30: Providing link text that describes the purpose of a link for anchor elements
- G91: Providing link text that describes the purpose of a link
- H33: Supplementing link text with the title attribute
All link elements used in BotDetect-generated markup follow this WCAG technique and include customizable link text and titles.
CAPTCHA and the WCAG 2.0 Success Criterion 2.4.10 – Section Headings
Section headings are used to organize the content. (Level AAA)
This WCAG success criterion doesn't apply to Captcha protection, but to the page it is placed on – so providing section headings appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer.
CAPTCHA and the WCAG 2.0 Accessibility Principle 3: Understandable
Information and the operation of user interface must be understandable.
Before a visitor can successfully use or interact with a web page, they must obviously first be able to understand it. A well designed web form will always provide all information in a readable and predictable manner designed to avoid user confusion – but to meet accessibility standards it also needs to remain understandable when transformed by assistive technology and provide appropriate input assistance.
Focusing on Captcha understandability, accessibility can be achieved by using appropriate form labels, instructions and help, as well as clear feedback through error, success and progress indicators. All of these elements need to be designed to remain understandable to individuals with disabilities, regardless of the assistive technology they use to access the form. Only then can a Captcha implementation conform to WCAG standards.
CAPTCHA and the WCAG 2.0 Accessibility Principle 3 Guidelines
- Captcha & WCAG 2.0 guideline 3.1 – Readable
- Captcha & WCAG 2.0 guideline 3.2 – Predictable
- Captcha & WCAG 2.0 guideline 3.3 – Input Assistance
CAPTCHA and the WCAG 2.0 Accessibility Guideline 3.1 – Readable
Make text content readable and understandable.
Textual content is the most accessible form of web content – but it also requires careful handling to ensure conformance to WCAG standards. Metadata about text language and direction is necessary to allow browsers and assistive technologies to interpret text correctly. Considering how text content is likely to get transformed into alternative visual, audible, or tactile forms, text readability can only be properly evaluated with such transformations in mind. And of course, cognitive abilities of the target audience should always dictate text complexity and expression choices.
Core elements of Captcha challenges are usually non-text content, but should always be accompanied with appropriate and understandable textual instructions, descriptions, feedback etc. – and WCAG readability objectives must be considered for such Captcha companion content.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 3.1 Success Criteria
- Captcha & WCAG 2.0 SC 3.1.1 – Language of Page
- Captcha & WCAG 2.0 SC 3.1.2 – Language of Parts
- Captcha & WCAG 2.0 SC 3.1.3 – Unusual Words
- Captcha & WCAG 2.0 SC 3.1.4 – Abbreviations
- Captcha & WCAG 2.0 SC 3.1.5 – Reading Level
- Captcha & WCAG 2.0 SC 3.1.6 – Pronunciation
CAPTCHA and the WCAG 2.0 Success Criterion 3.1.1 – Language of Page
The default human language of each Web page can be programmatically determined. (Level A)
This WCAG success criterion doesn't apply to Captcha protection, but to the page it is placed on – so providing language metadata appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer.
CAPTCHA and the WCAG 2.0 Success Criterion 3.1.2 – Language of Parts
The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA)
This WCAG success criterion doesn't apply to Captcha protection, but to the page it is placed on – so providing language metadata appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer. Of course, if the page contains content in several different languages, Captcha solving instructions and other Captcha-specific textual content should be localized for the main language of the page. This also includes things like Captcha image alt text and Captcha control link titles.
CAPTCHA and the WCAG 2.0 Success Criterion 3.1.3 – Unusual Words
A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon. (Level AAA)
Since the term "CAPTCHA" itself can be considered as "jargon", if the Captcha-protected page includes it in text, it should also include a definition or explanation in on-page or linked Captcha help to maximize readability to all visitors and achieve highest levels of WCAG conformance.
CAPTCHA and the WCAG 2.0 Success Criterion 3.1.4 – Abbreviations
A mechanism for identifying the expanded form or meaning of abbreviations is available. (Level AAA)
This WCAG success criterion doesn't apply to Captcha protection, but to the page it is placed on – so providing abbreviation meaning appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer.
CAPTCHA and the WCAG 2.0 Success Criterion 3.1.5 – Reading Level
When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available. (Level AAA)
This WCAG success criterion doesn't apply to image Captcha protection (which should use random alphanumeric codes and not words that require reading comprehension), but to the page it is placed on – so providing simple enough text appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer. The simpler the language and the lower reading ability required to understand it, the wider the target audience that can successfully use the page.
CAPTCHA and the WCAG 2.0 Success Criterion 3.1.6 – Pronunciation
A mechanism is available for identifying specific pronunciation of words where meaning of the words, in context, is ambiguous without knowing the pronunciation. (Level AAA)
This WCAG success criterion doesn't apply to Captcha protection, but to the page it is placed on – so providing unambiguous pronunciation appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 3.2 – Predictable
Make Web pages appear and operate in predictable ways.
To make individual web pages and websites easily understandable, transitions between multiple pages as well as the behavior of individual page elements should also be predictable. This can be as simple as always keeping universal website elements (such as navigation) in the same logical and visual position on the page – or as involved as testing that each user interface interaction only changes the page context in a manner appropriate for screen reader users (who experience the site strictly sequentially). Captcha implementations usually don't present any unique challenges to meeting this WCAG accessibility objective.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 3.2 Success Criteria
- Captcha & WCAG 2.0 SC 3.2.1 – On Focus
- Captcha & WCAG 2.0 SC 3.2.2 – On Input
- Captcha & WCAG 2.0 SC 3.2.3 – Consistent Navigation
- Captcha & WCAG 2.0 SC 3.2.4 – Consistent Identification
- Captcha & WCAG 2.0 SC 3.2.5 – Change on Request
CAPTCHA and the WCAG 2.0 Success Criterion 3.2.1 – On Focus
When any component receives focus, it does not initiate a change of context. (Level A)
Like all other user interface elements on the form, components constituting the Captcha challenge as well as other Captcha-related elements should adhere to this success criterion and avoid unpredictably submitting the form or switching focus to other windows or elements when they receive focus. When all form elements behave in an expected, default manner, users can predict their behavior before interacting with them. This allows the page to achieve the WCAG accessibility standards of understability.
Note that this requirement only applies to elements receiving focus – for example, BotDetect automatically clearing text input and switching focus to it when a new Captcha code is requested by activating the Captcha reload button is different because it involves activating the UI element instead of merely giving it focus. And even then, if automatic previous input clearing and focusing are deemed too unpredictable to visitors with cognitive impairments, they can easily be switched off in BotDetect configuration.
CAPTCHA and the WCAG 2.0 Success Criterion 3.2.2 – On Input
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)
In common forms of Captcha challenges, only entering text in a text box qualifies as "changing its setting". In order to implement WCAG-conformant Captcha validation, user's interaction with the Captcha text box should never initiate a "change of context" (submit the form automatically, open new browser windows or switch focus to an unrelated user interface component).
CAPTCHA and the WCAG 2.0 Success Criterion 3.2.3 – Consistent Navigation
Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. (Level AA)
This WCAG success criterion doesn't apply to Captcha protection, but to the page it is placed on – so providing consistent site navigation appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer.
CAPTCHA and the WCAG 2.0 Success Criterion 3.2.4 – Consistent Identification
Components that have the same functionality within a set of Web pages are identified consistently. (Level AA)
This WCAG success criterion doesn't apply to Captcha protection, but to the page it is placed on – so providing consistent component identification appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer.
CAPTCHA and the WCAG 2.0 Success Criterion 3.2.5 – Change on Request
Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA)
Most Captcha implementations don't use any kind of "changes of context" not initiated by the user, so this WCAG criterion doesn't apply. Some aspects of a particular Captcha implementation might however involve such changes, and they should be reviewed for accessibility and conformance to this WCAG success criteria. For example, BotDetect Captcha automatic reloading of expired Captcha codes won't switch focus to the Captcha textbox even if automatic textbox focusing on reload is enabled – precisely to avoid potentially unpredictable context changes and meet WCAG Level AAA standards. Since we can't know which part of the form will the user be engaged with when automatic reloading triggers, we can't switch focus to the Captcha textbox without potentially interrupting their workflow, breaking concentration, and confusing them. To conform to WCAG accessibility requirements, such a context change is avoided.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 3.3 – Input Assistance
Help users avoid and correct mistakes.
Website interactions often provide some form of feedback when the user input results in an error, progress change, or task completion. While clear interaction feedback is important to all website visitors, it needs to be carefully designed to accommodate the special needs of disabled individuals. Making Captcha validation WCAG conformant requires that appropriate input assistance is provided during the visitors' interaction with the Captcha challenge.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 3.3 Success Criteria
- Captcha & WCAG 2.0 SC 3.3.1 – Error Identification
- Captcha & WCAG 2.0 SC 3.3.2 – Labels or Instructions
- Captcha & WCAG 2.0 SC 3.3.3 – Error Suggestion
- Captcha & WCAG 2.0 SC 3.3.4 – Error Prevention (Legal, Financial, Data)
- Captcha & WCAG 2.0 SC 3.3.5 – Help
- Captcha & WCAG 2.0 SC 3.3.6 – Error Prevention (All)
CAPTCHA and the WCAG 2.0 Success Criterion 3.3.1 – Error Identification
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A)
When the visitor fails to provide any input required to engage with the Captcha challenge, or their input is not correct (i.e. is insufficient to serve as proof of human interaction), the Captcha validation failure must result in error feedback that is properly identified and described to the visitor. Most Captcha implementations will return the result of Captcha validation as a boolean indicator, and it is the responsibility of web form developers to use that result to update the form status with appropriate feedback to meet this WCAG success criterion and facilitate Captcha understandability.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 3.3.1
When adding Captcha protection to a form, the Captcha code textbox should have a text clearly identifying it as a required field after Captcha validation fails or the Captcha code textbox is left empty.
After adding server-side Captcha validation to a form, Ajax Captcha validation can be added using a variety of different client-side approaches and frameworks.
Web form developers should follow this WCAG technique to implement WCAG compliant client-side Captcha validation.
Each Captcha-protected form should be implemented to follow this WCAG technique.
When Captcha validation succeeds, the visitor can be shown a success indicator. If other form fields still contain errors that prevent the form from being submitted, Captcha validation can be omitted since the visitor has already solved it and proved that they are human. When the form as a whole is successfully submitted, the visitor should be notified appropriately.
CAPTCHA and the WCAG 2.0 Success Criterion 3.3.2 – Labels or Instructions
Labels or instructions are provided when content requires user input. (Level A)
To meet the requirements of this WCAG success criterion, appropriate labels and Captcha solving instructions must be provided and associated with input elements of the Captcha challenge.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 3.3.2
When adding BotDetect Captcha protection to a form, the Captcha solving instructions should be provided in a label element associated with the Captcha code textbox to follow this WCAG technique.
Each Captcha-protected form should be implemented to follow this WCAG technique.
When adding Captcha protection to a form, the Captcha code textbox should have a text clearly identifying it as a required field after Captcha validation fails or the Captcha code textbox is left empty.
CAPTCHA and the WCAG 2.0 Success Criterion 3.3.3 – Error Suggestion
If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)
The nature of Captcha validation (testing for a human presence by challenging unique properties of human perception and cognition), no suggestions beyond appropriate Captcha solving instructions can automatically be provided without jeopardizing the security of Captcha validation vs. automated attempts. Other form input elements must of course adhere to this requirement to meet WCAG standards of understability.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 3.3.3
The WCAG techniques necessary to meet this criterion are the same as used for error identification.
CAPTCHA and the WCAG 2.0 Success Criterion 3.3.4 – Error Prevention (Legal, Financial, Data)
For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (Level AA)
- Reversible: Submissions are reversible.
- Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
- Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
This WCAG success criterion doesn't apply to Captcha protection, but to the page it is placed on – so providing error prevention mechanisms appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 3.3.4
After adding server-side Captcha validation to a form, Ajax Captcha validation can be added using a variety of different client-side approaches and frameworks.
When adding Captcha protection to a form, the Captcha code textbox should have a text clearly identifying it as a required field after Captcha validation fails or the Captcha code textbox is left empty. When the form as a whole is successfully submitted, the visitor should be notified appropriately.
CAPTCHA and the WCAG 2.0 Success Criterion 3.3.5 – Help
Context-sensitive help is available. (Level AAA)
Context-sensitive help for Captcha challenges (with detailed instructions, descriptions and explanations which go beyond the scope of Captcha-focused labels necessary for achieving WAI Level A conformance) can be provided by embedding a Captcha help link within the challenge. BotDetect is engineered to make this easy using the Captcha help page configuration option, allowing you to achieve WAI Level AAA conformance of your Captcha-protected forms.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 3.3.5
General help for the whole form is a responsibility of the form developer, and a Captcha-specific help link can be embedded directly within the Captcha challenge using BotDetect help page functionality.
Each Captcha-protected form should be implemented to follow this WCAG technique.
CAPTCHA and the WCAG 2.0 Success Criterion 3.3.6 – Error Prevention (All)
For Web pages that require the user to submit information, at least one of the following is true: (Level AAA)
- Reversible: Submissions are reversible.
- Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
- Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
This WCAG success criterion doesn't apply to Captcha protection, but to the page it is placed on – so providing error prevention mechanisms appropriate enough to achieve WCAG conformance is the sole responsibility of the form developer. Captcha validation will naturally allow multiple solving attempts, so disabled users who might need several attempts to provide the correct input won't be denied the opportunity to do so.
CAPTCHA and the WCAG 2.0 Accessibility Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
A web page can only be considered accessible if it displays and works properly for the visitor regardless of the client browser or device she uses. Testing web pages on a wide variety of target clients (including various form of assistive technologies) is obviously recommended – but to maximize compatibility with any future or exotic user agents, web pages should also be implemented to adhere to accepted standards such as valid Html according to specification.
Captcha implementation robustness should also be carefully tested and validated to conform to WCAG accessibility requirements.
CAPTCHA and the WCAG 2.0 Accessibility Principle 4 Guidelines
CAPTCHA and the WCAG 2.0 Accessibility Guideline 4.1 – Compatible
Maximize compatibility with current and future user agents, including assistive technologies.
Assistive technologies used by disabled visitors to facilitate web access are not a panacea that can deal with any kind of web content – web content needs to carefully implemented not to break, circumvent, or confound assistive technology functionality.
To maximize content compatibility with the widest possible range of client browsers, devices and assistive technologies (making it accessible to the widest possible user base), it should follow known standards and conventions. The fact that a particular web page or Captcha implementation works with current assistive technologies is not enough – full WCAG conformance also requires that it tries to minimize any possible incompatibilities with future assistive technology advances.
CAPTCHA and the WCAG 2.0 Accessibility Guideline 4.1 Success Criteria
CAPTCHA and the WCAG 2.0 Success Criterion 4.1.1 – Parsing
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)
Elements constituting the Captcha challenge should adhere to this WCAG criterion just like all other form elements.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 4.1.1
- G134: Validating Web pages
- G192: Fully conforming to specifications
- H88: Using HTML according to spec
- H74: Ensuring that opening and closing tags are used according to specification
- H93: Ensuring that id attributes are unique on a Web page
- H94: Ensuring that elements do not contain duplicate attributes
- H75: Ensuring that Web pages are well-formed
BotDetect produces valid XHTML 1.1 Strict markup to meet the requirements of this WCAG success criterion.
CAPTCHA and the WCAG 2.0 Success Criterion 4.1.2 – Name, Role, Value
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)
When standard controls from accessible technologies are used, this process is straightforward. If the user interface elements are used according to specification the conditions of this provision will be met.
CAPTCHA Implementation Satisfying the WCAG 2.0 Conformance Success Criterion 4.1.2
- H91: Using HTML form controls and links
- H44: Using label elements to associate text labels with form controls
- H88: Using HTML according to spec
Each Captcha-protected form should be implemented to follow these WCAG techniques.
WCAG 2.0 CAPTCHA: Conclusions & Further Reading
Making Captcha validation WCAG 2.0 conformant requires careful consideration and adjustment from both web form developers and Captcha developers: ensuring that all form interactions (Captcha included) follow WCAG guidelines and meet WCAG success criteria of accessibility is far from trivial.
Unlike most other Captcha implementations, the BotDetect Captcha component has been engineered to meet these requirements and allow web form developers easy access to highest levels of WCAG conformance. If you want to check how does BotDetect live up to these high standards, test Captcha accessibility in the BotDetect online demo.
Of course, the accessibility of a form using BotDetect can only be considered for the web page as a whole. So it is equally possible to use BotDetect in both WCAG 2.0 conformant and non-conformant ways. BotDetect gives you all the means necessary to make your forms conform to WCAG 2.0, but can't guarantee they will always be conformant. Because of this, it is the responsibility of users to ensure WCAG 2.0 conformance for each page using the BotDetect Captcha component.
Strict Standards: CAPTCHA Accessibility
- Strict standards: Introduction to Captcha accessibility
- Section 508 Captcha: How to make Captcha comply with Access Board Section 508 standards
- WCAG Captcha: How to make Captcha conform to W3C WCAG 2.0 standards
- ADA Captcha: Does Captcha need to comply with the ADA standards?
Current BotDetect Versions
-
BotDetect ASP.NET CAPTCHA
2019-07-22v4.4.2 -
BotDetect Java CAPTCHA
2019-07-22v4.0.Beta3.7 -
BotDetect PHP CAPTCHA
2019-07-22v4.2.5
