Test form errors with a keyboard and screen reader

Check the starting form

Use the keyboard without a mouse. Confirm every field and control can receive focus, the focus indicator is easy to see, and the order follows the task. Check that each field has a visible label and that required fields are identified in text, not only by color or an icon.

Trigger validation

Submit the form with required fields empty, then enter a malformed value such as an invalid email address. Find out whether the page explains what is wrong and how to fix it. Error messages should be specific, visible, and programmatically associated with their fields; color alone is not enough.

Follow the focus and announcement

After submission, check where focus moves. A summary at the top can help users understand the number of errors, while each field should expose its own error. Test with a screen reader to confirm that the field label, value, and error can be understood together. If the form updates errors dynamically, verify that the change is announced.

Correct one field and submit again

Fix a single error while leaving another in place. Confirm the corrected error clears, the remaining error stays available, and the form does not discard valid information. Then submit successfully and check that confirmation is announced and that the next step is clear.

Include the complete journey in your scan

Use a demo or test environment so you can safely exercise invalid and successful states. Scan each meaningful state separately; the first page load does not include errors or confirmation that appear only after interaction. Keep test data synthetic and never export private customer information.