SC 3.3.7 Accessible authentication and CAPTCHA challenge

[mraccess77]

A typical CAPTCHA requires you to recognize images and has an audio challenge. The audio challenge is required for users who cannot see or who have some other visual disability.

We say that object recognition includes audio - but the transcription aspect is not addressed. SC 3.3.7 allows for the object recognition to pass - but the audio version would not pass the SC because it requires transcription. In effect a typical CAPTCHA that had an image with audio challenge could fail unless the audio challenge was set up differently with multiple choice answers for example - but then again that requires memorization.

Do I understand this correctly that typical CAPTCHA audio challenges would fail at the AA level because of the transcription?

[alastc]

Hi Jon,

It is an interesting intersection. You could look at the visual and audio as alternatives (one of which would pass). But if you need the audio and can't transcribe, then the visual one isn't an option.

I think the alternatives need to pass other SCs in order to work, that's something we can add to the understanding doc.

[mbgower]

I agree the audio should be viewed as an alternative.

However, based on the existing language, I do not agree that this audio alternative must pass 3.3.7 as well. If one CAPTCHA method (e.g., without the audio) meets 3.3.7, then this situation passes because "Another authentication method that does not rely on a cognitive function test" exists.

Likewise, if this audio alternative did not require transcription or any other cognitive test, it could also be used to meet 3.3.7.

I agree there's an intersection where someone who has a cognitive disability who also either cannot see or cannot hear may be unsupported. We have a hole. I looked to see if we were covered at AAA, but it retains two exceptions, which use alternative and mechanism. Interestingly, if we considered the audio a mechanism to assist users, instead of an alternative, then the intersection of needs is covered, since we have this wording for the mechanism:

Note
The mechanism needs to meet all success criteria for the conformance level claimed.

Incidentally, the examples I've seen of an audio alternative tend to be for a CAPTCHA mechanism that itself required transcription -- in other words, both mechanisms require transcription, and so the scenario would not pass 3.3.7 anyway. So one question I have is: do we know of examples of a CAPTCHA where the primary method passes 3.3.7, but the alternative fails it?

[mraccess77]

An audio alternative is one way to provide alternative for visual CAPTCHA. Some audio alternatives do require transcription - which is a cognifive function test. A person who is blind can't use the visual CAPTCHA test and must use the alternatives. WCAG requires alternative to meet the WCAG requirements. People who are blind or low vision can have cognitive disabilities just like anyone else. If n audio alternative relies on transcript I don't understand how that can pass. Most CAPTCHA including audio ones have timeouts as well and while you can reanswer - there is not an option to extend time but retry the audio or visual challenge repeatedly.

I have found audio alternatives that I believe would pass because they don't require a cognitive function test or the test is for recognition similar to the exception we have for 3.3.7. For example, recognizing a sound being from a bee. This is more similar to the exception for recognizing objects that we allow. So, in these cases I think they could pass the criteria. We need guidance on this in the understanding document.

[mbgower]

I was saying that if the primary CAPTCHA method does not include a cognitive function test, then it passes 3.3.7. There may be other SCs that the same CAPTCHA will fail (e.g., 1.1.1) but it passes 3.3.7. I agree there is a hole for users with more complex needs, but we still have to deal with the normative text as written. That gap will likely need to wait until 3.0 to be plugged.

I have made adjustments to your PR which I think make sense within the context of that section of the Understanding document.

I agree we could add in additional information both on your bee example and on the wider consideration for accessible CAPTCHA, but my sense is it makes sense to get this PR in and tackle that as a separate issue/PR. It is likely to need more scrutiny.

[mraccess77]

Ok, the PR clarifying the audio transcription problem seems good to me.

[bruce-usab]

Discussed on call 12/8 (and moved to Ready for approval) but we also discussed that even "check if you are not a robot" CAPTCHA remain a concern.

[mbgower]

@mraccess77 we're moving the the small PR to the Working Group for approval. As stated in the thread:

I agree we could add in additional information both on your bee example and on the wider consideration for accessible CAPTCHA, but my sense is it makes sense to... tackle that as a separate issue/PR. It is likely to need more scrutiny.

If you have time to craft some additional considerations and examples for the Understanding document, or further explore this, we'd welcome it. Thanks!

[mraccess77]

@mbgower I don't - but the principle I was trying to migrate over was non-text object recognition was deemed acceptable to meet for AA - so an audio equivalent of object recognition would be a closer model to that. It still requires the user to enter a corresponding number - but I'm finding these audio challenges more common then the transcribe phrase ones. The transcribe phrase ones were also very hard to audibly distinguish - although these ones will likely have problems for some users and likely will be solvable by bots as well.