Websites need simple, secure ways to authenticate users. That typically means requiring users to submit passwords to verify their identity — but when improperly implemented, a password requirement can create a major accessibility barrier.
The recently published Web Content Accessibility Guidelines (WCAG) 2.2 Working Draft calls attention to this issue with a new proposed Success Criterion (SC) 3.3.7, “Accessible Authentication.” Here’s the full text of the new criterion:
For each step in an authentication process that relies on a cognitive function test, 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.
Passwords create a “cognitive function test" because they require users to remember information. Some people with cognitive disabilities are unable to remember site-specific passwords, particularly when password entries have strict symbols, numbers, and capitalization requirements. Users with dyslexia, memory issues, and perception-processing disabilities may not be able to fill in password fields easily.
Of course, passwords play an important role in protecting users' privacy — and WCAG 2.2 doesn’t prevent websites from using passwords for authentication. In order to pass WCAG SC 3.3.7, here are a few considerations to keep in mind.
Use proper markup to allow password managers to fill in fields automatically.
Most modern web browsers have built-in password managers, and third-party password manager extensions are widely available. These tools fill in username and password information automatically.
However, password managers rely on proper form markup to work properly. Form controls need to have appropriate accessible names. Otherwise, the tool may not be able to recognize fields like “username" and “password.” Developers can find additional guidance for creating accessible forms by reviewing WCAG SC 1.3.5, “Identify Input Purpose,” and WCAG 4.1.2, “Name, Role, Value.”
Websites should not block copy-and-paste functionality.
Some people may store passwords in text documents or offline password managers. They expect to be able to copy and paste information to authenticate their identities — but if a form doesn’t allow copy-and-paste functionality, they’ll need to enter their credentials manually. That’s not always easy, particularly for people with neurocognitive limitations.
Developers should allow copy-and-paste functionality wherever possible. If security concerns justify removing that functionality, make sure to provide login alternatives whenever possible.
If your website requires manual password entry, give users the option to see the characters they’re typing. This is also important for password creation fields; remember, some users have trouble remembering complex information, so take thoughtful steps to make this process easier.
Wherever possible, provide alternative options for authentication.
Passwords are an obvious authentication solution, but they’re not necessarily the most effective. In one 2020 survey performed by data loss prevention firm Digital Guardian, 61 percent of respondents admitted to using their passwords across multiple websites, and 44 percent said they changed their passwords once per year or less.
Poor password practices can compromise security, and many developers have turned to alternative authentication technologies to build more robust websites. Some of these alternatives are more accessible, and they can create a better user experience.
Web Authentication (WebAuthn)
The WebAuthn API is a strong authentication method that allows users to authenticate with their device — no username or password needed. It identifies the user’s device, which allows for a range of options; users may scan their fingerprint with a mobile device, enter a pin number, or use a facial scanner. Provided that your site doesn’t enforce a particular modality, WebAuthn complies with Success Criterion 3.3.7.
Third-Party Authorization and Authentication Protocols
Open Authorization (OAuth) and other access delegation protocols allow users to login to websites with accounts created on other websites. For instance, users may be able to log in with their Google, Twitter, Microsoft, or Facebook accounts.
OAuth is an authorization protocol, not an authentication protocol, so your website relies on the third party to actually authenticate the user. However, OpenID and other authentication protocols are available and may be preferable for some websites.
Put simply, third-party protocols can be a useful option for improving conversions, and they also provide an alternative to password entry that will accommodate some people with disabilities. These resources shouldn’t be used as the only means of authentication — some users won’t have OpenID accounts, and some won’t want to log in with their Facebook or Google accounts — but they’re helpful for some visitors.
Pay close attention to captchas and two-factor authentication requirements.
Finally, make sure your authentication process doesn’t introduce barriers through two-factor authentication. When multi-factor authentication requires user input, the safest course of action is to give your audience options: Some users might appreciate an SMS (phone text) authentication option, some might prefer email-based authentication, and others might prefer authentication apps like Google Authenticator or FreeOTP. Providing alternatives limits the risk of an accessibility issue. Plus, when people have more ways to access your website, they’ll be more likely to complete the required actions.
Likewise, captchas (or Completely Automated Public Turing Tests) and captcha alternatives help to distinguish between human users and computers, but they can prevent some people with disabilities from accessing your content. Offer alternatives to captcha that are accessible for your entire audience including people with vision, hearing, and neurocognitive disabilities. WCAG SC 1.1.1, “Non-text Content” provides additional guidance for using captchas thoughtfully.
By considering all of your users when building your site’s authentication process, you can improve the experience considerably for your entire audience. If you’re not sure whether your current authentication protocols are accessible, a WCAG Accessibility Audit is an excellent first step.
