Accessible Form Validation: Help Web App Users Fix Rejected Entries

Accessible form validation should tell users which entry needs attention, explain how to correct it, and keep their other answers intact. Use browser checks for immediate feedback, repeat validation on the server, and make error recovery usable with a keyboard and assistive technology.

This article focuses on correcting rejected entries in business applications, such as supplier onboarding, project intake and product administration. It complements the broader checklist for contact forms that lose enquiries, with a narrower question: what should happen when someone submits a form the application cannot accept?

1. Agree on what each field can accept

Before choosing an error colour or notification component, write down the actual input rules. For every field, identify whether it is required, which formats the system accepts, and which restrictions come from a genuine operational need. Give each rejection a correction the user can reasonably make.

For example, a project reference might need a fixed structure because another system consumes it. A person's name usually needs a different approach. Avoid transferring a rigid identifier rule to ordinary language fields simply because both contain text.

W3C's input validation guidance recommends accommodating different input formats and explains that browser validation must be accompanied by server validation. Review whether harmless formatting differences can be accepted before asking someone to retype an answer.

Create a field rule sheet for the product owner and developer to approve together. Include an accepted example, a rejected example, the reason for rejection and the proposed message. Treat these as proposed acceptance criteria, rather than evidence that the current application already behaves correctly.

Separate format checks from business checks. A reference can have the right shape while pointing to a retired project. That distinction affects both the message and where the application can verify it.

2. Choose when validation should interrupt

A newly opened form should give instructions without immediately treating every empty field as a mistake. Someone who has just started typing has not necessarily supplied their final answer.

MDN's guidance on the aria-invalid attribute advises against marking empty required fields invalid before a submission attempt. The attribute communicates an invalid state to assistive technology; it does not perform validation itself.

Use the following table as a proposed review policy. Adapt it to the task, especially where a check needs a server response.

For routine fields, start with submission checks and add earlier feedback where it helps people avoid wasted work. Test any validation during typing carefully. A warning that changes with every character can distract from completing the answer.

If a server lookup runs while the user edits, specify which answer its result belongs to. An old response must not mark the replacement value invalid. Ask the implementation team to demonstrate this with deliberately delayed responses.

3. Make browser and server validation agree

Browsers can handle common constraints, including required values and some input formats. MDN's Constraint Validation API documentation explains the built-in mechanisms and why they cannot replace server validation: requests can bypass the form or alter its browser-side restrictions.

Use native controls where they fit the task. Custom validation is justified when the business rule needs it, but replacing browser feedback creates additional work for the team. Someone must maintain the messages, focus behaviour and accessible relationships between controls and explanations.

Ask developers to compare the browser and server rules explicitly. A form that accepts an answer locally and then rejects the same format remotely gives users contradictory instructions. Keep shared business rules documented even when the two implementations use different technologies.

The server response should let the interface associate each rejection with the correct field. For repeating sections, such as several project contacts, review how the application identifies the affected row after users add, remove or reorder entries.

A failed lookup also needs its own outcome. If the application cannot verify a project reference because the service is unavailable, asking the user to correct the reference misdiagnoses the problem. Preserve the entry and explain the available next action. Whether submission can continue depends on the workflow's requirements.

4. Give users a clear route through the errors

A useful field error names the problem and offers a correction. Proposed copy such as "Enter the project reference shown in your invitation" is more actionable than "Invalid input" when that is the information the user needs.

For longer forms, consider an error summary with links to affected fields, alongside explanations near those fields. W3C's form notification tutorial describes overall feedback, linked error lists and associations between controls and their error messages. Keep each message concise enough to scan.

Define keyboard focus as part of the design. In a custom interface, a reasonable proposal is to focus the summary after a rejected submission and let users follow its links. Confirm that each link reaches the relevant control and that the current error is available there. Avoid simultaneously moving focus and triggering several competing announcements.

Colour can support the message, but users should have a written explanation too. The application must also remove obsolete error states after a valid correction. Recheck the field's accessible state as well as its border.

Preserve ordinary entries after rejection, including answers in collapsed sections. Review sensitive fields separately rather than assuming every value should be retained or stored. File selections may require another choice depending on the implementation, so explain that requirement beside the attachment control.

Keep validation recovery separate from recovering unsaved work after a session timeout. Users need different instructions when an answer is unacceptable and when their login has expired.

5. Test the correction journey, including common mistakes

A successful submission test does not show whether users can recover from rejection. Build a small set of realistic failure scenarios around the application's most important form.

Start with several errors in different sections. Submit using only the keyboard, follow the summary, correct one answer and submit again. Check that the remaining errors still make sense and the corrected answer stays in place. Repeat with a screen reader and the browsers your audience uses.

Then test a slow server check followed by an edited value. Include unavailable verification, a server-only business rejection and a message long enough to wrap on a narrow screen. These are proposed tests, not claims about measured application performance.

Common mistakes deserve explicit review. Teams sometimes disable submission without explaining which requirement remains unmet. Others show a brief notification that disappears before the user can act, or clear the entire form after one rejected field. Another failure is leaving a hidden error in an unopened section while showing only a generic message above the submit button.

Check wording with the people responsible for the workflow. If users cannot resolve a rejection themselves, the message should describe the available route, such as choosing another active project or contacting the designated administrator. Avoid exposing internal exception details as instructions.

6. Use a release checklist and start with one form

Use this checklist before accepting the validation behaviour:

• Document required fields, accepted formats and server-only checks.
• Show format instructions before users need to guess.
• Avoid premature errors on untouched required fields.
• Match browser rules to server acceptance rules.
• Associate each rejection with the correct control or repeated row.
• Provide written correction guidance and a keyboard route to errors.
• Preserve appropriate entries after rejection.
• Handle delayed checks without applying obsolete results.
• Distinguish invalid input from unavailable verification.
• Confirm success only after the application accepts the submission.

These checks help define a reviewable implementation. They do not establish that every browser, assistive technology combination or business workflow has been covered. Record the environments tested and any known limitations.

The next step is to select one frequently used business form and write its failure scenarios before changing its visual design. Have the product owner approve the rejection messages, then ask the development team to demonstrate correction and resubmission. Expand the pattern to other forms after that journey works consistently.