Accessible Forms: Error Recovery Tested on Our Contact Form

Test the correction, not just the empty form

A contact form can have visible labels and still leave someone unsure how to fix a mistake. Useful form testing follows the task: enter information, trigger a supported error, find the affected field, correct it and check what happens to the other answers.

We used our own What Is ADA contact form to make this concrete. On October 19, 2026, we checked empty fields, a malformed email address, a short message and the message-length boundary. We found an instruction worth improving and retained the browser observations before and after the change.

These are observations from Grow Wild’s maintenance of this website. We did not measure conversion lift, abandonment, legal risk or participant usability. The value demonstrated here is a clearer instruction and a reproducible test record.

What an accessible form review should cover

Start with the task and its real requirements. Identify required fields, accepted formats, conditional questions and the submission destination before choosing test inputs.

• Labels: each field needs an understandable name and the appropriate programmatic association. A placeholder can supplement a persistent label; it should not be the only instruction.
• Requirements: make required fields and meaningful input constraints understandable before someone encounters an error.
• Error information: identify the affected field and describe the problem in text. Give a useful correction when one is known.
• Navigation: inspect the actual focus destination, visible focus and route back to the field. Do not assume an error is discoverable because it exists in the page source.
• Preserved answers: check that correcting one field does not erase valid work elsewhere.
• Completion and failure: include success, server failure, anti-spam and any external controls in the eventual full review. Those need an authorized test destination.

WCAG 3.3.1 Error Identification addresses text identification of automatically detected input errors. 3.3.3 Error Suggestion addresses known correction suggestions, subject to its exceptions. These are related checks, not interchangeable labels for every form defect.

Completed example: our contact form

Our form has Name, Email, Subject and Message fields. All four are required. The message rule checks the length after removing spaces from the beginning and end.

The original production revision was 4945188. The instruction repair was tested locally at revision 4210f40, using the same form and validation logic. Both sessions used the Codex in-app browser on macOS with a 1280 × 720 viewport; the browser engine version was not exposed. We used browser UI controls and keystrokes, then inspected the rendered page, focus and field associations. This was not a complete keyboard-only journey or a screen-reader session.

1. Empty submission exposed four field errors

We activated Send Message with all four fields empty. The page showed four text errors, and focus moved to Name. Each affected input had aria-invalid="true" and an aria-describedby reference to its error text.

That verifies the observed field associations and focus movement. It does not establish which errors a screen reader would announce, in which order or at what time.

2. A partial correction moved focus to the next error

We entered the synthetic name “Grow Wild QA,” selected “Accessibility Issue,” entered a malformed email address and used “Short” as the message. Retrying produced the email and message errors, with focus on Email.

After correcting the synthetic email and retrying while the message remained short, only the message error remained and focus moved to Message. The name, selected subject and short message remained visible through those attempts. The browser’s inspection output redacted the email value, so the record does not claim a readback of that value.

3. The minimum length appeared too late

Initially, Message had no associated help explaining its minimum length. A user learned the ten-character requirement from the error after submitting.

We added this visible instruction before the textarea:

Use at least 10 characters, excluding spaces at the beginning and end. Include the page address and what you need help with.

The field now references message-help before an error and message-help message-error when the error is present. The instruction stays associated while the error appears or clears. We changed the guidance and its association; the validation rule and submission destination stayed the same.

4. Boundary tests checked the instruction against the rule

In the local retest, a message containing nine digits with two spaces on each side still produced the message error. Ten digits with the same outer spaces did not. We deliberately left Name empty during both boundary checks, preventing a valid submission.

Those cases verify the tested ASCII examples and the treatment of outer spaces. They do not evaluate every language, character sequence or input method.

5. A disappearing error was not a validation result

The form clears a field’s prior error when it is edited. We observed the email and message errors disappear while the replacement values were still invalid. Retrying brought those errors back.

This distinction matters when recording a result: “error cleared during editing” is an observation; “the new value passed validation” requires a validation attempt. We stopped after the intended checks and did not send a valid enquiry.

Download the actual observations

• Before-and-after browser record, inputs, focus and field associations (JSON)
• Concise completed test matrix (CSV)
• Blank form error-recovery test matrix (CSV)

The completed record separates the original production session from the local repair retest. It identifies the revisions, times, methods and untested scope. Use the error-recovery workflow to record a different form rather than treating our result as its result.

What still needs a separate test

This session did not test successful submission, delivery to an inbox, server rejection, spam handling, disabled participants or a screen reader. The form’s client-side checks returned before its send request on the invalid attempts, as confirmed by source review and the observed validation states; this was not a network-capture study.

For screen-reader evidence, record the actual announced name, requirement, instruction and error. Test what happens after correction and after completion. The presence of role="alert" or aria-describedby is implementation evidence, not a speech transcript.

Our separate NVDA heading-validator session demonstrates why that distinction matters: the captured automatic announcement named the results heading; reading commands were needed to expose the counts in that session. That test covered a different tool. It does not verify NVDA behavior on this contact form.

A fuller review should also cover zoom/reflow, text and control contrast, keyboard-only operation from page entry through completion, supported mobile input methods and relevant browser/assistive-technology combinations. Define that coverage with the audit-scope guide.

Use tools for the evidence they can provide

Our compliance checker runs selected automated rules on fetched HTML and can identify issues such as missing form labels. It does not execute the page’s scripts or test validation and correction journeys. The color contrast checker evaluates supplied color pairs; it does not establish every state of a form. Automated inspection, browser operation and assistive-technology testing answer different questions.

The W3C forms validation tutorial explains native and custom validation approaches and why client-side validation is not a substitute for server-side validation. This review did not assess our submission service’s security controls.

For your next review, choose one important form, record a bounded task, retain the actual errors and correction path, and turn any repair into a retest with the same inputs. Measure completion and enquiry quality separately if you want to assess a business outcome. An accessibility improvement should not be turned into a conversion claim without that evidence.

Correction, October 19, 2026: an earlier version of this article incorrectly described the checker as a manual review aid. It already performed selected automated HTML checks. Our verified scan example and self-check guide explains that scope. This correction does not change the form-testing observations above.