My thought is that cognitive function tests test for short-term memory, visual spatial awareness, motor speed, etc. so I'm not so sure the line is just between what the site has provided and what you know if there are other factors involved such as speed, etc.

how about this example from LinkedIn where users have to recognise the spiral galaxy.

Even if you argue galaxies are a common object(?!), I think that comes more under puzzles as you are differentiating one galaxy from another?

On a tangent, if that is something you do at registration, then it doesn't come under "authentication" which is for when you already have an account.

I'm not convinced that defining "common objects" is going to help. Whether something requires domain-specific knowledge is just as fuzzy and opens up more questions.

The normative text (from the definition) is whether something "requires the user to remember, manipulate, or transcribe information", and this is requiring the manipulation of information.

Response from the COGA task force:

The word “recognize” implies a cognitive test. An individual with memory challenges may not be able to remember or recognize what they uploaded. We would like propose updating the understanding document accordingly, which means

1. removing the three words in the first sentence, “the website provided,” from this statement.
2. the sentence “Recognising common objects, or a picture the user has provided, would not be a cognitive functional test.”

Result:
If the test is based on something the website has set such as remembering or transcribing a word, or recognising a picture, that would be a cognitive function test.

Hi @rainbreaw,

Making those changes would un-do some of the changes made to address issues in the first round of review. It is worth reviewing #1256, as I'm not sure if we can progress with this if we disallow all forms of CAPTCHA.

For example, the typical re-captcha from Google would not pass that.

Following up on this from the COGA TF perspective:

I reviewed #1256 as recommended (thank you for this history). The language that was added in there has similar issues from a COGA perspective:

If a CAPTCHA is used as part of an authentication process, there must be a method that does not include a cognitive function test. 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 a picture the website provided, along with or a picture the user has provided from the part below, implies that if the user provides the image, all will be fine. This doesn't include those individuals who may not be able to access immediate working memory, or may be subject to memory lapses.

Recognizing common objects, or a picture the user has provided, would not be a cognitive functional test. Some forms of object recognition may require an understanding of a particular culture. For example, taxis can appear differently in different locales. This is an issue for many people, including people with disabilities, but it is not considered an accessibility-specific issue.

Recognizing common objects is an accessibility-specific issue for some (even beyond the internationalization/localization challenges). Without going into great detail on what constitutes common objects, they may be significantly different for individuals with a variety of cognitive disabilities. Additionally, the ability to recognize those common objects in context may be different.

As for what to do next, starting by acknowledging my understanding that:

1. Our goal is not to change the underlying SC, but rather to make sure this is accurate and is as understandable and usable as possible
2. We can't create an SC that is impossible to pass

I'm proposing this revision to the text in place of what we (the COGA TF together) originally posted on June 25:

If the test is based on something the website has set such as remembering or transcribing a word, or recognising a picture the website provided, that would be a cognitive function test. Recognising common objects, or a picture the user has provided, can still be cognitive function tests for some individuals, and so an alternate method of authentication should be available.

Hi Rain,

We could adjust the SC text (or more likely the CFT definition), but I'm not seeing a useful update in this case.

In terms of definitions, we need to be as clear as possible about what constitutes a CFT. It should be based on the content rather than the degree to which it affects people. The proposed text technically brings everything inside the CFT definition, just in a way that isn't as clear.

I'm struggling to see how you could implement a CAPTCHA style step to authentication if you can't use any kind of image recognition. Unless we have a good story for that (with examples), I don't think the SC could continue, it is falling into the "impossible to pass" category (for some organisations).

Unless someone can assemble those example quickly, COGA need to decide whether it is better to have something in place as a baseline, or not.

Leaving a note here to acknowledge Alastair's concerns above and confirm that I'm bringing this back to COGA.

Update: Alastair came to our planning call this week, and we believe we have a path forward. Before posting it to this comment thread, however, we will be reviewing with the COGA Task Force on Thursday, August 12.

