The World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) is finalizing the latest version of the Web Content Accessibility Guidelines 2.2 (WCAG 2.2). This blog post from Knowbility Digital Accessibility Specialist Melissa Green is the second in a series examining the new success criteria and other changes. WCAG 2.2 is also the topic of Knowbility's next Be A Digital Ally session, Thursday, February 16, 2023 at 5 PM Central Time (US and Canada). We will continue our exploration with a look at proposed criteria and changes related to navigation and focus: 2.4.7 Focus Visible, 2.4.11 Focus Appearance, and 2.4.12 Focus Not Obscured. Register for February BADA through Humanitix.
The Web Content Accessibility Guidelines 2.2 (WCAG 2.2) are currently at the Candidate Recommendation stage and will be finalized soon. Two of the newly-proposed success criteria address authentication:
Input Assistance
These proposed success criteria fall under the area of WCAG Guideline 3.3 Input Assistance, which reads "Help users avoid and correct mistakes". Everyone makes mistakes, but some people with disabilities may have more difficulty creating error-free input, or entering data that does not have errors. It may also be harder for disabled users to detect they have made an error because common ways of indicating errors may not be obvious to them because of a limited field of vision, limited color perception, or use of assistive technology.
What do we mean by "input"? People use different approaches to enter text and activate commands. For instance, some people do not use a mouse, keyboard, or both, while others use specific configurations for keyboard and mouse, or use alternative hardware and software altogether. Assistive technologies and strategies related to input can enhance the efficiency of typing, writing, and clicking, but web content must be designed to support these different kinds of approaches. The success criteria that fall under WCAG Guideline 3.3 Input Assistance seek to help users avoid and correct mistakes by providing assistance with input, including 3.3.7 Accessible Authentication at the AA level and 3.3.8 Accessible Authentication (No Exception) at the AAA level.
Accessible Authentication
"Authentication" can be understood as the process of "verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in a system" (National Institute of Standards and Technology). We'll look at several examples in a moment, but, for now, think about entering a username and password to log into an email account or responding to a push notification on your phone asking if that's really you logging into a new device. These are authentication methods.
The purpose of the Accessible Authentication success criteria is to ensure there is an accessible, easy-to-use, and secure method to log in, access content, and undertake tasks that does not rely on a cognitive function test.
Cognitive Function Test
A cognitive function test is "a task that requires the user to remember, manipulate, or transcribe information" (WCAG 2.2 Glossary).
"Remember" refers to remembering a site-specific username, password, set of characters, images, or patterns, which may be difficult or impossible for people with cognitive issues relating to memory. For purposes of this definition, recalling something personal to you – like your name, email address, and phone number – is not considered a cognitive function test because they are personal to you and consistent across websites.
"Transcription" refers to entering data, such as typing in characters. An example of an authentication process that requires transcription is receiving a two-factor authentication code or other value that you have to type into a site. A CAPTCHA could be considered a cognitive function test if the user must transcribe the text they are presented with. Transcribing can be problematic for people with cognitive issues relating to memory, reading (for example, users with dyslexia), numbers (for example, users with dyscalculia), or perception-processing limitations.
"Manipulate" refers to things like spelling correctly, performing calculations, and solving puzzles. These may be good useful tools for distinguishing humans from bots, but may make it difficult or impossible for people with cognitive disabilities to access and use a site. Whether it is remembering random strings of characters, a pattern gesture to perform on a touch screen, or identifying which images include a particular object, cognitive function tests will exclude some people.
Such tests are known to be problematic for many people with cognitive disabilities. Whether it is remembering random strings of characters, a pattern gesture to perform on a touch screen, or identifying which images include a particular object, cognitive function tests will exclude some people.
3.3.7 Accessible Authentication (AA)
The proposed 3.3.7 Accessible Authentication criterion reads:
"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.
Note: Objects to recognize and user provided 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."
In other words, the 3.3.7 Accessible Authentication criterion states that, when a cognitive function test is used, at least one other authentication method must be available which is not a cognitive function test. If there is more than one step in the authentication process, such as with multi-factor authentication, all steps should comply with this Success Criterion. There should be a path through authentication that does not rely on cognitive function tests. This is a AA criterion. Let's break it down a bit more.
Accessible Paths to Authentication
The proposed 3.3 Input Assistance criteria state that we should not require a cognitive function test UNLESS we also offer an alternative – another authentication method that does not rely on the test – OR a mechanism to assist the user in completing the test. At the AA level, we also have the option of requiring users to recognize objects or identifying non-text content the user provided to the website.
Alternatives
The proposed criterion states that, when a cognitive function test is used, at least one other authentication method – an alternative authentication method – must be available which is not a cognitive function test. Some ideas:
Biometrics
Biometrics are unique physical characteristics, such as fingerprints, that can be used for automated recognition. Most mobile phones now have some sort of biometric authentication built in, like Face ID, Touch ID, or voice recognition.
USB Tokens
USB tokens are another good alternative authentication approach. A USB token is a secure hardware device, often resembling a flash drive, that a user can connect to a computing device to verify their identity.
Authentication Links
Authentication links provide a way for users to authenticate without a password. These are sometimes referred to as "magic" links because a user gives an application an email address and then clicks the magic link that is sent to their email – and, voilà, they’re logged in. The following screenshot is from Slack's magic link workflow. A user has entered their email address, and this message directs them to check their inbox for a link that will sign them into the Slack workspace of interest.
OAuth
OAuth could also be used to provide an accessible path. OAuth is "an open protocol to allow secure authorization in a simple and standard method from web, mobile, and desktop applications." "It's a system that allows for Authentication to be relegated to another party. This means you can use login credentials from one provider to log onto the systems of another provider. For example, you can use google or apple login information to identify yourself in a game on your smartphone". The following screenshot is of the eBay sign in page. There are options for logging in with Facebook, Google, and Apple.
Provide Multiple Ways to Authenticate
One of the best approaches is providing multiple ways for people to authenticate. Duo, a service used for multi-factor authentication – or providing multiple levels of account security – allows users to verify their identity via SMS, voice call, one-time passcode, the Duo Mobile smartphone app, or a hardware token, among other ways. The following screenshot is of the Duo interface showing multiple authentication methods, "Send Me a Push", "Call Me", and "Enter a Passcode".
Mechanism
To conform with this success criteria, if we require a cognitive test, we must provide support for, or do not block the use of, mechanisms that can assist the user in completing the task. 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.
Web sites can employ username (or email) and password inputs as an authentication method if they allow browsers and third-party password managers to fill in the fields automatically.
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 interface 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.
Object Recognition
At the AA level, we can require an authentication task based on recognizing generic objects. If you think this sounds like a CAPTCHA, you are not alone, and there has been a lot of discussion around this in accessibility circles. CAPTCHA stands for "Completely Automated Public Turing test to tell Computers and Humans Apart". It is an approach to distinguishing human users of web sites from robots. The traditional CAPTCHA approach asked users to identify obscured text in an image, but other approaches have emerged – like audio CAPTCHA, logic puzzles, visual comparison based on the identification of still images.
At this time, the draft criteria read as if they support the use of CAPTCHA, but the Understanding document that explains the intent of each criteria advises caution: "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 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".
This may continue to evolve as WCAG 2.2 is finalized. What we know for sure is that CAPTCHA is inaccessible to many people and we should strive to avoid it.
Personal Content
At the AA level, it is also acceptable to provide a test where you ask the user to identify an image, an audio, or a video that they themselves have provided in the past. You could, for example, pop up five profile pictures and ask them to pick their own, or maybe five pictures of pets and ask them to pick their own. Notice that the content must not be text. Having to type an answer to security questions, like what is your pet’s name or what street did you grow up on, WOULD be considered a cognitive function test and would still need some support or an alternative.
3.3.8 Accessible Authentication (No Exception) (AAA)
The 3.3.8 Accessible Authentication (No Exception) criterion is the same as 3.3.7 Accessible Authentication but without the exceptions for objects and user-provided content. In other words, to achieve conformance at the AAA level, you must provide a path to authentication that is not a cognitive function test and that path cannot rely on recognizing objects or pictures or identifying content that the user has provided to the website.
Benefits
The primary benefit of 3.3.8 Accessible Authentication (No Exception) is that people will not have to rely on their cognitive abilities to authenticate themselves. This benefits everyone, but especially people with cognitive issues relating to memory, reading (for example, dyslexia), numbers (for example, dyscalculia), or perception-processing limitations. Having multiple, accessible paths to navigation also benefits those who have difficulty typing, writing, and clicking, or are more likely to make mistakes.
WCAG 2.2 Resources
Knowbility will continue our exploration of the new success criterion in our next Be A Digital Ally session, "What's New in WCAG 2.2?," February 16, 2023 at 5 PM Central Time (US and Canada). Register for February BADA through Humanitix. Keep an eye on our website and social media for more in-depth blog posts, webinars, and other WCAG 2.2 learning opportunities.
Resources from the W3C Web Accessibility Initiative:
- WCAG 2.2 Draft: Latest published version of WCAG 2.2. Currently at the Candidate Recommendation stage, we expect WCAG 2.2 to be finalized in early 2023.
- What's New in WCAG 2.2 Draft: Explanation of the proposed new success criteria with examples.
- WCAG 2.2 Supporting Documents: Quick references, guides, and techniques for understanding and meeting WCAG 2.2
- WAI Resources: This page lists W3C WAI technical and educational resources and should be updated to include WCAG 2.2 following its publication as a recommendation.