The task and original case
Build a three-field signup demo that helps someone recover from two errors without retyping valid information. Use fictional values in a local demo. The artifact should show the invalid state, the correction path and the successful state; a screenshot of the empty form is insufficient.
| Case element | Value or requirement |
|---|---|
| Inputs | A fictional 3-field signup form submits with one invalid email and an omitted required preference. |
| Build | An accessible form example and keyboard/error-state walkthrough. |
This is an original invented exercise. It is independent practice, with no employer assessment or open-vacancy claim. Download the inputs, attempt your own result, then open the separate answer key.
Data and worked inputs
Build a result another person can follow
Use a name field, an email field and a required preference selection. Give every control a visible associated label and state required information in text. Submit a valid name, an invalid email and no preference. Identify the email and preference problems separately and preserve the valid name value.
W3C's forms tutorial covers labels, instructions and error notification. Put each corrective message next to its field and associate it programmatically, for example through aria-describedby. Mark invalid controls appropriately. Provide an error summary with links to the affected controls when useful, and choose an understandable focus behavior. Avoid a color-only message or an alert saying merely “Something went wrong.”
Sources[1]
Check the worked result
The failed submission exposes exactly two known errors: an email-format issue and an omitted required preference. The name stays intact. Correcting the email should remove that error while the missing-preference message remains; correcting the preference should then allow the demo's success state.
Describe success as a local simulated submission. It does not establish that a message was delivered or an account created. Keep the demo disconnected from a real mailing list while reviewing recovery behavior.
Make the failure visible
Operate the form with a keyboard and inspect the controls' accessible names, descriptions and error state. A visible message can still fail if it is unassociated, offscreen or impossible to reach. Test a second failed submission too: messages should update without duplicating indefinitely or clearing the valid name. Automatic validation tools can help identify issues but cannot substitute for the recovery walkthrough.
Revise it and ask someone to reproduce it
Ask a peer to recover from the invalid state while you observe without prompting them. Record where the correction instruction was unclear. Revise that wording and repeat the same task with the same fictional inputs. Keep the before-and-after states and report only observed recovery behavior, not a general accessibility certification.
- Each invalid field has a specific associated corrective message.
- Valid values survive failed submission.
- Keyboard review covers failed, partially corrected and successful states.
Describe the work accurately
After completing your own version, you could adapt this project bullet: “Built a local form-recovery exercise with associated field errors, preserved valid entries and a keyboard-tested correction path.”
Use Projects or Independent practice as the heading. Keep the input files, result and revision together. Describe only your own completed work; the invented numbers are model outputs, not employer results or measured business impact.