Strict Standards: Introduction to CAPTCHA Accessibility

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

Web accessibility is a complicated topic. Sure, the basic idea is simple enough: make web pages that everyone can use, following established and well known accessibility guidelines and standards. But as soon as you move from that basic idea towards actual execution, you realize how deep does the rabbit hole go: there are many types of disability to consider, and adapting different elements of web page content and functionality to resulting alternate browsing styles requires significant effort.

And the standards which should guide you through the process? They are often long, complicated enough and phrased in such a manner that unless you have previous experience, it's possible to spend weeks studying them in detail. The next thing you know, you're looking for a... well, guide to help you make sense of those accessibility guidelines, and something as simple as publishing a web page has become quite an involved operation...

Captcha protection introduces its own, unique accessibility challenges: generally accessible web pages will be designed to be as machine-readable as possible, so assistive technology can transform them into alternate formats accessible to disabled individuals. But Captcha only stops automated form submissions because it is purposefully designed to be indecipherable to machines. This means that generic web accessibility techniques don't suffice to make an accessible Captcha implementation.

So, how will we go about it? We'll examine the crucial accessibility criteria a Captcha challenge must meet, and study the minutiae of the most important web accessibility standards (Section 508 and WCAG). We'll do all the hard work of translating official-sounding and often abstract guidelines into concrete Captcha implementation decisions so you don't have to, and see where it takes us.

CAPTCHA Accessibility Criteria

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

However, if reading the Captcha is the only way for visitors to complete the form, it presents an insurmountable barrier to the blind or otherwise visually impaired people. Since most individuals with such disabilities browse the web using assistive technology based on sound (e.g. screen readers which can pronounce web pages designed with accessibility in mind), an obvious solution is to present an alternative Captcha form which such visitors can hear.

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

[back to the top of the page]

CAPTCHA Accessibility and Section 508 Compliance

Among web accessibility standards and guidelines, the Access Board Section 508 Standards for Electronic and Information Technology (abbreviated as "Section 508") are unique on two significant accounts:

Scope: Section 508 applies only to US Federal agencies.
Severity: Section 508 compliance is mandatory under Federal law.

The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d).

Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency.
Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.

Considering the legal severity of Section 508 requirements, we'll examine the current Access Board Section 508 standards in detail, 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. An accessible, Section 508 compliant Captcha implementation must meet both the Section 508 technical standards for web-based Intranet and Internet information and applications and the Section 508 functional performance criteria.

Even when using an off-the-shelf Section 508 compliant Captcha implementation, compliance of the Captcha-protected form as a whole can only be achieved by web form developers. The BotDetect Captcha component has been engineered to allow Federal agency web form developers easy access to highest levels of Section 508 compliance, and comes with a checklist for maximizing Section 508 compliance of protected forms.

[back to the top of the page]

CAPTCHA Accessibility and WCAG Conformance

Among web accessibility standards, W3C Web Content Accessibility Guidelines (WCAG) are the most commonly used and (in version 2.0) the most detailed.

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 is the most complex web accessibility standard, and requires careful consideration to meet. 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 an accessible, WCAG-conformant Captcha implementation 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 explain why that is the case. But we'll focus on WCAG 2.0 conformance requirements which apply to Captcha.

Even when using an off-the-shelf WCAG-conformant Captcha implementation, conformance of the Captcha-protected form as a whole can only be achieved by web form developers. The BotDetect Captcha component has been engineered to allow web form developers easy access to highest levels of WCAG conformance, and comes with a checklist for maximizing WCAG conformance of protected forms.

[back to the top of the page]