Accessible error prevention and recovery help people avoid mistakes, understand what went wrong, and continue without unnecessary loss of work. They concern more than whether someone can operate a control: the interface must also make the consequences, current state, and available next steps understandable.
A form can be keyboard accessible yet erase someone’s answers after a failed submission. A delete button can have a clear accessible name yet remove important information without a way back. A payment request can time out while leaving someone unsure whether they were charged.
In each case, the interaction needs more than an error message. It needs a recovery path.
In this article
What prevention and recovery need to accomplish
Error prevention reduces avoidable mistakes before an action is completed. Error recovery gives people an understandable way forward when something goes wrong. Both depend on the interface accurately communicating what has happened.
A useful interaction helps someone answer four questions:
- Before acting: What information is needed, and what will this action do?
- When a problem occurs: What needs attention, and where is it?
- While correcting it: What work has been preserved, and what must I change?
- After acting: Did the action complete, and can it be corrected or reversed?
These questions matter for people using screen readers, magnification, keyboards, speech input, or other assistive technologies. They also matter when someone is interrupted, unfamiliar with a process, tired, or working over an unreliable connection.
Not every failure is a user error. A service outage, expired session, or lost response should not be described as though the person supplied something incorrectly.
Preventing avoidable errors
Prevention begins with clear instructions and reasonable input requirements. People should not have to discover an undisclosed rule through repeated rejection.
Explain requirements before they become errors
Place relevant instructions near the control they explain, and associate them programmatically where needed. A visible date-format hint is more useful than a general instruction at the top of a long page.
- Identify required fields in text, rather than through color alone.
- Explain meaningful format, length, and file-size restrictions before submission.
- Use persistent labels; placeholder text is not a substitute.
- Make button labels describe the action, especially when it has consequences.
“Review application” and “Submit application” describe different steps. Calling both “Continue” hides an important distinction. The foundations of this work are covered in accessible forms.
Accept reasonable variations
When the underlying task permits it, accept familiar variations in spaces, punctuation, and formatting. A phone number should not fail merely because someone included parentheses that the system can safely interpret.
Normalization needs boundaries, however. Silently changing a name, address, identifier, or financial amount can introduce a more consequential mistake. When interpretation could change meaning, show the proposed interpretation and allow correction.
Validate at a useful moment
Validation should help people complete an entry, not interrupt every keystroke. Showing “Invalid email address” while someone has typed only the first few characters is usually premature.
Checking a completed field may be helpful, while other checks belong at submission. The appropriate timing depends on the input and the cost of interruption. Client-side validation can improve feedback, but the server must still validate submitted data.
Making errors understandable and discoverable
An error message should identify the problem and, when known, explain how to correct it. “Invalid input” provides little help. “Enter an end date on or after the start date” identifies both the relationship and the correction.
Useful messages generally include:
- The affected item: which field, file, or action needs attention.
- The problem: what requirement was not met or what operation failed.
- The next step: how to correct the issue or proceed another way.
Do not rely on red borders, icons, or position alone. Provide text, and connect field-level error text to its control. An invalid state can also be exposed programmatically with aria-invalid="true", alongside an appropriate association with the error description.
Use summaries and field messages together
After an unsuccessful submission with several input errors, a summary near the beginning of the form can explain that submission did not complete and link to each affected field. Messages beside those fields provide local guidance.
For a custom form, moving focus to a well-structured error summary after submission is one useful pattern. The links must then take people to the relevant controls in a usable way. This requires deliberate focus management, not simply adding a prominent box.
Not every update should move focus. An asynchronous status change may instead need a suitable live region or status message. Coordinate announcements and focus changes so that the same content is not unnecessarily repeated or announced on every keystroke.
Distinguish correction from service recovery
“Choose a file smaller than 10 MB” asks the person to change an input. “The upload service is unavailable; your selected file has not been uploaded” describes a system failure. These situations need different recovery options.
Be specific where that helps, without exposing sensitive information. For example, authentication feedback may need to avoid revealing whether a particular account exists.
Preserving work during recovery
A person should not have to re-enter valid information merely because one field needs correction. Preserve unaffected answers, selections, and relevant context whenever it is safe to do so.
For longer tasks, this may include:
- Retaining completed fields after validation fails.
- Providing a deliberate save-draft option or clearly explained autosave.
- Showing which step is current and which steps are complete.
- Allowing people to review earlier steps without erasing later work.
- Explaining what remains available after a session expires.
Preservation also has privacy limits. Sensitive information should not be stored indefinitely or left exposed on a shared device merely to make recovery convenient. Explain what is saved, where relevant, and for how long.
Some inputs cannot be restored in the same way as ordinary text. A file input, for example, may require the person to select a local file again. If that happens, explain it rather than presenting an apparently unexplained empty control.
Clear state matters as much as retained data. “Draft saved” should mean the save was confirmed, not merely that a save request began. The distinction connects directly to interface feedback.
Reviewing and reversing consequential actions
The protection around an action should reflect its consequences. Correcting a display preference and authorizing a payment do not need the same interaction.
Make review specific
Before a consequential submission, show the information that determines the outcome: the amount, recipient, selected records, effective date, or other relevant details. Give people a clear route to correct those details without restarting.
A generic “Are you sure?” asks for confirmation without supplying much basis for a decision. “Delete these three saved reports?” makes the affected objects clearer. If deletion is permanent, state that plainly.
If review opens in a dialog, the dialog itself needs an accessible name, sensible focus behavior, and operable controls. See accessible dialogs for that interaction pattern.
Offer reversal when it is real
For some actions, undo is more useful than an extra confirmation. Moving an item to a recoverable trash area can allow ordinary work to continue while preserving a way back.
But an undo control must correspond to a supported reversal. Removing a message from the screen does not recall an email already delivered. Refunding a payment is not necessarily equivalent to cancelling it before processing.
Explain any limits. If recovery is available only briefly, do not make a short-lived notification the only discoverable route when a persistent recovery location is feasible.
Handling uncertain submission outcomes
One of the most difficult recovery situations occurs when a request may have completed but the interface did not receive confirmation.
Consider a payment form that times out after submission. “Payment failed—try again” may be inaccurate: the payment might have been accepted before the response was lost. An immediate retry could create a duplicate charge.
A safer recovery design separates three states:
- Confirmed success: the system has evidence that the action completed.
- Confirmed failure: the system knows the action did not complete.
- Unconfirmed outcome: the interface cannot yet establish what happened.
For an unconfirmed outcome, explain the uncertainty and provide a way to check status. Where supported, a reference number, transaction history, or status lookup can help someone establish what happened before trying again.
Duplicate prevention also belongs in the underlying system. Temporarily disabling a submit button can reduce repeated clicks, but it does not reliably prevent duplicate requests. Consequential operations may need server-side safeguards, such as idempotency keys, so that retrying the same operation does not repeat its effect.
As network success is not task success explains, technical delivery and the person’s intended outcome are different things. Recovery needs to account for both.
How WCAG addresses error prevention and recovery
WCAG includes several related requirements. In WCAG 2.2, these include:
- 3.3.1 Error Identification, Level A: automatically detected input errors must identify the affected item and describe the error in text.
- 3.3.2 Labels or Instructions, Level A: labels or instructions must be provided when content requires user input.
- 3.3.3 Error Suggestion, Level AA: when an input error is automatically detected and a correction is known, suggestions must be provided unless doing so would jeopardize security or the purpose of the content.
- 3.3.4 Error Prevention (Legal, Financial, Data), Level AA: specified consequential submissions must be reversible, checked with an opportunity for correction, or reviewable and correctable before final submission.
- 4.1.3 Status Messages, Level AA: qualifying status messages must be programmatically determinable so assistive technologies can present them without receiving focus.
The scope of 3.3.4 is specific: it covers legal commitments or financial transactions, modification or deletion of user-controllable data in storage, and submission of user test responses. It does not require a confirmation dialog for every button.
WCAG provides testable requirements, but meeting an individual criterion does not establish that an entire recovery experience is usable. A fuller introduction is available in understanding WCAG.
Testing the complete recovery path
Test what happens after something goes wrong, not just whether an error message appears.
- Submit incomplete or incorrect information. Can someone identify every problem and reach the affected controls?
- Correct one issue at a time. Do messages update accurately while other answers remain intact?
- Use a keyboard and assistive technology. Are focus, error associations, and status announcements understandable?
- Interrupt the task. What happens after navigation, session expiry, or a return to an unfinished draft?
- Simulate connection and service failures. Does the interface distinguish a known failure from an unknown outcome?
- Repeat a consequential submission. Can the system prevent unintended duplicate effects?
- Attempt reversal. Does the advertised recovery actually restore the relevant state, and are its limits clear?
Combine technical inspection with assistive technology testing and, where possible, observation of people completing realistic tasks. A programmatic association may be correct while the wording or sequence remains confusing.
The aim is not to prevent every possible mistake. It is to make ordinary mistakes less costly, consequential choices more understandable, and recovery possible without asking people to reconstruct work the system could have preserved.