Logins are critical to the digital world. We need them to keep the bad guys out of our stuff. This includes everything from our email, bank, social media, and e-commerce accounts. And that necessarily creates barriers, which can sometimes present login accessibility issues. UX, engineering, and security professionals designing login systems have the difficult task of balancing ease of use with safeguards to keep bad actors out. Following accessibility principles and best practices, including new success criteria for accessible authentication in the brand new WCAG 2.2 release, can ensure that login systems don’t lock out people with disabilities.
Logins are usually forms
Some newer authentication systems rely on methods such as fingerprint biometrics, facial recognition or device-based authentication. Those systems have their own accessibility considerations, some of which are beyond the scope of this article. But most logins on the internet are still forms. So, unsurprisingly, the best way to create an accessible login experience is to build accessible forms.
Accessible login field and button labels
As with all forms, labels are important to making clear the purpose of all fields and buttons within a login. Logins are usually very short forms, which makes these recommendations easy to address (though you should also apply them to all forms sitewide).
Field labels should be visible
Make sure that labels are placed in a predictable place that makes it clear which field they belong to. Avoid using placeholder text as a pseudo label. Placeholder text disappears once a user types something into the field (and is often displayed in low contrast text colors).
Programmatic field labels
All fields should also be programmatically associated with a <label> element. There are two ways to accomplish this:
Option 1: Wrap the visible label and field input inside the <label> element. See code sample below.
<label>
Email address:
<input type="username" name="email">
</label>Option 2: An even better option is explicitly mapping the label element to an input id. The “for” attribute of the label should exactly match the form field id.
<label for="email">Email address</label>
<input type="username" name="email" id="email">Make fields autocomplete friendly
Many users have a hard time remembering or manually typing their passwords. You should code your form fields to ensure that password managers and browser autocomplete functions can successfully provide the relevant username, email and password. Generally the account username or email field should be assigned a type=”username" or type="email" value. The password field should be assigned type="current-password".
Label submit buttons
Make sure to provide a submit button for your form and to include a label within the <button> element.
Subscribe to our Newsletter
Instructions, errors and other messages
Login forms are usually fairly simple, which means you won’t need too much in the way of instructions. But you do want to make sure that you provide enough information to make filling out the form easy. And if users do run into trouble, alerts and errors should be provided to make clear how to correct the form.
- Indicate required fields: Typically all fields in a login form are required. But it’s still a good idea to indicate this whether in a form legend or within each field label. If you are using a symbol like an asterisk (*) to indicate required fields, don’t forget to explain this in the form legend. Don’t forget to also add the required attribute to each field in code.
- Don’t rely on color only: Errors or missing required fields should be output as text. Changing a field label or outline to red is insufficient and would not be noticed by blind, color blind or other users with visual impairments.
- Provide errors and notices programmatically: Adding role=”alert” to form errors ensures that they are announced to screen readers at the right moment and that they are properly contextualized. The same goes for success or confirmation messages, which should have role=”status”.
Passwords and cognitive function tests
Passwords inherently represent an accessibility concern. It can be challenging for people with memory difficulties or other cognitive limitations, including many older adults. Frankly, many users without any disabilities find it challenging to keep track of and recall all of their passwords. Security requirements that mandate regular password changes, minimum character lengths, and use of different types of characters make remembering passwords even more challenging.
Supporting autocomplete (which we’ve already addressed above) is one way you can address this issue. But when users are not on their regular device, they may not have access to a password manager or saved passwords. Here are some other accessibility features you can incorporate to mitigate password issues:
- Allow users to see the password as they type: As a security measure, many password fields obscure the text as a series of dots or asterisks. Users should be given the option to view the actual text as they type; this can make it easier to type a password especially when it is long of complex.
- Allow copy and paste: Users may have passwords stored in a document or offline password manager. Allowing them to copy and paste into the password field saves them the trouble of remembering the password or copying it character-by-character.
- Provide alternatives to passwords: Allow users to authenticate through another method instead of entering a password. This can include using a third-party provider, sending a one-time password, or allowing a user to authenticate via facial recognition, fingerprint or push notification on a separate device. Some of these methods can present accessibility issues of their own; these should be addressed and mitigated, but it is also a good idea to offer multiple choices so that users can select the option best suited to their needs.
Other considerations
CAPTCHAs
Some authentication systems employ CAPTCHAs or other cognitive tests (like math equations) to block or slow bots from trying to brute force login attempts. It’s important to note that this kind of barrier can also impact users with disabilities. The latest WCAG 2.2 release includes a new success criteria that does not allow the use of cognitive tests (beyond passwords) in authentication systems. This is true even if the CAPTCHA is only used in certain situations like repeated incorrect password submissions. There is currently an exception for object recognition CAPTCHAs (which are commonly used by Google’s popular reCAPTCHA service). However, these can present similar accessibility concerns and the WCAG 2.2 Level AAA includes a higher level success criteria that removes this exception.
Email accessibility
Authentication is a combined user experience between websites (or apps) and email. Most login systems rely on email for password reset, one-time password links, identity verification and other confirmations. It is important to ensure that your email templates are accessible as well. Email accessibility is a larger topic but these criteria are a good start:
- If your email relies on tables for layout, be sure to set add role=”presentation” to ensure that screen readers understand that they do not contain data
- Make sure that link labels are clear and informative
- Make sure that text and link colors have sufficient contrast. The WebAIM color contrast checker is a good resource to verify this.
- Avoid embedding text in images as the sole means of conveying information.
Third party login providers
Relying on a third party login system (including single sign-on services through Google or Facebook accounts) are a good way to reduce friction for users. They can also improve accessibility by allowing users to login without having to remember a unique password. However, placing any third-party service in a critical flow on your site makes it your responsibility when it comes to accessibility. Look for a VPAT or other documentation of accessibility from the third party; when in doubt, you should reach out directly to the vendor to inquire about accessibility and perform your own testing.
We can help
These techniques will ensure your logins are usable including by people with disabilities, assistive technologies like screen readers and also by password managers. If you aren’t sure whether your login systems are accessible or need guidance on implementation, we can help. Reach out today for a free strategy consultation.
