Make errors recoverable

Start from the behavior you can observe. The summary links to invalid fields, each field has a specific message, and server validation preserves valid values.

An error is useful only if the user can find it, understand it, and correct it without restarting. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to change the border color and return a generic “invalid form” message. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to provide text, programmatic association, an error summary for multiple failures, and a clear correction path. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Repair the registration content so input and information remain clear across perception and reading conditions. Record enough evidence that another developer can repeat the result without relying on your memory.

Submit five distinct errors and repair them with keyboard and screen reader without losing entered data. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.