Make form errors understandable and reachable
Connect error descriptions, fields, summary links, focus behavior, and preserved answers in a workshop form, then test the correction route with keyboard and assistive technology.
Connect discovery, explanation, and correction
An accessible error message needs more than a warning icon and a red border. Someone must discover that a problem exists, identify the affected question, understand the issue, and reach the place to correct it. Design those connections for the entire workshop-registration task, including what happens after another attempt.
Associate summaries and field messages
Describe the error in text and associate it with the relevant input. Keep the label and hint available. A summary can provide an overview and direct links to affected fields, while local messages explain each correction. Choose focus and announcement behavior deliberately so the same message is not missed or repeated unnecessarily. Separate what the system knows from what the person has actually been told. A technically valid operation can still look unsuccessful when its confirmation is delayed or ambiguous. Describe the state before the action, while work is pending, and after it completes. Then name the information that remains available if the person leaves and returns. These notes become concrete requirements for the eventual implementation.
Correct a registration form by keyboard
Create a registration form with a missing email and an unselected session. Write a specific message for each, then connect them to a summary. Submit the form by keyboard and follow a summary link. Correct one answer and submit again, checking that the remaining message and preserved values still make sense. Work through the example once without a pointer, once on a narrow screen, and once after an interruption. These passes examine different assumptions; none replaces research with people who use the finished service. Preserve the same task and content across passes so that changes reveal weaknesses in the design rather than unrelated differences in the scenario. Capture each weakness as a specific revision, not a general impression.
Remove stale and unreachable error states
If the summary announces only a generic failure, the person still needs a route to the details. If a linked label lands on a wrapper instead of the input, correction may become awkward. If corrected errors remain visually or programmatically attached, the page can communicate an outdated problem. Test state changes rather than only the first failure. Distinguish a missing cue from a missing capability. Copy can explain an available recovery path, but it cannot create a recovery path the system lacks. Annotate where the interface needs a different state, a preserved value, or an operational response. Give each case a visible outcome. Otherwise an apparently helpful message may simply send someone around the same unsuccessful loop with more words to read.
Review announcements through another attempt
Review the sequence with keyboard input and representative assistive technology, including a second failed attempt and successful completion. Record what was announced, where focus moved, and which answers survived. Keep technical behavior aligned with the written correction guidance. This makes the error design a usable recovery path rather than an attractive collection of warning states that has never been operated.
Worked decision
After correcting the email, the remaining session error should stay accurate, reachable, and associated with its question while the valid address remains entered.
References & further reading
Examples and exercises in this guide are original teaching scenarios.
