Clarify CAPTCHA content scope, within 'accessible authentication (minimum)' understanding doc

[dav-idc]

Summary

This issue is to recommend that clarifying content be added to the 'Object Recognition' section of the 'Accessible Authentication (minimum)' Understanding document.

The clarifying content would state the scope of when the advice within the object recognition section would apply to CAPTCHAs.

Context on the current gap in guidance

Right now, there is no solid definition provided for 'authentication process' for 'Accessible Authentication', for both the 'minimum' and 'enhanced' success criteria. This lack of definition is covered by another GitHub issue:

• https://github.com/w3c/wcag/issues/3264

With or without a definition though, it can get a bit muddy on where the line is drawn for when CAPTCHA-related advice should be followed. What CAPTCHAs should be accessible? All? Or just the ones involved in logins?

Outside of explicit sign-in and re-sign-in spaces for authentication, CAPTCHA are often employed to 'authenticate' the validity of a user. Examples of CAPTCHA use outside of sign-in spaces:

• Submitting a form or application
• Uploading or downloading a file
• Completing a sensitive operation (like deleting an account)
• Accessing a page or piece of web content that is currently under high-traffic or a suspected DDOS (distributed denial of service) attack

Here's a couple relevant excerpts from the 'Object Recognition' section of the 'Accessible Authentication (minimum)' Understanding document:

Object Recognition

If a CAPTCHA is used as part of an authentication process, there must be a method that does not include a cognitive function test, unless it meets the exception. If the test is based on something the website has set such as remembering or transcribing a word, or recognizing a picture the website provided, that would be a cognitive functional test. Recognizing objects, or a picture the user has provided is a cognitive function test; however, it is excepted at the AA level.

Some CAPTCHAs and cognitive function tests used for authentication may only appear in certain situations, such as when ad blockers are present, or after repeated incorrect password entry. This criterion applies when these tests are used regardless of whether they are used every time or only triggered by specific scenarios.

My recommendation

I would recommend taking action to improve the clarity of the 'object recognition' content, especially as it pertains to CAPTCHAs.

Leaving the current CAPTCHA content in the 'understanding' document as is would risk inconsistent interpretation of which CAPTCHAs need to follow the success criteria and which don't. That seems messy, to me. Especially when it could be clarified with some additional content.

However, there are a few options for how to address this lack of clarity via content, and I'm less certain on which approach is best. I've outlined 3 options in the next section.

Options for improved guidance

There are a few paths forward I see, for increasing clarity around CAPTCHA requirements and scope. Each option has pros and cons, some of which I've brainstormed here.

Option 1: rigid definition-based scope

Define 'authentication process' explicitly in the glossary, and then scope the 'Object recognition' section to only apply to CAPTCHA used in 'authentication processes'.

Pros:

• An easy and solidly-scoped bit of guidance that stays in its lane.
• Works nicely with the other issue that's recommending to define 'authentication process'.

Cons:

• Allows for two tiers of accessibility for CAPTCHA: ones in authentication processes and ones not tied to authentication processes.
• Could lead to inaccessible CAPTCHA options in use.

Option 2: broader-scoped applicability of 'object recognition' advice

Regardless of the definition of 'authentication process' scope the 'object recognition' section could be stated to apply more generally to CAPTCHAs, and not be limited to login journeys.

Pros:

• Avoids splitting acceptable CAPTCHA types into 'ones used in login' and 'ones used elsewhere', where the ones used elsewhere can be less accessible.
• Promotes the broader adoption of CAPTCHAs and security checks that don't include a cognitive function test all over.
• Simplifies the process of vetting CAPTCHA accessibility (guidelines won't be different based on what type of process it's used in).

Cons:

• if the definition for 'authentication process' ends up not including verification of 'human' status for things like file uploads, major actions, form submissions, and DDOS prevention, then we've suddenly got content in the 'object recognition' section that applies to more things than its success criterion applies to.
• It assumes that accessibility considerations for CAPTCHA within the context of accessible authentication are equally applicable in all other scenarios where CAPTCHA is employed. So essentially it assumed that cognitive function tests are more generally "...problematic for many people with cognitive disabilities".

Option 3: optional 'also applicable to X' advice

Instead of going for the two more decisive options above, a softer approach might be to add content to the 'object recognition' section that serves as more of a 'bonus idea', rather than a requirement of the success criterion.

Something like, "Beyond accessible authentication, these guidelines for CAPTCHA are beneficial in all scenarios when CAPTCHA are used. The use of cognitive function tests in CAPTCHA is consistently a barrier for many people with cognitive disabilities, regardless of the process where the CAPTCHA appears." (And then maybe something about the different types of scenarios where CAPTCHA is employed beyond logins).

Pros:

• Adds more useful context to the 'understanding document' on how 'object recognition' can be problematic regardless of whether it's tied to authentication.
• Doesn't expand the scope of the guideline beyond whatever the defined boundaries of 'accessible authentication' may be.
• Avoids becoming a situation where important and compliance-related advice is buried inside the 'understanding' document.

Cons:

• Wouldn't have any enforcement or 'teeth'
• Doesn't solve the scope ambiguity currently present in 'Accessible Authentication' success criteria
• May seem like it's a cop-out. "Here's what you maybe could do, and it could probably help accessibility?"

[bruce-usab]

@davidc-gds adding a glossary term is not feasible for 2.2.

Working within that constraint, could you propose what you would like to see added or changed in [Understanding[(https://w3c.github.io/wcag/understanding/accessible-authentication-minimum.html)?

[alastc]

What CAPTCHAs should be accessible? All? Or just the ones involved in logins?

Well, all CAPTCHAs should be accessible (or have an accessible alternative), but remember that Accessible Authentication isn't the only applicable SC. Non-text content, contrast, and others are probably applicable.

The examples in the bullets wouldn't be applicable to this SC, but other SCs would apply, particularly as they are unlikely to offer an alternative method of completing that task.

the 'object recognition' section could be stated to apply more generally to CAPTCHAs, and not be limited to login journeys.

That's not a direction we could take for this SC. It was specifically scoped to authentication because that was the focus of the user-need, and we couldn't get consensus on a wider application. (E.g. the companies/stakeholders protecting content from bots/abuse with CAPTCHAs wouldn't have agreed to a wider application.)

Also, objection recognition is only one type of CAPTCHA, other types (e.g. letter recognition) do not have an exception in this SC.

a softer approach might be to add content to the 'object recognition' section that serves as more of a 'bonus idea', rather than a requirement of the success criterion.

We already have similar content in 1.1.1, and there is a separate, dedicated document on CAPTCHAs linked from the first sentence of this object recognition guidance.

I think we're already heading towards your option 1, where it is tightly scoped.