Password Rules Revealed Only After a Mistake

Rules you learn by breaking them

A customer creates an account on an online shop, a booking system or a client portal. They fill in their name, email and address, choose a password and press the button.

The page reloads with a red message at the top: the password must be at least eight characters, contain a number and include no spaces. Nobody mentioned this before.

Often the form has also emptied itself. The name and address are gone, and the customer starts again, guessing at whatever other rules there might be.

Some try twice. Some close the tab.

Who pays for the guessing

• Screen reader users, who may never hear an error that appears silently.
• People with dyslexia or memory difficulties, for whom retyping is real work.
• Phone users, typing on a small keyboard into a field that hides every letter.
• Password manager users, whose generated passwords break rules nobody stated.
• Older customers, who may read the reload as their own failure.

The first group is hit hardest. A red outline or a message that simply appears on the page is not announced unless the form is built to announce it, so the user may not know why the form came back.

What WCAG asks for

WCAG 2.0, the reference standard for accessible websites, covers this in three places.

Forms should provide labels or instructions wherever they ask for input. Errors that are detected should be identified and described in text. And where the fix is known, the form should suggest it.

Password rules are known before anyone types. That makes them instructions, and instructions belong with the field, not in an error that follows it.

Put the rules beside the field

Write the rules in plain words directly under the password label, before the box: at least eight characters, including one number. Spaces are fine.

Ask whoever builds the form to connect that sentence to the field in the code, using an attribute called aria-describedby, so a screen reader reads it out when the field is reached.

Do not put the rules inside the box as grey placeholder text. It disappears the moment typing starts, which is exactly when people need it.

Fewer rules, stated plainly

While writing them down, ask why each rule exists. Many came with the software and were never chosen by anyone.

A ban on spaces, a short maximum length or a list of forbidden symbols makes long passphrases impossible and trips up the passwords that password managers generate.

If the system genuinely requires them, say so. If it does not, ask whoever maintains it whether they can go.

A worked example

A car share co-op with about thirty cars, parked in reserved spots across several neighbourhoods, takes new members through an online application.

The form asks for contact details, a driver's licence number and a password for the booking system. Its password rules appeared only after a mistake.

After an error, the page reloaded with the rules at the top and every field empty except the email address. Applicants retyped their licence details two or three times, and some phoned the office instead.

The office had been taking those calls for two years without connecting them to the form.

The rules now sit beside the password field, connected in the code. The no-spaces rule went, after the booking system's supplier confirmed spaces were fine.

After any error, the form keeps everything except the password fields, says which rule was missed beside the field, and lists the problem at the top with a link to it.

When something still goes wrong

Errors will happen anyway. Say exactly what failed, next to the field: needs at least one number. A message that only says invalid password tells nobody anything.

Put a short summary at the top of the form as well, listing each problem with a link that jumps to the field, and move the focus there so a screen reader reads it.

Never rely on colour alone. A red outline means little to someone who cannot see red, and nothing at all to a screen reader.

Some forms tick off each rule as the person types. That helps, provided the ticks are announced to screen readers too and the written rules stay on screen.

Keep what they typed

A form that empties itself after one mistake doubles the work and invites new mistakes.

Keep every field the person filled in. Clearing the password boxes is normal for security, but say so beside them, so the empty field is not a mystery.

That includes choices made from lists and ticked boxes. Retyping a long number on a phone keyboard is exactly where the next mistake comes from.

Let people see the password

A password field hides each character, which makes typing errors invisible, especially on a phone.

A show password option lets people check before pressing the button. It helps everyone, and it can replace the second box that asks for the same password again.

Test it yourself

Create an account on your own site with a deliberately wrong password, first on a phone and then using only the keyboard.

Then try it by ear. Every iPhone and Mac includes the VoiceOver screen reader, and Windows users can download a free one.

Listen for the rules before you type, and for the error after. If you hear neither, nobody else does either.

The counter-case

Some sign-up forms belong to a hosted booking or payment service that the business cannot change. There, write the rules in the text just above the embedded form and ask the supplier to fix the rest.

And for many small shops the simplest answer is no account at all: a guest checkout asks for no password, so there are no rules to hide.

Wherever a password is required, though, state the rules before anyone types and keep what people entered.

On the sign-up form

1. Create a test account with a wrong password.
2. Write the rules beside the field.
3. Connect them in the code for screen readers.
4. Drop rules nobody can explain.
5. Keep entered fields after an error.
6. Name the exact problem beside the field.
7. Add a show password option.

Step two removes most of the problem by itself. When the rules are visible before anyone types, people can meet them on the first attempt, and the error path becomes the exception.

Letting people review what they are about to send is covered in orders that cannot be checked before sending.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.