Cover: AI-generated concept illustration, not an actual product interface.
A form error is useful only when a person can understand it, reach the affected field and correct the problem without losing their work. Test that whole recovery path, not just whether invalid input is rejected.
Consider a small property enquiry form with an email field, an optional phone field and a message. A visitor writes a careful question, mistypes an email address, presses Submit and receives a red border. The validation rule might be correct. The experience is still incomplete if the visitor cannot discover what went wrong or if the message disappears.
The following plan uses a fictional form. It is a starting point for development and review, not a claim that the form meets every accessibility requirement. The proposed tests have not been executed against a production application.
Start with a contract a tester can read
Before choosing a validation library, write a short table of the fields, why each is collected and the accepted input. In this example, email is required because the visitor expects a reply. Phone is optional. The message must be present and stay within an explicitly displayed length limit.
Avoid adding rules simply because they are easy to express as a regular expression. If the business does not need a phone number, it should not block an enquiry over a missing one. If a field does have a limit, state it before submission rather than revealing it only after someone writes a long message.
W3C's validation tutorial recommends using appropriate HTML validation features and accommodating reasonable variations in input. It also explains why client-side checks cannot replace server-side validation. A script can improve feedback, but the server must still enforce the application's rules. [1]
Treat the table as a review artifact. A designer can check the wording, a developer can implement the rule, and a tester can create cases without guessing which behavior is intentional.
Separate the initial state from an error state
An untouched form should not start by accusing its visitor of making several mistakes. For a custom validation flow, decide when an error becomes visible and when it is cleared. A simple starting policy is to report errors after a submission attempt, then update the affected field as the visitor corrects it.
MDN describes aria-invalid as a state that communicates an unacceptable value. It should reflect validation results, rather than marking untouched required controls invalid immediately. The attribute does not supply the explanation itself. A user still needs a useful message. [2]
For example, the following is a static illustration of one field after validation has failed, not a complete working form:
<label for="contact-email">Email address (required)</label>
<input id="contact-email" name="email" type="email" required
aria-invalid="true" aria-describedby="email-error">
<p id="email-error">Enter an email address with a name and domain.</p>
In the implemented form, the error text and invalid state must change together. When the value is accepted, remove the obsolete error association or update its content appropriately, and clear the invalid state. Do not leave a screen reader describing an error that is no longer on screen.
Test whether the message points to a repair
“Invalid input” tells a visitor almost nothing. The message should identify the field and explain a reasonable correction. Keep the wording consistent with the visible label so the visitor does not need to translate between “Email address” on the form and “contact identifier” in the error.
W3C's notification tutorial describes both overall feedback and messages beside individual controls. It also shows how aria-describedby can associate a field with its error text. These are useful building blocks for a recovery path that remains understandable without relying only on color. [3]
For this fictional form, test the copy with three distinct problems: missing email, malformed email and a message beyond the displayed limit. Ask a reviewer to explain the next action using only the error text. If they have to inspect developer logs to understand it, the message needs another pass.
Keep implementation details out of public error copy. A validation failure does not require a visitor to know an internal field name, database constraint or exception class.
Make keyboard recovery part of the acceptance test
Use the form without a mouse. Reach every control, submit invalid data and check where focus goes. If an error summary is used, its links should lead to the corresponding controls. If focus moves to the first invalid field instead, confirm that the associated explanation is available there.
The exact interaction should be intentional and consistent. Moving focus repeatedly while someone is still typing can make the form harder to complete. Test correction and resubmission as well as the first failure.
Write down the browser, operating system and assistive technology used for each manual check. “Tested with a screen reader” is too vague to reproduce. A successful run in one combination is useful evidence, but does not establish universal compatibility.
Include a narrow viewport and increased zoom in the review. Error text should remain readable and should not cover the control or push an important action into an unreachable area.
Preserve input and tell the truth about submission
Make a synthetic test message long enough that losing it would be noticeable. Trigger each recoverable field error and confirm that the message stays in the form. Repeat with a server validation response. A frontend-only happy path can hide problems introduced when the server returns a different error shape.
Keep validation failure separate from an uncertain network result. If a request times out after leaving the browser, the interface may not know whether the server accepted it. Do not label that state “sent” merely because Submit was clicked, or “not sent” without supporting evidence.
For an application that needs duplicate protection, design that behavior on the server and test it separately. Disabling a button can reduce accidental repeated clicks, but it does not prove that only one record can be created. This article's validation checklist does not implement request deduplication.
Original proposed testing flow. It illustrates expected states, not results from an implemented system.
Keep a small, repeatable regression set
Record at least these cases: untouched form, missing required email, malformed email, optional phone left blank, message at the allowed boundary, message beyond the boundary, correction after failure, server-side rejection and an uncertain network response.
For each case, capture the expected field state, message, focus behavior, retained values and submission outcome. Use synthetic contact details; there is no need to place real enquiries in a test fixture. Add an automated check where it is reliable, then keep the keyboard and assistive-technology review explicit rather than treating a green test suite as a complete accessibility audit.
The final question is practical: can a visitor discover the problem, fix it and continue with confidence? A good validation rule is one part of that answer. Clear messages, stable input and honest submission states complete the recovery path.
Sources
[1] W3C WAI, Validating Input: https://www.w3.org/WAI/tutorials/forms/validation/
[2] MDN, aria-invalid: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-invalid
[3] W3C WAI, User Notifications: https://www.w3.org/WAI/tutorials/forms/notifications/
Top comments (0)