The coga taskforce reconfirmed that recognizing objects is a cognitive function test that provides significant barrier and if it is used, an alternative that does not require a cognitive functional test should also be provided. Recaptcha includes an option that does not require image recognition (https://developers.google.com/recaptcha/). If the image recognition is used, an alternative that allows for 2 factor authentication that allows a yes/no response or clicking a confirmation link (vs sending a code) can be provided.

an alternative that does not require a cognitive functional test should also be provided.

We need to know what that would be, because I don't know of one that would pass the SC (having scoped out things provided by the user).

This isn't about 2-factor, it is about the scenario where the site thinks you are a bot or abusing the system, and it adds a CAPTCHA to the login to prevent that.

@rachaelbradley HI, you mention RACPATCHA offers an option without image object recognition. Can you let me know what that is? Despite v3 having a checkbox - on some sites I always get the object recognition challenge - no matter what. On others I get it after entering an incorrect password. There is an audio challenge which requires transcription which is another cognitive function test. So I think the only solution is to offer another option in situations when RECAPTCHA requires object recognition.

@mraccess77 You are correct that a number of times the RECAPTCHA changes to object recognition due to some trigger.

This page outlines why you might sometimes get a CAPTCHA: https://support.patreon.com/hc/en-us/articles/115004119043-Why-am-I-getting-so-many-CAPTCHAs-

This isn't just a Google thing, most large-scale providers will have something like this in place. The problem is that this is already the 'backstop' method if others have failed. I'm not aware of an alternative that would pass the SC if common-objects are considered a test.

As an update, we have been exploring various options for resolving this in a way that is both viable to implement with current technology, and may address the COGA TF concerns. The following explorations are being documented here before bringing them to the COGA TF, so please consider these comments knowing that the COGA TF still needs review.

Following are two possible approaches to resolving this:

1. Create more strict SC language that essentially means captchas will not pass, and perhaps allow exceptions for some of the extreme cases @alastc refers to in the comment above
2. Split this up into Level AA and Level AAA versions

What the language for option 1 might look like:

If the test is based on something the website has set such as remembering or transcribing a word, or recognising a picture the website provided, that would be considered a cognitive function test. Recognising common objects, or a picture the user has provided, can still be cognitive function tests for some individuals. When cognitive function tests are required, an alternate method of authentication (such as a physical device key or equivalent app) should be available.

An example of a two-factor authentication path that would pass this SC:

1. a username/password field that works with a password manager and allows copy and paste, AND
2. either a physical device key or authentication app (e.g. Microsoft’s authenticator, or Google’s use of the Gmail app) that doesn’t require additional steps once set up, and/or an equivalent app .

Challenges we still need to figure out in this language, even:

• What do we mean by "no additional steps"? Some of these tools require that you accept a notification or put your finger onto a device.
• What are the acceptable alternatives?
• Which exceptions (for security reasons) are we comfortable with? Example might be if there is genuine indication that the device being used for authentication has been hacked?

What the language for option 2 might look like:

Level AA language:

For each step in an authentication process that relies on a cognitive function test [link text to definition], at least one other authentication method is available that does not rely on a cognitive function test, or a mechanism is available to assist the user in completing the cognitive function test.

Exception: Two types of cognitive function tests are excepted from Level AA at this time:

1. prompting the user to recognize common objects (examples: cars or tables),
2. asking the user to recognize content, such as an image or a word, that they provided to the website.

Level AAA language:

If the test is based on something the website has set such as remembering or transcribing a word, or recognising a picture the website provided, that would be considered a cognitive function test. Recognising common objects, or a picture the user has provided, can still be cognitive function tests for some individuals. When cognitive function tests are required, an alternate method of authentication (such as a physical device key or equivalent app) should be available.

An example of a two-factor authentication path that would pass this SC:

1. A username/password field that works with a password manager and allows copy and paste, AND
2. Either a physical device key or authentication app (e.g. Microsoft’s authenticator, or Google’s use of the Gmail app) that doesn’t require additional steps once set up, and/or an equivalent app .

Notes about Level AAA language:

• This has the same language and challenges as the level AAA option referenced above
• There is no exception that allows "common objects" or "user provided" content to be considered exceptions from cognitive function tests

I do not understand why the exceptions are realy nessisary when they are a clear block to the content to so many people.
sending a link in an email to click? why is that not ok? Or third party (such as a google login) etc etcf. so many free ways for small sites
If it is not possible to get more inclusion then we must be clear in our description of AA conformance that it allows things that completely block people with disabilities from using the content.

I believe the AAA language for the SC should be:

For each step in an authentication process that relies on a cognitive function test [link text to definition], at least one other authentication method is available that does not rely on a cognitive function test, or a mechanism is available to assist the user in completing the cognitive function test.

Then the language in the comment above should be in the understanding documents. As noted in today's COGA call, the understanding document for the AA should also include a note that while the exceptions pass, they do not fully support the COGA community and should be avoided if possible.

For option 1, I am concerned that without providing clear guidance on what Constitutes an additional step, financial services, e-commerce and payment providers will not be able to implement this SC as it could contradict UK and EU regulations. These regulations require a two-step authentication process (as raised in #1965 ) and it’s is often out of the website providers control whether the customer chooses to use a method that has an additional step (eg whether they choose to use biometrics or enter a password to acknowledge a notification). So if option 1 is progressed, we would need to be really clear on what was acceptable.

I would be supportive of option 2 if the second exception in the AA language included audio in the second exception to ensure that non-visual approaches are included.

In case it matters, I came across an example yesterday that relates back to one of my original thoughts. In this example, the user is requested to selected an object.

However, the objects are arguably common objects that should be relatively universal across cultures.

It contrasts with the LinkedIn example, which I would argue more-so needs subject specfic knowledge, are not common objects, and requires users puzzle out the solution.

The challenge I think is the line between and test criteria for where we draw the line. These are two extreme examples and most probably fall somewhere in between these two.

to clarify, most (almost all) people who were in COGA groups themselves and were consulted, seemed to be potentially excluded from entering a site that conforms to this SC at AA. That needs to be understandable and clear from the description of AA conformance.

FYI, #2042 adds explicit exceptions to the AA version to allow for common objects / user-provided content.

That doesn't explicitly define common objects, but as mentioned above, we're just using the dictionary definitions of those terms.