How to test 3.3.8 Accessible Authentication (Minimum)

Continuing our series of articles on how to test the new Success Criteria (SC) in WCAG 2.2.

Detailed conformance and testing information can also be found in KnowledgeBase, a digital accessibility repository available through TPGi’s ARC Platform. KnowledgeBase is maintained and consistently updated by our experts, and can be accessed by anyone with an ARC Essentials or Enterprise tier subscription. Contact us to learn more about KnowledgeBase or the ARC Platform.

Success Criterion 3.3.8 Accessible Authentication (Minimum) is concerned with cognitive function tests that are used to authenticate users. Whenever such tests are used, then either an alternative authentication method must be provided (which doesn’t rely on a cognitive function test), or a mechanism is available to help users complete it.

This benefits users with some cognitive impairments relating to memory, reading, numeracy, or perceptual processing, for whom cognitive function tests may be difficult or impossible to complete.

Normative requirements

A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:

  • Alternative: Another authentication method that does not rely on a cognitive function test.
  • Mechanism: A mechanism is available to assist the user in completing the cognitive function test.
  • Object Recognition: The cognitive function test is to recognize objects.
  • Personal Content: The cognitive function test is to identify non-text content the user provided to the website.

The definition of cognitive function test includes anything that requires the user to remember and transcribe information, and this includes username and password authentication.

However if the site allows for password managers to be used, then that’s a mechanism which helps users to complete it. That kind of input would only fail if the site is explicitly blocking support for those tools, and the most likely cause of that would be preventing copy-paste into username and password fields. Some sites block pasting for ‘security reasons’, but that would fail this SC. No exception is allowed on the basis of security, because there aren’t actually any security issues there.

The only exceptions are fields that request the user’s real name, email address, or phone number. Those are personal information that doesn’t change between sites, and therefore inputting them is not considered a cognitive function test.

Hiding authentication information as it’s entered does not fail this SC, for example, using a type="password" field which obscures the input characters.

CAPTCHA tests that ask you to identify obfuscated text or sound are included in this SC, and would therefore fail if no alternative is provided. However tests that ask you to identify a familiar object are specifically excepted (e.g., Select all images with crosswalks).

Even though this is a cognitive function test, it’s listed as an exception because the objects are generally familiar to users. Being able to recognize, say, a street light or a car, is considered sufficiently easy. There is still the potential for cultural lack of familiarity — the images in these tests are generally US urban scenes, which might include objects you’ve never seen before, or don’t know what they’re called. But this is not an accessibility issue, so it’s not considered as part of WCAG.

The “object” in object recognition tests is not limited to images, it also includes video or audio content.

A further exception is for non-text content that the user themselves provided to the site. For example, images from the user’s own profile can be used for a cognitive function test, and one possible application might be a set of faces that asks you to recognize yourself (although that doesn’t sound very secure to me, it’s just a hypothetical). Text-based personal content is not included in this exception, because that relies on recall rather than recognition.

Practical ambiguities

If an alternative authentication method is provided, then it must also pass this SC in order to be a conformant alternative. The most common alternative is likely to be Two-Factor Authentication (2FA), which sends a link or code to the user for verification.

If a verification code is used, then this would be subject to the same requirements as username and password authentication, i.e., there must be a mechanism available for the user to complete the process, such as copy and paste. Therefore if copy-pasting isn’t possible, or if the verification process requires the user to enter only specific digits (such as the 3rd and 5th digit of a 6-digit code), then this would fail, because it’s a requirement to transcribe information.

Some sites implement 2FA by requiring the whole code to be entered using individual fields (i.e., one field per digit). If (and only if) it’s possible to paste the entire code into an individual field, and have it automatically propagated to single digits across all fields, then this would pass. Otherwise it would fail.

If the code is sent to a separate device, such as via SMS, then it’s not necessary to validate whether users can copy or transfer the code between devices. Only the final input needs to be tested.

Testing barriers

Testing for this SC requires the ability to visually identify content.

To differentiate object recognition tests from other kinds of CAPTCHA, for example, you would need to be able to see the content, and also recognize that it’s an object recognition test.

Automated testing

This SC can’t be tested by automation.

Automation can’t unambiguously identify relevant content, such as username and password authentication. The huge variety in potential markup and labelling text would make that unreliable at best. Similarly, there’s no sufficiently reliable way to determine whether image content is an object recognition test.

They also wouldn’t be able to perform the steps necessary to validate alternative authentication methods. This is a good thing too — if it were possible for automation to do this, then the authentication method wouldn’t be secure!

Advances in LLM analysis and image recognition might make some content identification possible in future.

Manual testing

Manual testing can be performed in the following steps:

  1. Identify the presence of cognitive function tests that are used to authenticate users (e.g., username and password, inputting a security code, or CAPTCHA).
  2. Ignore those where (either):
    • CAPTCHA asks you to identify a familiar object;
    • CAPTCHA is based on non-text user content (e.g., user profile images);
    • authentication fields ask for the user’s real name, email address or phone number;
    • an alternative authentication method is available (which itself meets this SC).
  3. For username and password authentication, verify that it’s possible to copy and paste into the fields, or to use a password manager application or browser autocomplete.
  4. For inputting a security code, verify that (all):
    • it’s possible to copy and paste into the fields; and
    • the whole code is input (e.g., if the input requires you to enter only specific characters, like the 3rd and 5th digit, then this fails, because it’s a requirement to remember and transcribe information).
  5. For any other kind of cognitive function test used for authentication, verify that there’s no reliance on memory, transcription, or perceptual processing (e.g., rotating captcha relies on spatial reasoning, which requires perceptual processing).

Yielding one of three expected results:

  • Pass: All cognitive function tests used for authentication provide an alternative method of authentication, or an exception applies to those which don’t.
  • Fail: Some cognitive function tests used for authentication do not provide an alternative method of authentication, and no exceptions apply.
  • Not Applicable: There are no cognitive function tests used for authentication.



Image credit: Mustang Joe.

Categories: Accessibility Strategy, KnowledgeBase Content, Technical

About James Edwards

I’m a web accessibility consultant with around 20 years experience. I develop, research and write about all aspects of accessible front-end development, with a particular specialism in accessible JavaScript. I can also turn my hand to PHP and MySQL when it’s needed. I started my career as an HTML coder, then as a JavaScript developer, but the more I learned, the more I realised just how important it is to consider accessibility. It’s the basic foundation of web development and a fundamental design principle of the web itself. If information is not accessible, then what’s the point of any of it? Coding is mechanics, but accessibility is people, and it’s people that actually matter.


Software Testing Notes says:

This article was curated as a part of #126th Issue of Software Testing Notes Newsletter.

Add Your Comment