Password Forms — 3 Ways to Make Them More Accessible

The Create Password form field on the Kiip website

I can’t tell you how many accounts I’ve created and the associated passwords that have come along with them. Don’t even get me started about how they have all sorts of different requirements –uppercase, numbers, the last 4 digits of your credit card (wait, what?)! We encounter password form fields so often that it’s easy to forget their importance. Unfortunately, vital aspects of password inputs are often not accessible. But that begs the question: what is the expected accessible behavior for a password input? We could only find a few resources and even resorted to Reddit threads (included below).

We believe Kiip is for everyone. With that said, creating an account shouldn’t be the first obstacle any user should come across! So we thought we’d share how Kiip implemented accessibility into our password form.

Here is a content table for this article:

1. The Problem
2. A Code Demo
3. The Basics
4. Tip 1: Show/Hide Password Toggle
5. Tip 2: Accessible Password Requirements
6. Tip 3: Password Progress Indicator
7. Further Suggestions
8. Resources

The Problem

There is a password input with a list of four requirements. As each of these gets satisfied, a checkmark icon appears; if not, an X mark appears. The icons update in real-time as the user’s input changes to meet requirements. A sighted user can see the icons change, but there is no indication for a visually impaired user. Users can toggle password visibility with a button, but we were unsure if there was a proper way to make it accessible.

A Code Demo

Below is an example of an accessible password input that solves the problem and implements all the tips featured later in this article. It is a simple recreation of how Kiip did it, but without design.

First, the Basics

If you are familiar with standard form accessibility rules, you can skip to the next section.

<label htmlFor="password">password</label>
<input
 id="password"
 autocomplete="new-password"
 value={password}
 required
/>

For any form input element, not just password inputs, several official WCAG requirements are needed to consider them accessible. So here are some of the basics you should be aware of:

• Every input should have an associated label. The elements can be linked by adding an ‘id’ to the input and a ‘for’ attribute to the label with that id as its value. As in, the label is for this id input.
  — Placeholder text cannot act as labels
  — This helps screen readers let users know what the input is for.
• If an input is required, you should use the HTML required attribute.
  — The label should also indicate that it’s required other than font color (commonly done with an asterisk *). However, this is design-wise debatable for single-input forms as it’s implied.
• Add the autocomplete attribute whenever appropriate.
  — You can find all autocomplete values on the mdn web docs
  — It can help users with cognitive or typing issues fill out forms quicker.

Passwords are an input with a specific purpose, so moving onward are some extra tips on how to engineer them in a way that reduces user barriers.

Tip 1: Show/Hide Password Toggle

A password input with show/hide toggle button and corresponding screen reader output.

In design best practices, single password input has become more accepted. But to get rid of the “confirm password” input, there should be a “show” button for people to double-check if it’s correct. The toggle button will help many users avoid mistakes and see the characters they’re typing. But if coded wrong, you might cause the password to be read aloud without warning and risk the user’s security.

The ability to toggle password visibility is especially useful for accessibility purposes:

• Screen readers can’t read password hidden text,
• Some people may have memory or cognitive issues,
• Those experiencing hand tremors are more likely to make typing mistakes,
• And so on.

Suggested Solutions:

• Use a button to display or hide the password. We used the word “show/hide,” but the “eye” icon is also common. Make sure to use an HTML semantic button instead of a custom <div>.
• Add role=’switch’ to the button to signal that users can toggle it on/off. You may have to include an aria-checked to the element as well.

Tip 2: Accessible Password Requirements

Notice how requirements are read after description of the input (due to aria-describedby).

When users fill out a form, it shouldn’t feel like a game where the rulebook is missing. Displaying password requirements help users know what pattern to expect when submitting. Adding requirements is also to help increase password security. However, depending on how you code the requirements, assistive technologies might not announce this information to non-visual users.

Suggested Solutions:

• Programmatically associate the requirements with the password input using aria-describedby={id-of-input}. This will allow screen readers to announce them the moment when users reach the input.
• Add a period (.) at the end of each requirement. This will create a “full stop” and prevent run-on sentences from a screen reader.
• If you use icons, like a check mark or an x mark, they should be programmatically associated with the corresponding requirement. How to do this is arguable, but in the code demo, we used a combination of an aria-label and aria-describedby. In this scenario, the icon is informational over decorative, so we should label it. Using an aria-label for the icon establishes its meaning or purpose, while the aria-describedby connects it to the requirement.
• An alternate solution would be to place the password requirements above the input. This will have screen readers read them aloud in browse or form mode regardless of labels. Design-wise, this is uncommon, but you can make them visually hidden in this case.

Tip 3: Password Progress Indicator (optional)

Password progress indicator and corresponding screen reader output.

In the last section, we learned how to make the requirements known to screen readers. An optional added bonus would be to add real-time validation of the requirements. It gives users immediate feedback about their new password. A way to do this would be to use visual check marks or bolded font as the user types. Symbolic icons can help those with dyslexia or other cognitive abilities register the change easier. But, as always, visual solutions should also have some behind-the-scenes work to make them more inclusive.

Suggested Solutions:

• Add visually hidden text that announces the number of complete requirements. Use styling and aria-live=”polite” to do this. This allows assistive technologies to observe the contents of this ‘live region’. By giving it a value of polite, screen readers won’t interrupt the user’s task. The message is only read once a user stops typing.
• Alternatively, you could include a ‘strength meter’ similarly. An example of such can be seen in a tutorial by W3C.

Further Suggestions

In this article, the explanations and code demo use plain javascript. However, on the actual Kiip website, we design our elements with the Chakra-UI component library. Chakra-UI has many wonderfully built-in accessibility features and out-of-the-box components, which is definitely worth looking into if you’re interested in coding for web accessibility.

Special thanks to Nicolas Steenhout’s article on password accessibility, as it was a hugely helpful resource.

Thank you for reading, and happy coding!

Resources

• https://incl.ca/show-hide-password-accessibility-and-password-hints-tutorial/
• https://www.w3.org/WAI/tutorials/forms/examples/password/
• https://www.reddit.com/r/Blind/comments/tl9vdm/accessible_behavior_for_new_password_requirements/
• https://webaim.org/techniques/forms/advanced#describedby
• https://dev.to/indieklem/8-uiux-tips-about-password-design-5bbn