A contact form can look simple while still blocking someone who uses a keyboard, screen reader, speech input, magnification, high contrast, or extra processing time. A useful review follows the whole task: find the form, understand every question, correct an error, submit once, perceive the result, and recover when delivery fails. An automated scan can help locate candidates, but it cannot prove that this path works for a person.
Establish the test boundary
Record the exact page URL, build, browser, viewport, zoom level, input method, and assistive technology used. Use invented contact details and a test destination so the review does not create a real customer inquiry or expose personal information. List third-party components such as consent widgets, file uploaders, spam checks, and scheduling embeds because they remain part of the user journey even when a vendor supplies them.
Write expected results before testing. A reviewer should know which fields are required, what formats are accepted, how long the form remains active, what confirmation should appear, and which alternative contact route is available. If any point is undocumented, mark it as an open question rather than silently inventing a pass criterion.
Check labels, instructions, and grouping
W3C WAI's labeling guidance explains that controls need descriptive labels that are properly associated with them. Check that every text box, select menu, checkbox, radio group, and upload control has a visible purpose and an accessible name. Clicking or tapping a visible label should activate or focus the intended control. A screen reader should announce a useful name, role, current value, and required state.
Do not accept placeholder text as the only label because it disappears during entry. Place format help before it is needed, identify required fields in text rather than color alone, and group related choices under a meaningful legend. Speech-input users also benefit when the visible label matches the control's accessible name. Review link text in privacy notices and help messages so it explains the destination out of context.
Complete every action without a mouse
Starting at the page address, use Tab and Shift+Tab to follow focus, then activate controls with standard keyboard commands. Confirm that focus order matches the visual and logical order, the focus indicator remains visible, all actions are reachable, and no modal or custom widget traps focus. Repeat with browser zoom at 200 percent and a narrow viewport. Labels, errors, and the submit action should remain readable without two-dimensional scrolling for ordinary text entry.
Test autocomplete, pasted text, non-Latin characters, long values, and supported file selection in a safe environment. Check high-contrast or forced-colors behavior when available. A selected state, required state, or error must not be conveyed only by color, shape, or location.
Force errors and observe recovery
Submit an empty form, enter an invalid email format, exceed a documented limit, and simulate a server rejection. W3C WAI's validation guidance recommends clearly identifying errors and explaining how to correct them. It also notes that client-side validation alone is not a security control, so the server needs its own validation.
Verify that error text is associated with the affected field, announced when it appears, easy to find, and specific enough to act on. Valid entries should survive when another field fails. Move focus deliberately: either provide a concise error summary with links to fields or place focus where the user can understand what changed. Re-test with scripting disabled only where that is a supported scenario, and make sure server feedback is just as understandable.
Verify submission status and failure handling
After a valid submission, confirm that success is visible and announced without making the user hunt. The message should say what was received, what happens next, and how to proceed if the matter is urgent. Prevent accidental duplicates without leaving the submit button silently disabled. On a slow or failed connection, preserve the message where practical and provide a safe retry path.
Inspect the address bar, browser history, analytics events, logs available to the reviewer, and confirmation page for unexpected personal data. Check whether a timeout warns the user and offers an extension. If a CAPTCHA or anti-spam check is present, test its accessible alternative and document third-party limitations.
Keep a reusable evidence record
For each result, capture the steps, expected behavior, observed behavior, evidence, severity, owner, and retest status. Separate confirmed failures from combinations that were not tested. A form passes this review only when someone can understand its fields, complete it without a mouse, correct mistakes, submit once, perceive the outcome, and find another route when the form cannot deliver. That evidence is more useful than a single accessibility score because it identifies the exact task and configuration that were exercised.
Sources
- Labeling Controls — W3C Web Accessibility Initiative
- Validating Input — W3C Web Accessibility Initiative