Source: https://captcha.com/accessibility/section508-captcha.html?cst=bd3config
Timestamp: 2020-03-31 22:27:35
Document Index: 469387866

Matched Legal Cases: ['§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194', '§1194']

After preventing automated form submissions using Captcha validation, it is a common sense Captcha best practice to make it as accessible as possible to actual human visitors interacting with the form. To that end, there is a number of Web accessibility standards and guidelines that a professional Captcha implementation should comply with.
Among them, the Access Board Section 508 Standards for Electronic and Information Technology (abbreviated as "Section 508") are unique on two significant accounts:
To explain how to implement a Section 508 compliant Captcha, we'll examine the current Access Board Section 508 standards, identify those that can possibly apply to a web form protected against automated submissions with a Captcha human interaction proof, and elaborate how to meet them.
Captcha & Section 508 Subpart A: General
Captcha & Section 508 Subpart B: Technical standards for web-based Intranet and Internet information and applications
Synchronized multimedia alternatives
Readability without style sheets
Server-side image map navigation
Providing client-side image maps
Identifying row and column headers of data tables
Associating data and header cells of data tables
Providing appropriate frame titles
Avoiding screen flicker
Text-only alternatives for exceptional pages
Accessibility of client-side dynamic content
Linking to required plugins and applets
Form accessibility to assistive technology
Timed response extension
Captcha & Section 508 Subpart C: Functional performance criteria
Functional without vision
Functional with low vision
Functional without hearing
Functional with low hearing
Functional without speech
Functional with low motor ability
Captcha & Section 508 Subpart D: Information, documentation, and support
The content provided on this page is meant as general information only, and is not intended as legal advice of any kind. Although we tried to make sure this information is accurate and useful, we are not a law firm and are not acting as your attorney. If you want professional advice or assurance that this information and your interpretation of it is correct, please consult a lawyer familiar with US Federal law.
CAPTCHA and the Section 508 Subpart A: General
Subpart A of Access Board Section 508 doesn't contain any actual technical standards or criteria that need to be met, but still introduces several important concerns that affect Captcha validation of web form submissions.
Captcha & Section 508 Purpose
Captcha & Section 508 Application
Captcha & Section 508 Exceptions
CAPTCHA and the Section 508 §1194.1 – Purpose
The purpose of Section 508 interpreted in the context of a web form including Captcha validation is clear: care should be taken that individuals with disabilities are not excluded from form functionality. This can apply both to internal forms accessed by Federal employees over Intranet, and public forms accessed by the general population over Internet.
The main accessibility issue of Captcha tests is that they usually depend on image functionality and require visual acuity to solve – which can make them unfairly hard or impossible for visually impaired individuals. Obviously, a Captcha implementation that doesn't provide an alternative designed to allow blind people access to form functionality can not be considered Section 508 compliant.
CAPTCHA and the Section 508 §1194.2 – Application
(1) When compliance with the provisions of this part imposes an undue burden, agencies shall provide individuals with disabilities with the information and data involved by an alternative means of access that s the individual to use the information and data.
Section 508 standards apply to all web forms developed, procured, maintained or used by Federal agencies. If those forms include Captcha validation, it must either be implemented in a manner allowing disabled individuals to pass it (for example, using audio Captcha so not to require vision and discriminate against the blind), or have clear instructions how such individuals can access equivalent functionality (for example, providing a phone number which blind people can call and have a Federal employee help them get the information or service that would otherwise be unfairly denied).
In case the web form or any part of it is developed by an external provider, Section 508 standards still apply. If the web form functionality is implemented using off-the-shelf 3rd party products (e.g. commercial form templates), only products that meet the most Section 508 standards available must be used. If the web form functionality is implemented using products custom developed for the agency by contractors, Section 508 standards must be included in the contract requirements. If the Captcha validation is implemented using off-the-shelf Captcha components, libraries or services, only Captcha products that best meet Section 508 standards must be chosen.
CAPTCHA and the Section 508 §1194.3 – General Exceptions
Fundamentally, Captcha tests are implemented to prevent automated form submissions, and must require a proof of human interaction for the protected form action. Section 508 standards mandate that Captcha validation is implemented in a manner that doesn't discriminate against disabled individuals – but don't require that Captcha validation be omitted or implemented in a manner that would compromise security against automated form submissions.
CAPTCHA and the Section 508 Subpart B, §1194.22: Technical Standards for Web-Based Intranet and Internet Information and Applications
Subpart B of Access Board Section 508 is the most important one to consider when evaluating Section 508 compliance of a specific technology. Since Captcha validation is mainly used in web applications, $1194.22 contains the most relevant Subpart B standards which apply to Captcha implementations.
Captcha & text equivalents for every non-text element
Captcha & synchronized multimedia alternatives
Captcha & use of color to convey information
Captcha & readability without style sheets
Captcha & server-side image map navigation
Captcha & providing client-side image maps
Captcha & identifying row and column headers of data tables
Captcha & associating data and header cells of data tables
Captcha & providing appropriate frame titles
Captcha & avoiding screen flicker
Captcha & text-only alternatives for exceptional pages
Captcha & accessibility of client-side dynamic content
Captcha & linking to required plugins and applets
Captcha & form accessibility to assistive technology
Captcha & skipping repetitive navigation links
Captcha & timed response extension
CAPTCHA and the Section 508 §1194.22 (a) – Text Equivalents for Every Non-Text Element
General CAPTCHA Compliance with Section 508 Standards
Captcha validation typically includes several non-text elements: Captcha images, Captcha sounds, and icons/buttons for Captcha controls. While Captcha controls can and should include a text alternative, Captcha images and sounds are excluded from this requirement by §1194.3. To wit, providing a plain text alternative with the Captcha image or sound representation would defeat its primary purpose, since bots could simply read that text alternative from page source and automatically bypass Captcha protection.
As such a change would defeat the fundamental nature of Captcha protection (detecting bots by testing for unique properties of human vision and sense of hearing), not providing exact textual equivalents for Captcha images and sounds doesn't impact the Section 508 compliance of Captcha implementations.
The main purpose of text equivalents for all non-text web page elements is improved accessibility to visually impaired individuals: screen readers and other assistive technology can pronounce these text equivalents of images and other visual elements imperceptible to the blind. Since Captcha audio serves the same purpose when it comes to Captcha images, providing an audio Captcha alternative is crucial to complying with the intent of this Section 508 rule.
If your form includes any other non-text elements (e.g. visual error/success/progress indicators), you should of course adhere to this rule and provide appropriate text equivalents for them.
BotDetect CAPTCHA Compliance with Section 508 Standards
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.
BotDetect also generates descriptive alt attributes as text equivalents for images used as Captcha sound playback and Captcha reloading controls – and those text equivalents are easily customized to fit any form use case or language requirements.
Since all Html markup elements generated by BotDetect have text equivalents or alternate representations which don't require sight, BotDetect Captcha protection complies with the requirements of Section 508 $1194.22 (a).
CAPTCHA and the Section 508 §1194.22 (b) – Synchronized Multimedia Alternatives
Since Captcha images and sounds qualify as "multimedia presentation", this rule can be interpreted to mean that Captcha sounds should be synchronized with Captcha images – i.e. contain the same Captcha code. Whether users read the code from the Captcha image or hear it it from the audio Captcha pronunciation, the code used to verify that the visitor is human should be the same to avoid any confusion.
While this is generally the case, some Captcha implementations use a different content for Captcha images and sounds, for example using words from books in images but fragments from radio shows in sounds. Such Captcha implementations are in conflict with Section 508 $1194.22 (b) and can consequentially not be considered Section 508 compliant.
BotDetect always uses the same randomly generated code in Captcha images and audio, satisfying the requirements of Section 508 $1194.22 (b).
CAPTCHA and the Section 508 §1194.22 (c) – Use of Color to Convey Information
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.
BotDetect audio Captcha provides an alternative that color-blind individuals can use to pass Captcha validation, preventing any discrimination of such visitors regardless of the color scheme used in Captcha images.
BotDetect Captcha reloading functionality allows visitors to request a new Captcha image if the current one is indecipherable; since BotDetect randomly switches between 60 image styles by default (a number of which use a grayscale color scheme, and only a small minority of which rely only on the ability to distinguish colors which could possibly be problematic to color-blind individuals), such users have good chances of getting a Captcha image they can read within a few clicks of the "Change the Captcha code" button even without Captcha audio.
BotDetect allows site owners to fully adjust the color scheme used for Captcha image generation – so in cases where maximum readability of Captcha images to color-blind visitors is absolutely required, it can easily be achieved.
Considering the above, BotDetect is clearly designed not to require the ability to distinguish color to pass Captcha validation, complying with Section 508 $1194.22 (c).
CAPTCHA and the Section 508 §1194.22 (d) – Readability Without Style Sheets
This rule is intended to ensure that all web forms function properly on different client browsers and devices, not all of which interpret and apply CSS rules (especially among assistive technologies used by disabled individuals). If the sequence of form fields is important, that sequence should also apply to Html markup elements (so the visual element order matches the logical one), instead of relying on style sheets to place the elements in desired order.
In Captcha validation implementations, this applies to Captcha elements such as the label prompting users to retype the code from the Captcha picture, the text box where user input of the Captcha code goes, as well as the Captcha images themselves and the associated controls. When developing the form, modern browsers provide a useful aid to check this requirement through the option to disable CSS styles altogether – and you should use it to check compliance with Section 508 $1194.22 (d).
The visual order of BotDetect elements matches the logical order of generated markup sections, ensuring that BotDetect Captcha functionality suffers minimal impact when accessed through a client without CSS support. While BotDetect will look somewhat less pretty in such cases (with visible thick borders around control links, and the Captcha reloading and sound playback controls displayed below the Captcha image instead of beside it), it will remain fully functional according to Section 508 $1104.22 (d) requirements.
CAPTCHA and the Section 508 §1194.22 (e) – Server-Side Image Map Navigation
Most Captcha implementations don't use server-side image maps, so this Section 508 rule doesn't apply. If your Captcha implementation or form does use server-side image maps for some reason, you should of course consider it carefully to achieve Section 508 compliance.
CAPTCHA and the Section 508 §1194.22 (f) – Providing Client-Side Image Maps
Most Captcha implementations don't use any kind of image maps, so this Section 508 rule doesn't apply. If your Captcha implementation or form does use image maps for some reason, you should of course consider it carefully to achieve Section 508 compliance.
CAPTCHA and the Section 508 §1194.22 (g) – Identifying Row and Column Headers of Data Tables
Most Captcha implementations don't use data tables, so this Section 508 rule doesn't apply. If your Captcha implementation or form does use data tables for some reason, you should of course consider it carefully to achieve Section 508 compliance.
CAPTCHA and the Section 508 §1194.22 (h) – Associating Data and Header Cells of Data Tables
CAPTCHA and the Section 508 §1194.22 (i) – Providing Appropriate Frame Titles
Most Captcha implementations don't use frames, so this Section 508 rule doesn't apply. If your Captcha implementation or form does use frames for some reason, you should of course consider it carefully to achieve Section 508 compliance.
CAPTCHA and the Section 508 §1194.22 (j) – Avoiding Screen Flicker
Classic image-based Captcha implementations don't cause any noticeable screen flicker at all, and satisfy the requirements of Section 508 $1194.22 (j). However, Captcha protection which uses animated images or Captcha video can cause screen flicker and consequentially be problematic to seizure-prone individuals. Since flicker-induced seizures are a very serious (and potentially life-threatening) issue, any video Captcha or animated Captcha implementations should be scrutinized closely for compliance with this Section 508 standard.
BotDetect uses classic image Captcha challenges, and doesn't cause any noticeable screen flicker at all.
CAPTCHA and the Section 508 §1194.22 (k) – Text-Only Alternatives for Exceptional Pages
As we have shown that it's quite possible to implement Captcha validation which complies with the antecedent provisions of Section 508, this exception is not relevant in most cases. And since the primary function of Captcha protection is to verify a human presence, it is hard to imagine an adequate "text-only page, with equivalent information or functionality".
It could perhaps be a page with a phone number which individuals can call to have a human operator provide help (which would eliminate many of the automation benefits of having a web form in the first place, and verifying that only disabled individuals use it would be non-trivial; possibly approaching "undue burden" territory).
However, it's hard to imagine a scenario in which using a Section 508 non-compliant Captcha implementation with such a labor-intensive workaround would make an acceptable replacement for a properly Section 508 compliant Captcha. Of course, starting with a compliant implementation and then adding a special text-only page providing relevant Captcha information to go the extra mile in improving the user experience is a different matter.
BotDetect complies with Section 508 requirements and doesn't require a special page to meet minimum accessibility standards. If a special Captcha-focused info page is desired to provide detailed explanations and instructions to visitors who could benefit from them, BotDetect configurable help page functionality can be used to clearly associate such a page on your website with the Captcha challenge.
CAPTCHA and the Section 508 §1194.22 (l) – Accessibility of Client-Side Dynamic Content
In general, the Captcha workflow should always first be implemented without using any client-side scripting, for one obvious reason: most bots don't execute JavaScript at all, and would bypass any purely client-side Captcha protection effortlessly. So, Captcha functionality should use client-side code only as an enhancement (in usability and ease of use) on top of fully functional server-side code. This means well-implemented Captcha validation should never break this Section 508 standard.
For example, Ajax Captcha validation should always be considered a small usability improvement over server-side Captcha validation (which also works for clients which don't execute client-side scripts at all). If this is the case, no crucial content or interface elements will naturally rely on scripting functionality (which could possibly discriminate against certain assistive technologies used by disabled individuals). To ensure Section 508 compliance, all web forms should be tested with JavaScript disabled, and checked for compliance with this rule.
This also means any Captcha tests or "tests" which rely on client-side functionality to work at all (such as various "drag and drop Captcha", "Captcha slider", "Captcha game" etc. variants) are either completely ineffective in stopping bots (if the form can be successfully submitted without JavaScript – meaning, without the Captcha-like "protection" at all) or non-compliant with Section 508 standards (since requiring JavaScript for crucial web form interaction makes it inaccessible to visitors using assistive technology with no client-side support available).
Furthermore, descriptive labels should be provided for the client-side script triggers, so more advanced assistive technology which does support JavaScript execution can properly inform the user about available dynamic functionality. These labels are required so disabled visitors don't trigger unwanted dynamic behavior accidentally, considering how their interaction with the form will often differ from the average user workflow. For example, visually impaired visitors using screen readers will only experience the form sequentially as it is read to them: dynamic changes in previous form sections will go unnoticed until the form is re-read.
BotDetect Captcha display and validation is tested to work even with JavaScript disabled. While this does cause a slight degradation in user experience (since e.g. dynamic sound playback in page background and changing the Captcha code without reloading the whole page can only be implemented in client-side code), it never impacts the core Captcha functionality or prevents the user from fully interacting with the Captcha test (since Captcha audio can then be delivered as a file download, and a new Captcha code can be accessed by reloading the form).
For those dynamic elements that do get created or changed using client-side scripting (seamless audio Captcha playback and on-demand Captcha image reloading), BotDetect uses clearly labeled controls (image links with screen reader friendly alt descriptions, which can also be customized for each form or visitor as needed). This makes BotDetect Captcha compliant with the Section 508 §1194.22 (l) standard.
CAPTCHA and the Section 508 §1194.22 (m) – Linking to Required Plugins and Applets
While standard image Captcha implementations work without requiring any additional applets or plugins, Captcha equivalents in other media formats or specific technologies might require specialized plugins. For example, video Captcha variants might need a video player plugin installed and configured in older browsers, while Captcha implemented as a Java applet, a Flash Captcha, Silverlight Captcha or Unity Player Captcha interaction will obviously require the respective browser plugin.
In general, using a plugin-dependent Captcha as the main form of user interaction is a bad idea – since the default implementation should work across the broadest range of client browsers and devices possible, and plugin requirements always shrink the supported user base. If a plugin-dependent Captcha variant is necessary, it will have a much lower impact on user friendliness and form accessibility if it's used as an optional alternative targeting a smaller user base.
BotDetect is designed to be as plugin-independent as possible: it uses Captcha images as the default Captcha delivery mechanism, which work in all widely used browsers without requiring any additional plugins. The Captcha audio alternative is also widely compatible and always tries to use Html5 audio elements if available, which compatible browsers can play without external plugins.
Even in older browsers which don't support Html5 audio playback, Captcha sounds are usually handled by default software present on the majority of devices (for example, Internet Explorer delegates webpage sound playing to Windows Media Player, which is present on most Windows machines of visitors using IE – while Safari plays web sounds through QuickTime, present by default on Mac clients).
Of course, due to the huge variety of possible OS, browser, and related configuration options found on web clients, it's impossible to guarantee that the Captcha sound alternative will always play without appropriate plugins. For example, users of Firefox versions prior to 4.0 will need to install the QuickTime plugin to play Captcha audio. For them, displaying appropriate plugin installation instructions would be useful.
Considering that browser audio capability detection and conditional display of appropriate plugin links is unreliable, the minority of visitors which will even try to use audio Captcha functionality, as well as the minority of those among them who will actually require a separate plugin to access it – always displaying a lengthy warning such as "If the audio doesn't play, your browser might need a separate plugin to play sounds on web pages, or you might need to enable sound playback in your browser options. Depending on your browser, you might need to install the following plugins: ..." would provide an unnecessary distraction (easy doubling the amount of Captcha content on the page!) to the majority of visitors.
For this reason, BotDetect doesn't automatically display such instructions by default. Of course, if having such instructions is required for your forms using BotDetect Captcha protection despite the trade-offs involved, it's very easy to add them at your discretion. The reasoning is similar to how BotDetect doesn't automatically add the label instructing users how to solve the Captcha challenge ("Retype the characters from the picture" or similar), because the appropriate instructions will vary from form to form – and only the person or team implementing form functionality can make the call what is appropriate for it.
CAPTCHA and the Section 508 §1194.22 (n) – Form Accessibility to Assistive Technology
Since on-line forms are the most common scenario of Captcha application, this rule is highly relevant to evaluation of Captcha Section 508 compliance. The whole form – including Captcha validation – should be tested on assistive technology such as screen readers, and any potential roadblocks preventing users of such technology from completing the form should be removed.
An audio Captcha alternative that can be pronounced by screen readers is obviously the first requirement, since otherwise the visual Captcha challenge would unfairly exclude all visually impaired visitors.
Other notable concerns include:
All form instructions and field labels should be in plain text or have clear text equivalents, so people using screen readers can understand the form purpose, the information required, and how to complete it.
All interactive form elements (such as <input type="text" id="..."> text boxes) should have respective <label for="..."> elements, so the association between field label and input is not merely visual and inaccessible to screen readers or users of alternate layouts (low resolution high contrast displays, devices without CSS support etc.)
The form should be navigable without a pointing device, using keyboard navigation only (element tabindex order and functionality must be clear); the form should be navigable using voice navigation, etc.
Form feedback such as error, success or progress indicators will be presented in text or will have unambiguous textual equivalents that can be pronounced by screen readers, won't depend on color characteristics to convey important information that would exclude color-blind individuals, etc.
Captcha page elements generated by BotDetect – Captcha images, Captcha sound and reload icons, the Captcha help page link – have text equivalents (which can be configured to suit your form requirements), can be navigated and interacted with using only the keyboard (with a configurable starting tabindex), and are tested to work with assistive technology as required by Section 508 $1194.22 (n). BotDetect even implements a configurable Captcha sound delay to ensure screen reader ease-of-use.
Since BotDetect-generated page elements will comply with Section 508 standards, you'll only need to check other form elements and the overall form workflow for compliance. And BotDetect configuration options will allow you to make any adjustments needed to make it fit your form accessibility requirements.
CAPTCHA and the Section 508 §1194.22 (o) – Skipping Repetitive Navigation Links
Most Captcha implementations don't use repetitive navigation links, so this Section 508 rule doesn't apply. If your Captcha implementation or form does use repetitive navigation links for some reason, you should of course consider it carefully to achieve Section 508 compliance.
CAPTCHA and the Section 508 §1194.22 (p) – Timed Response Extension
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 Section 508 standard.
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). Section 508 $1194.22 (p) 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 Section 508 compliance.
CAPTCHA and the Section 508 Subpart C, §1194.31: Functional Performance Criteria
Subpart C of Access Board Section 508 enumerates important criteria that all complying forms and Captcha implementations should meet. After examining Section 508 technical standards in detail, we'll briefly evaluate the criteria from this section as well.
Captcha functional without vision
Captcha functional with low vision
Captcha functional without hearing
Captcha functional with low hearing
Captcha functional without speech
Captcha functional with low motor ability
CAPTCHA and the Section 508 §1194.31 (a) – Functional Without Vision
Visual Captcha challenges must always be supplemented by audio Captcha functionality, which is the most friendly alternative available to blind people using assistive technology such as screen readers. Captcha implementations which prevent visually impaired individuals from successfully completing the form can not be considered Section 508 compliant.
CAPTCHA and the Section 508 §1194.31 (b) – Functional With Low Vision
The audio Captcha alternative also provides a convenient accessibility aid to low-sighted individuals. A properly designed form should also remain fully functional when used with "enlarged print output" (for example, high level of full page zoom in modern browsers). If a Captcha implementation does not meet this criteria (for example, by using very small Captcha images with hard-to-read codes), it is clearly not Section 508 compliant.
CAPTCHA and the Section 508 §1194.31 (c) – Functional Without Hearing
Since Captcha images provide a form of challenge which can be completed without using the sense of hearing, Captcha implementations relying on images meet this criteria by default.
CAPTCHA and the Section 508 §1194.31 (d) – Functional With Low Hearing
The audio Captcha alternative is primarily meant for visually impaired visitors, and those hard of hearing will primarily interact with audio-independent Captcha images. In the rare case of visitors who are both visually and aurally impaired, the volume of Captcha audio playback should be set to the maximum allowed by the browser – since lowering the audio volume will usually be easier than increasing it, and it's better to err on the side of easier understanding.
CAPTCHA and the Section 508 §1194.31 (e) – Functional Without Speech
Most Captcha implementations don't rely on user speech, and meet this criteria by default.
CAPTCHA and the Section 508 §1194.31 (f) – Functional With Low Motor Ability
Captcha challenges can be designed to meet this Section 508 functional criterion by allowing an adequate amount of time for Captcha and form validation, and being navigable even without pointing devices (using "coarser" means of input such as keyboard or voice navigation). The only category of Captcha protection that will commonly have issues meeting this criterion are dynamic forms such as "drag & drop Captcha" or various "Captcha games" – making their Section 508 compliance highly unlikely.
CAPTCHA and the Section 508 Subpart D, §1194.41: Information, Documentation, and Support
The final section of Access Board Section 508 standards, Subpart D doesn't introduce any new requirements for compliant Captcha implementations, but we'll briefly consider it for the sake of completeness.
After ensuring that a web form which includes Captcha validation meets the Section 508 technical standards and functional performance criteria, web form developers can go the extra mile by providing documentation targeted at individuals with disabilities – explaining which form parts are likely to cause them issues, and how does the form provide for their needs with related accessibility features. Of course, this information should be available in a format accessible to users who are likely to need it.
For example, after ensuring that the whole form can be navigated and completed using only the keyboard, letting users know this feature is available will help make their initial interaction with the form easier. For another example, the BotDetect help page feature can be used to place a link to Captcha-specific instructions and explanations directly within the generated Captcha challenge.
Section 508 CAPTCHA: Conclusions & Further Reading
Making Captcha validation Section 508 compliant requires careful consideration and adjustment from both web form developers and Captcha developers: ensuring that all form interactions (Captcha included) meet Section 508 technical standards for web-based applications and Section 508 functional performance 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 Federal agency web form developers easy access to highest levels of Section 508 compliance. 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 Section 508 compliant and non-compliant ways. BotDetect gives you all the means necessary to make your forms Section 508 compliant, but can't guarantee they will always be compliant. Because of this, it is the responsibility of Federal users to ensure Section 508 compliance for each page using the BotDetect Captcha component.
CAPTCHA Complying with Section 508
BotDetect CAPTCHA Section 508 Compliance Checklist