Understanding SC 3.3.8: Accessible Authentication (Minimum) (Level AA)

In Brief

Goal: Make logins possible with less mental effort.
What to do: Don't make people solve, recall, or transcribe something to log in.
Why it's important: Some people with cognitive disabilities cannot solve puzzles, memorize a username and password, or retype one-time passcodes.

Success Criterion (SC)

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 Web site.

Note

"Object recognition" and "Personal content" may be represented by images, video, or audio.

Note

Examples of mechanisms that satisfy this criterion include:

support for password entry by password managers to reduce memory need, and
copy and paste to reduce the cognitive burden of re-typing.

Intent

The purpose of this Success Criterion is to ensure there is an accessible, easy-to-use, and secure method for users to authenticate when logging into an existing account. As the most prevalent form of authentication, Web sites commonly rely on usernames and passwords to log in. However, memorizing a username and password places a very high or impossible burden upon people with certain cognitive disabilities, as do additional steps often added to authentication processes. For instance, the need to transcribe a one-time verification code or requiring a puzzle to be solved.

While Web sites can use the recognition of objects or of non-text content provided by the user to meet this Success Criterion, such techniques do not fully support the cognitive accessibility community and should be avoided if possible. Refer to Accessible Authentication (Enhanced) for guidance to be more inclusive and accessible.

This Success Criterion is focused on authentication of existing users. It does not cover creation of a username or initiation of an account. For many Web sites, establishing an initial username and credentials may not differ greatly from logging in with that username. The techniques used to satisfy this criterion (particularly allowing pasting into inputs and not relying on transcription) can also reduce the cognitive burden in account creation. However, the focus of the Success Criterion is on reducing the ongoing need for users to recall previously supplied information each time they log in or otherwise authenticate to an account.

Cognitive Function Tests

Remembering a site-specific password is a cognitive function test. Such tests are known to be problematic for many people with cognitive disabilities. Whether it is remembering random strings of characters, or a pattern gesture to perform on a touch screen, cognitive function tests will exclude some people. When a cognitive function test is used, at least one other authentication method must be available which is not a cognitive function test.

Some CAPTCHA systems have an audio alternative of the visible text. If the user needs to transcribe this audio, it cannot be used to meet the Alternative exception.

If there is more than one step in the authentication process, such as with multi-factor authentication, all steps need to comply with this Success Criterion to pass. There needs to be a path through authentication that does not rely on cognitive function tests.

Being able to recover or change the email and password is an important part of authentication. If the user is authenticating with alternative information in order to recover their account, there needs to be a method that is not a cognitive function test.

Many organizations are required to use 2-factor authentication that combines independent sources to confirm a user's identity. These sources can consist of combining authentication through:

knowledge (e.g., password, letters in a passphrase or memorized swipe path);
possession (e.g., a verification code generated or received on a device, or scanning of a QR code on an external device);
biometrics (e.g., fingerprint scanning, facial recognition or keystroke dynamics).

Most knowledge-based authentication methods rely on a cognitive function test, so mechanisms to assist users must be available. When authentication relies on performing an action on a separate device, it should be possible to complete the action without the need to transcribe information. It may not be possible to know what device-based authentication methods are available to a user; offering a choice of methods can allow them to choose the path that most suits them.

Authentication Approaches

Web sites can employ username (or email) and password inputs as an authentication method if the author enables the user agent (browsers and third-party password managers) to fill in the fields automatically. Generally, if the login form meets Success Criterion 1.3.5 Input Purpose, and the form controls have an appropriate accessible name in accordance with Success Criterion 4.1.2 Name, Role, Value, the user agent should be able to reliably recognize the fields and automatically fill them in. However, if the user agent is actively blocked from filling in the fields (for instance, by a script), then the page would not pass this criterion because it prevents the mechanism from working.

Copy and paste

Copy and paste can be relied on to avoid transcription. Users can copy their login credentials from a local source (such as a standalone third-party password manager) and paste it into the username and password fields on a login form, or into a web-based command line interfaces asking for a password. Blocking people from pasting into authentication fields, or using a different format between the copied text and the input field (for example, "Enter the 3rd, 4th, and 6th character of your password"), would force the user to transcribe information and therefore fail this criterion, unless another method is available.

Two-factor authentication systems (verification codes)

Beyond usernames and passwords, some sites may use two-factor authentication, asking the user to enter a verification code (also called a passcode or one-time password). A service that requires manual transcription of a verification code is not compliant. As with usernames and passwords, it must be possible for a user to at least paste the code (such as from a standalone third-party password manager, text message application, or software-based security key), or to allow user agents to fill in the fields automatically.

There are scenarios where a verification code must be received or generated on a secondary device. For example, authenticating in a web browser on a laptop requires a verification code that is sent as an SMS text message to a mobile phone. However, in most cases, it is possible for the code to then be sent directly to the primary device, where it can then be copied and pasted (for example, by copying the code on the secondary device and emailing it to the primary device, or through the use of a shared cross-device clipboard where copying content on the secondary device makes it available to paste on the primary device). Evaluating whether or not the code can be seamlessly transferred from the secondary device to the primary device is outside of the scope for this Success Criterion. For the purpose of evaluating Web content that relies on authentication using these types of secondary device systems, it is assumed that provisions are in place that make the code available in the user's clipboard. Evaluating this criterion therefore only requires verification that the web content does allow pasting the clipboard content in the related authentication challenge field.

