Source: https://captcha.com/accessibility/captcha-section508-checklist.html
Timestamp: 2019-04-20 00:11:33+00:00

Document:
After adding BotDetect Captcha protection to your web form (PHP, WordPress, CakePHP, CodeIgniter, Laravel, Symfony, ASP.NET WebForms, ASP.NET MVC, ASP Classic) to prevent automated submissions, you will be able to satisfy Section 508 Captcha accessibility requirements. However, Section 508 compliance won't be automatic, since it can only be evaluated for the form as a whole, and involves page elements which are not generated by BotDetect but are under your control. Also, since each form might have its own unique requirements, BotDetect should be configured to meet them. This checklist will guide you through the Captcha implementation steps needed to fully comply with Section 508 standards.
Next, you should consider the target audience of your web form and localize BotDetect to match the language of the page itself – sound Captcha can only help visually impaired visitors complete the form if they can understand the pronunciation. Use the BotDetect localization guide for your core form technology: ASP.NET, Java, ASP Classic, PHP.
The descriptive text alternative / tooltip for the Captcha sound icon should also be clear and descriptive enough to screen reader users, and written in the same language as the rest of the form. If you need to change the Captcha sound icon tooltip, you can use the BotDetect setting for your core form technology: ASP.NET, Java, ASP Classic, PHP.
Finally, the audio Captcha starting delay should be configured so the Captcha pronunciation does not overlap with screen reader pronunciation of the descriptive label associated with the Captcha code textbox. This should be tested in a screen reader such as JAWS. Use the BotDetect sound delay configuration guide for your core form technology: ASP.NET, Java, ASP Classic, PHP.
BotDetect audio is designed to work for the widest possible user base, gracefully degrading to match the abilities of the visitor's browser and device. However, it's impossible to guarantee automatic sound support for all clients. Some very old browsers might require that a separate sound player plugin is installed and properly configured (this is equivalent to how users have to install the Flash player plug-in to access Flash movies in their browsers). Note that blind users are unlikely to experience this issue, since they are most likely to have already ensured browser sound support.
Unfortunately, it is currently not possible to automatically detect whether the visitor's browser requires such a plugin (or other client/user settings prevent the audio from being played), and which one is appropriate – so BotDetect cannot do this out-of-the-box. If you want to maximize the accessibility of Captcha audio for users of older/incompatible browsers, you could add an appropriate explanation and links to common media plugins (such as QuickTime and Windows Media Player) below the Captcha challenge or as a part of the Captcha help page.
When using the form from a version of Firefox older than 4.0 (which requires QuickTime to play web page sounds), does the user have a reasonable chance to figure out the plugin is missing and fix the problem?
When audio playback is disabled (e.g. in Internet Explorer: the Internet Options > Advanced > Multimedia > Play sounds in webpages setting is set to Off), does the user have a reasonable chance to figure out and fix the problem?
A fully functional and accessible audio Captcha alternative as outlined above is necessary to meet the Section 508 technical standards for web-based applications §1194.22 (a) ("text equivalents for every non-text element"), §1194.22 (b) ("synchronized multimedia alternatives"), §1194.22 (m) ("linking to required plugins and applets"), §1194.22 (n) ("form accessibility to assistive technology"), as well as the Section 508 functional performance criteria §1194.31 (a) ("functional without vision") and §1194.31 (b) ("functional with low vision").
The descriptive text alternative for the Captcha image should also be clear and descriptive enough to screen reader users (and possibly instruct them to use the audio Captcha alternative made specially for them instead), and written in the same language as the rest of the form. If you need to change the Captcha image alternative text, you can use the BotDetect setting for your core form technology: ASP.NET, Java, ASP Classic, PHP.
Since wrapping the Captcha image inside the Captcha help link (when the help link mode is set to image) could unnecessarily extend the screen reader pronunciation of the Captcha image alternative text, setting the help link mode to text is recommended to maximize Section 508 compliance. You can configure it using the BotDetect setting for your core form technology: ASP.NET, Java, ASP Classic, PHP.
All Captcha images generated by BotDetect should be easily legible by color-blind visitors. And even if Captcha parameter randomization necessary to achieve the required level of Captcha security occasionally generates an image which could be problematic to the color-blind, they will still be able to use the form by requesting a different Captcha image or using the audio Captcha alternative.
The descriptive text alternative / tooltip for the Captcha reload icon should also be clear and descriptive enough to screen reader users, and written in the same language as the rest of the form. If you need to change the Captcha reload icon tooltip, you can use the BotDetect setting for your core form technology: ASP.NET, Java, ASP Classic, PHP.
An easy to read, easy to change and generally accessible implementation of image Captcha functionality as outlined above is necessary to meet the Section 508 technical standards for web-based applications §1194.22 (a) ("text equivalents for every non-text element"), §1194.22 (c) ("use of color"), §1194.22 (l) ("accessibility of client-side dynamic content"), as well as the Section 508 functional performance criterion §1194.31 (b) ("functional with low vision").
While most users today are familiar with Captcha challenges and how to solve them, clear Captcha-related text is necessary to maximize Section 508 compliance.
Captcha instructions: Just before the Captcha challenge, appropriate Captcha interaction instructions (e.g. "Retype the characters from the picture") should be presented to visitors. They should be written in the same language as the rest of the form, and implemented as a <label> element associated with the Captcha code textbox using the for="..." attribute – this way, screen readers and other assistive technology will be able to adapt the user interaction to meet the needs of disabled visitors.
Captcha feedback: When the visitor form submission fails because they didn't solve the Captcha correctly or at all, textual feedback explaining that Captcha input is required or was incorrect will guide visitors to completing the form. This Captcha error text should be clear, and not depend solely on color or other sensory characteristics to convey the information. This will make it accessible to visitors using screen readers and the color-blind. If Captcha validation succeeds but validation of some other form fields fails, it's best to hide the Captcha since the visitor is already verified as human.
Captcha help: If detailed Captcha instructions are provided (longer than would fit the form), a separate Captcha help page can be embedded in the Captcha challenge using the BotDetect help link feature (ASP.NET, Java, ASP Classic, PHP). Ideally, this Captcha help page will be text-only and will explain the available Captcha accessibility features to accommodate screen reader users.
A usable and accessible implementation of the user Captcha interaction as outlined above is necessary to meet the Section 508 technical standards for web-based applications §1194.22 (c) ("use of color"), §1194.22 (d) ("readability without style sheets"), §1194.22 (l) ("accessibility of client-side dynamic content"), §1194.22 (n) ("form accessibility to assistive technology"), §1194.22 (p) ("timed response extension"), the Section 508 functional performance criteria §1194.31 (a) ("functional without vision"), §1194.31 (b) ("functional with low vision") and §1194.31 (a) ("functional with low motor ability"), as well as the Section 508 provisions in §1194.41 ("information, documentation, and support").
BotDetect Captcha has been engineered to meet as many Section 508 compliance requirements as possible, but web form developers are ultimately responsible for making their Captcha-protected forms comply with Section 508 accessibility standards. This checklist can guide you through the steps necessary to ensure and maximize Section 508 compliance of your web forms using BotDetect Captcha to prevent automated submission.

References: §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194
 §1194