Form validation

Interaction methods

Mouse interaction

1. On submitting invalid data, display specific messages next to fields and, when appropriate, a summary with correction links.
2. Clicking a summary link leads to the corresponding field on the same page and positions focus for correction.
3. Preserve entered data, including values needing correction.

Keyboard interaction

1. Tab and Shift + Tab move through fields, the submit button, and summary links in interface order.
2. Enter or Space activates the submit button; Enter activates summary links.
3. After a rejected submission, place focus on the summary or first invalid field according to the chosen pattern.
4. During validation on leaving a field or while editing, maintain focus flow and text entry.

Gesture interaction

1. Tapping the submit button allows form validation.
2. Tapping a summary link leads to the field; the message remains available for consultation and correction.

Keyboard (or gesture) interaction + screen reader

1. When navigating to an invalid field, present its label, error indication, and associated message through aria-describedby, while preserving the association with instructions.
2. Use aria-invalid to indicate a detected error; update the state when the error is corrected and new validation confirms the correction.
3. If focus moves to a summary, allow its title, errors, and links to be read. If focus stays where it was, announce dynamic errors through an update region appropriate to the context.
4. Avoid announcing the same message simultaneously through focus and several aria-live.

Correction and resubmission

1. After a confirmed correction, remove or update the message and corresponding summary entry without clearing other errors.
2. Resubmitting performs the necessary validation; confirm success only after the operation completes.
3. For asynchronous checks, communicate progress and prevent old responses from replacing the result for the current value.

Gherkin

BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).

Scenario: Given that I am on a page containing a form with validation

Keyboard navigation

1. WHEN I use Tab key to move focus to the submit button
2. The focus I SEE is strongly indicated visually
3. THEN, when I use Enter or Space to submit invalid data
4. I SEE messages identifying fields with errors and explaining how to correct them
5. AND I perceive focus moved to the summary or first invalid field according to the defined pattern
6. WHEN I use Tab to focus a summary link and Enter to activate it
7. I SEE focus reach the corresponding field on the same page and I can correct it

Desktop screen reader

1. WHEN I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and submit a form with invalid data
2. I HEAR or perceive that submission was not completed and there are errors to correct
3. THEN, when I use Tab to navigate to an invalid field
4. I HEAR its label, error indication, and correction guidance
5. AND, when I use Enter to activate a summary link, I perceive that I reached the corresponding field
6. I HEAR or perceive messages without unnecessary duplicate announcements

Mobile screen reader

1. WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and submit a form with invalid data
2. I HEAR or perceive that submission was not completed and there are errors to correct
3. THEN, when I swipe to navigate to an invalid field
4. I HEAR its label, error indication, and correction guidance
5. AND, when I double-tap or use the appropriate gesture to activate a summary link, I perceive that I reached the corresponding field
6. I HEAR or perceive messages without unnecessary duplicate announcements

Correction and resubmission

1. WHEN I correct a field and new validation confirms the correction
2. I SEE that field's message and invalid state updated, preserving other errors and entered values
3. THEN, when I submit the form with all valid entries
4. I SEE or HEAR confirmation only after the operation completes

Validation while editing

1. WHEN validation occurs on leaving a field or during a specific check
2. I SEE or HEAR a message at the defined time without premature errors before entry
3. AND I perceive that focus and typing were not interrupted

Considerations

1. Prefer concrete messages, such as "Enter an email in the format name@example.com", rather than just "Invalid value".
2. Distinguish empty required fields, incorrect formats, and business rules. Do not treat connection failures or unavailable services as entry errors.
3. Do not rely solely on red borders, icons, or temporary messages. Keep guidance until the correction is confirmed.
4. Associate the error with the field using aria-describedby and preserve existing instructions in that association. Use aria-invalid only when an error is detected.
5. The summary complements messages next to fields. Its links must tell screen reader users that they lead to fields on the same page and move focus to the appropriate destination.
6. Choose between a focus announcement and a dynamic region according to the flow. Use role="alert" only when urgency justifies it; role="status" may serve for nonurgent updates. Avoid announcements on every key.
7. Preserve values after an invalid submission. Do not include passwords or other sensitive data in summaries or status messages.
8. Client-side validation helps provide guidance, but server-side validation remains necessary. Asynchronous checks must consider the current value and report check failures.
9. Do not disable the submit button as the only indication of problems: the person needs to know what is missing and how to correct it.
10. For supplementary icons, prefer Material Icons and hide decorative ones from assistive technologies; the information must remain available in text.
11. Bootstrap documents accessibility limitations in its custom client validation styles and tooltips. Evaluate examples before adopting them; colors and styles do not guarantee accessible association or announcements.

References

Design patterns

• W3C WAI — User Notification open_in_new (external link, opens in a new tab) — Errors, notifications, and feedback after form submission.

Design System

• GOV.UK — Error message open_in_new (external link, opens in a new tab) — Messages associated with fields and correction guidance.
• GOV.UK — Error summary open_in_new (external link, opens in a new tab) — Error summary, links to fields, and focus management.
• USWDS — Validation open_in_new (external link, opens in a new tab) — Validation and feedback on entry requirements.
• Bootstrap — Validation open_in_new (external link, opens in a new tab) — Validation examples and documented accessibility limitations.