With Web Content Accessibility Guidelines (WCAG) version 2.2 we also got two specific success criteria for authentication – the 3.3.8 Accessible Authentication (Minimum) on level AA and the 3.3.9 Accessible Authentication (Enhanced) on level AAA.
In this post I will provide some simple practical tips, to hopefully help you making authentication a bit more usable and accessible.
Use best practices
Before we even discuss more I want to remind you about the basics. Authentication usually involves forms and forms need to be accessible before we even consider how to actually authenticate users.
Therefore please consider:
- Form semantics.
- Labeling input fields.
- Writing good instructions.
- Accessible form validation and status messages.
- Use autocomplete for known fields like email, name, address etc.
- Allow copy pasting into all fields, including password fields.
- Use CAPTCHA alternatives or make sure CAPTCHA really is accessible.
Offer alternatives, don’t force users to use a single way
Remembering hundreds or even thousands of passwords is difficult. Some people also don’t trust password managers or sometimes even can’t install them. Using different devices and different browsers makes things even worse.
So the best solution is to offer alternatives. I am aware that not all of them may be applicable for your service or product and sometimes you are perhaps even forced into using a single alternative by local legislation, but perhaps you can still try to offer multiple alternatives.
Magic links
So called magic links are great when we have access to our email on the device and when we use a single browser. If user don’t have access to their email on the device then it can be even worse for them – having to first login to their email can even create more privacy issues, so I would not suggest it as a single alternative.
Third party authentication providers
Using third parties can often help, but we need to make sure about their accessibility before we use them. Some Open Authorization providers (shortly oAuth) include a very simple technical mechanisms, usually with a link that checks if we are already logged in with the provider (often social media) and then redirect us accordingly.
Usually the third party solutions are simple to implement, but we need to be aware of the potential privacy concerns and, as mentioned, we need to be sure the whole flow is accessible. Check if they provide accessibility conformance reports (ACRs) before using them. That is the least you can do.
But to make sure you are not introducing new accessibility issues or even total show stoppers – perhaps go further with it. Some third parties include accessibility issues when we test all scenarios (not just the happy ones when everything works), so we need to make sure to check all parts of third party implementation before we use them.
Sometimes we don’t have a lot of choices (especially public sector services) and we are forced to use some national authentication solutions. We are also responsible to check their accessibility as they can still include accessibility issues, even if they are provided but the government. Please don’t just refer to their accessibility statements (public sector in Europe will include accessibility statements for their services), as they are often out of date. According to most legislation they need to be updated at least once per year and unfortunately they often just update the date (if they even update them).
In 2024 I did some accessibility auditing of native mobile applications and websites, both private sector and public sector ones, and I quickly checked some government and social media provided authentication solutions and found that sometimes their accessibility statements and accessibility conformance reports are extremely out of date or even incorrect. Even if it is out of our scope we should do our own due diligence and check at least basic accessibility of them before trusting their own evaluations.
Web Authentication API (WebAuthn)
It seems that WebAuthn (opens in new window) is quite under-used and perhaps needs more awareness and implementation. WebAuthn abstracts a lot of best practices and also uses the platform and available hardware, giving users a lot of possibilities. Some can therefore use biometrics or just a simple codes, some prefer physical codes in form of hardware and cards and some use facial recognition.
I think we need to make WebAuthn more common as it will provide a lot of benefits, not only for people with disabilities but for all of us that dislike passwords. It is still a technology meant for devices we trust and control though, so it’s just a single alternative, but I totally see a lot of benefits comparing to third parties and other methodologies.