Make quote-form errors easy to find and correct

Observe what happens after rejection

Submit marked sample answers with one deliberate error. Does the page explain what failed, or simply stay unchanged? Where is keyboard focus after the attempt? Can you reach the relevant field without guessing? Record the error's position, wording and association with the input. Recovery is part of the form, not an exception to its customer journey.

Separate error explanation from focus movement

W3C's notification tutorial recommends understandable errors that reference the affected control and support correction. Focus order should also preserve a meaningful operating sequence. Ask the maintainer to check both relationships. Moving focus does not replace clear text, and clear text does not help if the customer cannot discover or reach it.

Source checks: W3C WAI: User Notification · W3C: Understanding Focus Order

Test one missing and one malformed answer

Use a small controlled test rather than entering several simultaneous mistakes first. Choose a missing required answer and a realistic malformed value, such as an incomplete email. Observe the result with and without a mouse. Keep the other answers in place so the test checks correction rather than forcing a complete restart.

• Submit a marked request with one required field left empty and record the message.
• Identify the focused element and use the keyboard to reach the affected input.
• Confirm the error names the field and tells the customer how to correct it.
• Repeat with a malformed value and check that the instruction fits that different problem.
• Correct the value, resubmit once and verify the saved request and receipt.

Avoid sending users back through unrelated content

Do not rely on color alone to indicate rejection. Avoid a generic 'invalid form' message when a specific field is known. Resetting every answer after a minor mistake forces unnecessary work. A focus jump to unrelated navigation can make the form appear broken. Custom dialogs need their own keyboard behavior, not just an attractive design.

Record the recovery task

Record whether a test user can identify the problem, reach the field and complete the request. Keep field-specific errors separate from delivery failures. A network outage needs a different message from an incomplete email. Passing these recovery cases establishes their usability in the tested environment, not complete accessibility conformance.

Retest errors after changing validation

Keep the error cases with the validation rules in the maintenance note. If a field's requirement changes, update its error message and association at the same time. The person handling enquiries should approve instructions that ask customers for new information. Retest the recovery path after a form component or layout change.

Worked example: an illustrative customer journey

For example, a heating-service form rejects a missing email but places a small error above the mobile screen. The maintainer provides a clear error summary linked to the email field and keeps the other answers intact. The test identifies and reaches the correction without a mouse.

TEST-ERROR-3201 then submits after the field is completed and appears in storage. A separately simulated delivery failure receives different wording. The result verifies distinct recovery paths; it does not show how often real customers previously encountered them.

Questions about this task