The Web Content Accessibility Guidelines version 2.2 introduces new requirements for accessible authentication. Success Criterion 3.3.8, “Accessible Authentication (Minimum),” prohibits requiring cognitive function tests as part of an authentication process, with several exceptions.
Content creators can use a range of techniques to fulfill this criterion — but one of the most effective is to use access delegation protocols like Open Authorization (OAuth) or solutions like Web Authentication (WebAuthn). That prompts an important question: Do these solutions impact security?
The answer, of course, depends on the implementation. Here’s what developers should know.
For the purposes of this article, we’re focusing on OAuth, which is one of the most widely used security protocols. OAuth is accessibility-friendly: Users can quickly login to websites by using credentials from other websites (for example, their preexisting Google or Facebook accounts).
This “secure designated access" can enhance privacy and security. It doesn’t require memorization, which can cut out a key security issue: One study from Security.org found that 68% of American adults use the same password across their online accounts, which certainly isn’t ideal.
And since unique authentication tokens are created for every user, tokens can be immediately deleted if compromised by bad actors. OAuth is more convenient, accessible, and secure than traditional password-sharing — but only when implemented correctly.
Related: 5 Quick Ways to Check Your Site Against New WCAG 2.2 Standards
Recently, security researchers at Salt Labs discovered OAuth implementation issues that could potentially affect millions of users on hundreds of websites. Several major websites mishandled access token verification, which could allow attackers to collect tokens with fraudulent websites, then use those tokens to access private data on legitimate websites.
The OAuth issue, while serious, is an error with implementation, not with the technology. Regular audits should be part of your business’s security/privacy strategy, and developers must follow best practices when implementing any authorization protocol.
For OAuth specifically, that includes:
This is not a comprehensive list of best practices. Your OAuth implementation should be carefully vetted and validated. To be clear, that’s equally true for every authentication method.
Related: Google’s Passkeys Provide Accessible Alternative to Passwords
It’s important to note that WCAG 2.2 Success Criterion 3.3.8 doesn’t force you to use OAuth, WebAuthn, or any other authentication/authorization solution. You simply need to limit cognitive function tests.
You can do that with a traditional password login. Requiring users to remember their passwords qualifies as a cognitive function test. However, if your website allows people to copy and paste their passwords or use password managers, that’s sufficient for WCAG conformance.
You’ll also need to review your use of captchas (Completely Automated Public Turing Tests) and two-factor authentication requirements. For additional guidance, read: How To Make Your Website's Authentication Process Accessible.
To balance security and accessibility, the best practice is to work with an accessibility partner when making decisions about your user authentication processes — particularly if your website stores credit card numbers or other personally identifiable information (PII).
If you’re ready to test your website for conformance with WCAG 2.2, we’re here to help. Get started with a free automated web accessibility analysis. To discuss a specific accessibility issue, send us a message and connect with an expert.