Accessible Form Errors: Help People Finish Registration

What should accessible form error messages do?

Accessible form error messages identify the affected field, explain the problem in text, and give a known correction when appropriate. Connect each message to its control, make the failed submission apparent, and provide a usable route back to the answer. Then verify the complete correction journey. These are content and design principles, not a compliance certificate: involve disabled users and qualified accessibility specialists, and confirm the standards and legal duties applicable to your service.

A message is useful only if someone can find it, understand it, and act on it. This guide follows those three jobs through a fictional event-registration form. It is a desk-researched design example, not a tested interface or a report of participant results.

Which WCAG requirements are relevant?

The following distinctions come from WCAG 2.2. They describe different responsibilities, not interchangeable labels for a red warning box.

W3C's Understanding documents explain the criteria; they are informative guidance rather than additional normative requirements. A component example is also not a universal implementation mandate. Other criteria still apply to the form, including its structure and keyboard operation.

What can you explain before someone makes a mistake?

Start with the rule behind the field. Does it genuinely need an answer? What values does the service accept? Can the person reasonably know that before submitting?

For our fictional workshop, the organizer needs a contact email and a choice of morning or afternoon session. An optional access-request field is separate. The example does not require medical details, payment information or an account.

Write visible labels such as “Contact email” and “Session,” with session choices named plainly. If a field is optional, say so. Do not make someone discover a required format only after rejection.

Understanding Labels or Instructions distinguishes presenting instructions from correctly associating them with controls. Clear visible words alone do not establish the underlying programmatic relationship. Give the developer both the copy and its intended connection to the field.

For event-specific access questions and a private contact route, use the broader accessible event checklist. Error-message design should support that journey, not turn access requests into another hurdle.

How do you turn a failed submission into useful copy?

Here is an original content specification, not a functioning form. Assume the participant submits a blank contact email, makes no session selection, and leaves the optional access-request field blank.

There are two errors, not three. An empty optional field is not a missing required answer. The content editor should catch that distinction before reviewing colors or icons.

For a different attempt, imagine the contact-email field contains only “alex.” If the actual validator rejects that value because required address components are missing, a suitable message might be: “Enter a contact email with a name and domain, separated by @.” This explains that specific failure; it is not a complete specification for validating every possible email address.

Understanding Error Identification requires text that identifies what went wrong. Color and symbols can supplement that explanation, not replace it. The criterion itself does not prescribe one placement for every form.

Understanding Error Suggestion adds the known correction, with its security and purpose exception. Do not invent a correction the system cannot substantiate, such as telling someone an address belongs to another registrant. Have account-specific disclosures reviewed separately.

What belongs in an error summary?

For this example, the proposed summary heading is “Check these registration details.” Its two entries repeat the exact field messages:

• Enter your contact email
• Choose a morning or afternoon session

In an implemented form, each entry would link to the corresponding control or appropriate field-group destination. These bullets are a copy specification, not working page links.

The GOV.UK error-summary component uses a specific pattern: a summary even for one validation error, keyboard focus moved to that summary, links to affected answers, and matching summary and field wording. Its required heading is “There is a problem.” Our example borrows the summary-and-field relationship, not the component's prescribed wording or a claim of adopting its complete implementation.

If your team actually uses that component, follow its documented requirements. If it uses another design system, document that system's focus behavior instead. A screenshot of a summary cannot show where keyboard focus goes.

Keep the mapping concrete: the email entry must reach the email control, not merely the form's start. The session entry must land where its choices and question can be understood. An accessibility specialist should verify the implemented behavior.

How do field messages remain connected to their controls?

The developer needs more than a spreadsheet of sentences. Record the field identifier, visible label, hint, error identifier and intended relationship.

For example, the design record might pair the field identifier “contact-email” with the error identifier “contact-email-error.” These are fictional implementation identifiers, not CSS instructions or production code. The record lets a reviewer ask whether the rendered control is actually associated with the intended explanation.

WAI's form-notification tutorial shows associations using aria-describedby. It also discusses overall feedback and inline messages. The attribute is a mechanism, not a substitute for writing a useful error or testing its announcement in the chosen implementation.

Do not replace a visible field label with its error message. The participant still needs to know what the field asks after the error is resolved. Keep the ordinary instructions and error explanation distinguishable.

When should a message appear?

Separate a submitted answer from an answer still being composed. The WAI tutorial discusses feedback during typing and on focus change, and notes that some formats are poor candidates for continuous checking because incomplete input repeatedly looks erroneous.

For our example, start the design review with validation after submission. That is an editorial starting point, not a WCAG rule forbidding earlier feedback. If the team proposes earlier validation, ask which specific difficulty it solves and how the participant knows when correction is complete.

Also distinguish an input problem from a service problem. If the booking service fails, “Choose a session” would falsely imply that the participant's selection caused the failure. The GOV.UK error-message guidance distinguishes validation errors from capacity or service problems the user cannot fix.

Write service-failure content separately, with only verified next steps. Do not claim that a place was reserved or a request was saved unless the application has confirmed that state.

How do you review the whole recovery sequence?

Use the following original worksheet as an expected-behavior plan. Nothing in it represents an executed accessibility test.

The fictional validation count goes from two to one to zero. Zero input errors alone does not prove registration succeeded; acceptance by the service is a separate condition.

GOV.UK's error-message guidance says to keep both passing and failing answers when showing validation errors. Check that behavior rather than assuming a returned page preserves the participant's work.

When a result appears dynamically without a context change, consider Understanding Status Messages. Its scope includes qualifying success, waiting, progress and error messages. It does not mean every changed paragraph needs an alert, or that a focus-changing confirmation page must be treated as the same kind of update.

What evidence supports a responsible handoff?

Ask a qualified accessibility reviewer to examine the implemented labels, relationships, focus movement, message exposure and correction path. Include disabled participants in evaluation, using appropriate research arrangements rather than asking one person to approve the experience for everyone.

WAI's guidance on involving users in evaluation recommends combining user evaluation with standards evaluation and cautions against generalizing limited findings.

Record the actual browser, assistive technology where used, version, scenario, observed result and unresolved issue. “Email summary link reached the wrong control” is an actionable observation. “Accessibility passed” is not an adequate record of a narrow test.

Keep this form review with the site's inclusive web guidance and the event journey with accessible events. Clear words, correct relationships and verified behavior belong in the same delivery.

Sources

• W3C WCAG 2.2 — normative success criteria and levels.
• Error Identification, Labels or Instructions, and Error Suggestion — informative explanations and limits.
• Status Messages — definition, focus and context distinctions.
• WAI User Notification — message relationships and feedback timing.
• GOV.UK Error summary and Error message — design-system-specific patterns.
• WAI Involving Users in Evaluating Web Accessibility — evaluation scope and reporting limits.