A failed submit must move focus to the first invalid field

What it is

After a click on submit, keyboard focus usually still sits on the button. If validation fails and only paints a distant red box, the point of action and the point of error split. Moving focus to the first invalid field means: on the same beat the submit is rejected, programmatic focus lands on the first still-invalid input in reading order, so keyboard, switch, and screen-reader “current position” coincide with the item to fix. First means the first error in document order, not a random item and not the last. This entry is about where focus lands. It is not the geometry of scrolling a field into the viewport, and not whether a red box can be told apart by color alone. A summary at the top does not replace the focus move.

Why it happens

Submit is an attention reset. The goal flips from filling to sending; gaze and focus are on the button. If errors only change appearance, attention does not jump back to the field—especially when the button is at the bottom of a screen and the error is off-screen or far above. Moving focus is a system-made orientation: current position = object to handle. A second layer is the assistive-technology caret. A screen reader does not read “what turned red”; it reads the focused node and its name. Focus left on the button, the announcement is still “Submit,” and the error did not happen. Switch and full-keyboard users have no pointer to click the red box; if focus does not move, the task stops on the button. Picking the wrong “first”—a hidden honeypot, or a later item scrambled by tabindex—sends people to a control they cannot edit or that is irrelevant, which is worse than not moving.

Studying it

Submit a form with several errors. Compare focus remaining on the button, focus to the visually first error, and focus to the first error in the DOM. Include a keyboard-only group and a screen-reader group.

Independent variables: focus target after failure (button / visual first error / DOM first error), whether the first error is inside a collapsed or hidden field. Dependent variables: time from submit to editing the error item, whether keyboard users can fix the first item without looking, whether the screen reader announces that field’s name and error, times focus lands on a non-editable control.

Mouse users in the lab click the red box themselves and hide focus failure. Keyboard and assistive-technology conditions are required. Do not treat “the page scrolled” as focus success—scroll without focus leaves the reader on the button.

Where it stops holding

A form in a modal that moves focus to a field outside the overlay locks the user under the modal. Single-page apps that redraw the whole page after submit must move focus after the redraw, or it lands on a destroyed node. Captchas and file pickers that cannot hold focus reliably should focus a focusable proxy (the trigger button or the explaining text). A successful submit should not steal focus onto a field. When live blur validation already left the person on the next item, do not yank back to the first error on every blur; that becomes a focus fight.

Applying it

• In the callback where client or server rejects submit, set focus to the first invalid editable control in reading order—not leave it on submit, and not jump to the top of the page.
• Decide “first error” with the same reading order used by Tab and visual order; skip display:none, honeypots, and aria-hidden nodes.
• When moving focus, expose that field’s accessible name and current error so a screen reader lands on “field name, error reason.”
• Verify with keyboard only: leave two errors, submit, and confirm focus lands on the first, not the button or the second. Repeat with a screen reader and confirm the landing announcement includes name and error. Put the first error in a collapsed section: focus must expand then land, or land on the first visible error—not on an invisible node.

Related

• Within the group: H1.05.2 The invalid field must be visible in the viewport · H1.05.3 Error identification cannot rely on color alone
• Adjacent: J3.02 Focus order and focus traps · D1.04 Focus rings · H3.11 Accessible error announcement
• Search terms: focus management · first invalid field · submit validation