After submission, a red sentence appears at the top while the affected field remains off screen. Colour alone explains neither the cause nor the next action. Identify the input needing correction and describe a usable correction.
An established email-format error might use:
<label for="email">Email address</label>
<input id="email" name="email" type="email"
aria-invalid="true" aria-describedby="email-error">
<p id="email-error">Check the address, for example name@example.invalid.</p>
This illustrates an error state. Do not permanently mark an untouched field invalid in advance. Distinguish missing required information from unsuitable formatting.
Coordinate the error summary and focus
For several errors, a summary linking to affected fields can help. Check that people can find it after submission and that links reach the intended inputs. Define predictable focus behaviour rather than moving focus elsewhere on every keystroke.
Preserve valid entries where appropriate. Having to re-enter everything after a server failure is a different problem from an invalid format. An unavailable API should not be described as the user’s input mistake.
Test empty fields, invalid formatting and simulated server failure in isolation. Show confirmation only after the intended server-side acceptance has genuinely occurred. Preserve valid entries when an error occurs.