Note that two-factor systems that do not rely on codes — including hardware authentication devices (such as YubiKey), secondary applications (either on the same primary device, or on a secondary device) that expect the user to confirm that it is indeed them trying to log in, and authentication methods provided by the user's operating system (such as Windows Hello, or Touch ID/Face ID on macOS and iOS) — are not a cognitive function test.

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.

An object in this context means the general English definition ("a material thing that can be seen and touched") and can include vehicles and animals. If the test goes beyond recognition (e.g. multiply the number cats by the number of dogs), that does not meet the exception.

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.

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.

There are a number of technologies that can be employed to prevent scripted abuse of the authentication process.

None of these systems are 100% effective. However, they may reduce the likelihood of a CAPTCHA being displayed.

Personal Content

Personal content is sometimes used as a second factor for authentication. For example, as part of account creation the user would upload a picture, and when logging in they would be asked to select that picture from several possible alternatives. Care must be taken to provide adequate security in this case, since non-legitimate users might be able to guess the correct personal content when presented with a choice.

Text-based personal content does not qualify for this exception as it relies on recall (rather than recognition), and transcription (rather than selecting an item). Whilst picture-based personal content will still be a barrier for some people, text based versions tend to be a much larger barrier.

Hiding characters

Another factor that can contribute to cognitive load is hiding characters when typing. Although this criterion requires that users do not have to type in (transcribe) a password, there are scenarios where that is necessary such as creating a password to be saved by a password manager. Providing a feature to optionally show a password can improve the chance of success for some people with cognitive disabilities or those who have difficulties with accurately typing.

Benefits

People with cognitive issues relating to memory, reading (for example, dyslexia), numbers (for example, dyscalculia), or perception-processing limitations will be able to authenticate irrespective of the level of their cognitive abilities.

Examples

The examples of this Success Criterion are the same as the Accessible Authentication (Enhanced) examples.

A web site uses a properly marked up username (or email) and password fields as the login authentication (meeting Success Criterion 1.3.5 Input Purpose and Success Criterion 4.1.2: Name, Role, Value). The user's browser or integrated third-party password manager extension can identify the purpose of the inputs and automatically fill in the username and password.
A web site does not block paste functionality. The user is able to use a third-party password manager to store credentials, copy them, and paste them directly into a login form.
A web site uses WebAuthn so the user can authenticate with their device instead of username/password. The user's device could use any available modality. Common methods on laptops and phones are facial-scan, fingerprint, and PIN (Personal Identification Number). The web site is not enforcing any particular use; it is assumed a user will set up a method that suits them.
A web site offers the ability to login with a third-party provider using the OAuth method.
A web site that requires two-factor authentication allows for multiple options for the 2nd factor, including a USB-based method where the user simply presses a button to enter a time-based token.
A web site that requires two-factor authentication displays a QR code which can be scanned by an app on a user's device to confirm identity.
A web site that requires two-factor authentication sends a notification to a user's device. The user must use their device's authentication mechanism (for example, user-defined PIN, fingerprint, facial recognition) to confirm identity.

Related Resources

Resources are for information purposes only, no endorsement implied.

Techniques

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.

Sufficient Techniques

G218: Email link authentication
H100: Providing properly marked up email and password inputs
Providing WebAuthn as an alternative to username/password (Potential future technique)
Providing a 3rd party login using OAuth (Potential future technique)
Using two techniques to provide 2 factor authentication (Potential future technique)

Failures

The following are common mistakes that are considered failures of this Success Criterion by the WCAG Working Group.

F109: Failure of Success Criterion 3.3.8 and 3.3.9 due to preventing password or code re-entry in the same format

Key Terms

ASCII art

picture created by a spatial arrangement of characters or glyphs (typically from the 95 printable characters defined by ASCII)

assistive technology

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents

Note

Functionality provided by assistive technology includes alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).

Note

Assistive technologies often communicate data and messages with mainstream user agents by using and monitoring APIs.

Note

The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles.

Example

Assistive technologies that are important in the context of this document include the following:

screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc. in order to improve the visual readability of rendered text and images;
screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;
text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
speech recognition software, which may be used by people who have some physical disabilities;
alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices.);
alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.

Cognitive function test

A task that requires the user to remember, manipulate, or transcribe information. Examples include, but are not limited to:

memorization, such as remembering a username, password, set of characters, images, or patterns. The common identifiers name, e-mail, and phone number are not considered cognitive function tests as they are personal to the user and consistent across Web sites;
transcription, such as typing in characters;
use of correct spelling;
performance of calculations;
solving of puzzles.

conformance

satisfying all the requirements of a given standard, guideline or specification

human language

language that is spoken, written or signed (through visual or tactile means) to communicate with humans

Note