0
Build Accessible Forms with Clear Validation and Recovery
An original worked form guide: design understandable fields, associate useful errors with inputs, and rehearse keyboard and failure-state behavior.
0 comments3 views3 steps
Comments
An original worked form guide: design understandable fields, associate useful errors with inputs, and rehearse keyboard and failure-state behavior.
Help me design a fictional project-creation form with a required project name and an optional description. The name must be 1 to 80 characters after trimming, and the description may contain up to 500 characters. Start with the structure and interaction requirements rather than a visual theme.
Describe the initial, submitting, success, and failure states. Explain how labels, help text, and error messages should work for someone using a keyboard or assistive technology. Avoid treating placeholder text as the only explanation of a field.
Use a semantic form with a visible label associated with each control, a text input for the project name, a textarea for the description, and a submit button. Put the required marker and length guidance where they remain available while typing. A placeholder may offer an example, but it disappears when the user enters text and should not be the sole label.
Initially, show the fields without accusing the user of errors before they have acted. During submission, keep the current values and present a visible saving status. On success, confirm the created project's name and offer an obvious way to open it. On failure, preserve the inputs, explain whether they need correction or whether saving failed, and provide a clear retry path.
Define the validation timing as part of the interaction: this exercise validates on submit, then rechecks an affected field as the user corrects it. That avoids repeatedly interrupting someone who is still composing an answer. The implementation should expose the status and error relationships programmatically as well as visually; a red outline alone cannot communicate which rule was violated.
Now specify the error behavior for a whitespace-only project name, a description that exceeds the limit, and a server failure after valid input. Give useful message text for each situation and explain where keyboard focus should go after an invalid submission.
Show a compact HTML relationship between the name field, its help text, and its error message. Include the relevant attributes, but explain when they should be present rather than adding accessibility attributes indiscriminately.
For a whitespace-only name, show 'Enter a project name.' For an oversized description, show 'Shorten the description to 500 characters or fewer.' After an invalid submit, a practical pattern is to focus an error summary containing links to the affected controls. Preserve every value so a person can correct the issue without re-entering unrelated information. A valid submission that fails at the server instead needs a form-level message such as 'The project could not be saved. Your entries are still here.'
An invalid field relationship can be represented as <label for="project-name">Project name (required)</label><input id="project-name" name="name" required aria-invalid="true" aria-describedby="name-help name-error"><p id="name-help">Use 1 to 80 characters after trimming.</p><p id="name-error">Enter a project name.</p>. When the error is resolved, remove or set aria-invalid to false and update the description references so they match the content actually present.
Keep client and server validation aligned, because a browser check does not replace validation at the write boundary. Avoid competing browser and custom error flows that send focus to different places. W3C's form-validation guidance discusses identifying errors and communicating them accessibly; the messages and focus sequence above are a concrete proposed pattern to verify with the chosen interface.
Create a manual verification plan for this form. Include keyboard-only use, invalid submission, correction, slow requests, a failed request, and a successful save. Explain what an automated accessibility check can help with and what still needs direct interaction testing.
Also cover an uncertain result where the server may have saved the project but the browser lost the response. Explain how the product should avoid encouraging duplicate projects when the user presses Retry, and finish with a concise definition of done.
Starting at the page heading, use only the keyboard to reach both fields and submit. Check that focus stays visible, labels are understandable, and the error summary links reach the right inputs. Submit an empty name, correct it, and exceed the description limit. Confirm that errors update without erasing text or unexpectedly moving focus while the user types. Inspect the announced field name, description, and error using a screen reader in the supported browser setup.
Simulate a slow request and a definite server rejection, then a successful creation. Verify that the saving state is perceptible, repeated submissions are controlled, failure preserves user work, and success corresponds to a persisted project. For a lost response after possible creation, reuse a stable submission identifier with server-side duplicate prevention or reconcile the result before retrying. Disabling the button alone cannot resolve an ambiguous network outcome.
An automated accessibility scan can detect some structural issues, but it cannot establish that the messages make sense or that focus behaves well through every state. Done means the main keyboard journey, error recovery, screen-reader relationships, and persistence behavior have been checked in the intended environment. This guide provides the proposed verification steps; it does not claim that a real interface has already passed them.
Comments 0
Share how you would use this prompt or suggest a useful improvement.