Password

Password requirements checker

• Use bullet points to list the password requirements and keep them visible when the component is selected.
• Include information about symbols, types of characters, case sensitivity, special formatting, size, range, or length restrictions.

Requirement text examples

• Minimum of [number] characters
• At least 1 capital letter
• At least 1 number
• At least 1 special character

Hint text

• If paired with the password requirements checker, use hint text to generally describe what a password should be.
• For example, that it must be a strong or long password.
• Do not describe specific requirements in the hint text.
• End hint text with a full stop if possible. This makes screen readers pause before reading out any error or warning message after the hint text.

Error messages

• Do not use specific error messages if they will cause duplication of content. For example, referencing text in the password requirements checker.
• Instead, use a generic error message to communicate the problem and how to fix it.

Password reset

Requirements

Users should be able to:

• Enter or create a password using assistive technology.
• Understand password requirements before and during password creation.
• Toggle the visibility of a password.

Interactions

Users should be able to toggle the visibility of their password, as some users with cognitive impairment may find it difficult to remember what they have typed if they are unable to see the password.

Users should also be allowed to copy and paste their passwords into a field, or autofill passwords from a password manager. This can help some users with motor impairments or memory limitations.

Keyboard interactions

• Tab. Moves focus from the previous interactive element on the page to the password input field.
• Users should be able to type or copy and paste into the password field.
• Pressing tab again moves focus to the visibility toggle.
• Space. Pressing space on the password toggle toggles the visibility of the password field.
• Enter. Pressing enter on the password input submits the password form.

Design considerations

• Avoid overly strict password requirements, as this can make it more difficult for users to remember their passwords.
• Avoid using color alone to communicated that passwords are incorrect or that requirements have not been met. Use additional visual cues to relay this information.
• Make sure the borders of the input have a 3:1 minimum contrast ratio with the background.  
• The visibility toggle button should have clear, visible button name, given by the inner text.

Development considerations

• The input field should have a visible label, associated with the password field using the for attribute, pointing to the id of the password field.
• The input field should have , so it inherits the secure input of password field types.
• The button to toggle the visibility of a password should have a clear aria-pressed state to communicate the current state to screen reader users.
• Hint text communicating password requirements should be associated with the password field using aria-describedby.
• Use the autocomplete attribute to allow users to autofill passwords.
• For a new password, the new-password token should be used.
• For an existing password, the current-password token should be used.
• Use the required attribute to communicate to screen reader users that a password is required.
• If the password requirements are dynamic, any updates should be communicated to screen reader users using an aria-live region, relaying the changes or updates.