Form error states: which field to fix

The visitor fills most of a long form, presses Send at the bottom, and the page stops. Nothing moves to the mistake. A summary line may appear at the top, saying there were problems, with no link to the fields. The visitor is still at the button, so the wrong box may be a screen above, under a sticky header, or not marked at all. They press Send again, see the same silence, and start scrolling. The owner knows which box is wrong, so the form never looks broken from the owner's side.

• Submit with only the last field wrong. Does the page bring that field into view, or stay on the button?
• After Send, run document.activeElement in the Console. If it still reads as the button, the error did not move focus.
• Scroll the first error into view and check whether a sticky header covers its message.
• Type a correct value into a flagged field and see whether its message clears at once or waits for Send.
• Press Tab from the top of the form and check that focus moves through the fields in visual order, with none skipped.

The form has a summary at the top, such as 'Please fix the errors below'. The visitor reads that summary only if they are already near the top, and a visitor who has scrolled down to Send usually is not. Each flagged field has a red border, but the border is small, and the message text sits where the visitor is not looking. The visitor does what a person does next: scrolls up, scans for red, and guesses. The first red box they meet is not always the first mistake in the form, so they fix the wrong field, press Send again, and the form reports the same problem.

Focus is the place a keyboard or a screen reader is working. After a failed Send, a form that leaves focus on the button makes a keyboard user start the whole cycle again, and a mouse user is left at the bottom of the page. Moving focus to the first invalid field takes the visitor to the mistake and places the cursor in it. Scrolling alone does not do this. A script can scroll a field into view and still leave focus on the button, so the visitor sees the box but typing goes to the button. A sticky header can then hide the message that the scroll was meant to show.

An error should clear when its field passes, and stay until then. Two common mistakes break this. Some forms clear the message the moment the visitor clicks into the field, so it vanishes while they are still deciding what to type, and the red border stays until the next Send. Others keep the message after the field is fixed, so the visitor cannot tell whether the change was accepted. Clear the message on the field's own change event, and recheck the whole form on each Send.

A new field, a new step, or a header that grows on phones can put the first error back out of view. Rerun the same visitor after each change, with two or three fields wrong on purpose, and check which field gets focus and whether its message is visible. With paid credits, visitors can reach a form behind a site password, so the same check runs on each preview deploy before release.