A person creates a password, submits the form and is told that it fails an undisclosed rule. They try again and encounter another rule. The form has turned a predictable requirement into a guessing game.
Show the actual requirements before the person begins. Keep the explanation close to the password field and make it available to assistive technology through the form’s supported labelling and description structure.
Explain the real policy, not a generic example
The W3C tutorial on form instructions recommends telling people about required formats and constraints. Instructions that disappear when typing begins are less useful than guidance that remains available.
This is a presentation principle, not a recommendation to invent a particular password-composition policy. Security requirements should be chosen and maintained by the responsible team. The interface must accurately describe the rules the server actually enforces.
Test the rule and the message together
For an illustrative form, the help text says a minimum length is required, but the server also rejects certain characters without explanation. The visible instructions are incomplete even if the error handling works technically. Fix the discrepancy rather than adding another vague “invalid password” message.
Check boundary cases against the documented policy. Confirm that pasted values and password-manager input are handled appropriately. Do not log or include the entered password in analytics, support screenshots or error reports while diagnosing the form.
Make correction local and understandable
After a failed submission, identify the field and explain the unmet requirement in plain language. Do not rely only on a red border. Preserve unrelated valid information where appropriate, so correcting one field does not force the person to complete the whole form again.
If a live checklist is used, test it with keyboard navigation and assistive technology. An attractive row of checkmarks can still be confusing if changes are not conveyed or if the list contradicts the final submission check.
The final review question is practical: can someone understand the requirements before entering a secret, and understand the next step after an error? A form that answers both questions reduces avoidable retries while keeping the underlying policy explicit.