Choose a task a new customer could actually have.
Start with one route, such as requesting a window-cleaning estimate. Write the task in the customer’s words: “I have not used this business before. I want to describe the work and ask how an estimate is arranged.” Follow the link a new visitor would use.
Review the form on a phone and a larger screen. Begin with its visible fields, instructions and controls. For interactive practice, use fictional details in a non-sending rehearsal that the form owner has confirmed cannot create customer records or trigger messages. Otherwise, inspect without entering information and mark the untested behavior as not checked.
This is an observation exercise, not a live submission test. Do not press a send or booking control unless the form owner has arranged that exact test.
Check whether the questions make sense before entering answers.
Fictional example: A window-cleaning company’s estimate form requires an existing job number. A new customer has none. Another field shows its name only as faint text inside the empty box; once someone types, that hint disappears.
On a small screen, swipe or scroll sideways to read the full table.
| What the visitor encounters | What the owner should check |
|---|---|
| Required existing job number | Can a first-time customer complete this step honestly? If the number is only needed for existing work, review the question or route. |
| A field name disappears while typing | Can the visitor still identify what the answer belongs to and find any needed instructions? |
Do not invent a job number to get through. The minimum-useful-intake guide helps decide which information belongs here. W3C’s labeling guidance explains how controls should be identified; checking that a label is correctly connected also needs technical review.
Follow the controls without relying on a mouse.
In the non-sending rehearsal, move through the form with the keyboard. Check whether you can see the current position, reach each needed control, operate it and move away again. Record the specific control where the task stops rather than writing “keyboard broken.” Browser and operating-system keyboard settings can affect this check; note your setup.
In the fictional form, a service chooser opens with a mouse, but the keyboard reviewer cannot open it or move on once focused there. That is a usable finding for the person fixing the form. It does not tell you how every visitor experienced it.
On a phone, also check whether instructions remain readable and whether the on-screen keyboard or a floating banner obscures the field being used. Use an actual phone where possible; a narrow desktop window does not reproduce every mobile interaction.
Make an error understandable and recoverable.
Inspect an error state supplied in the non-sending preview, or ask the form owner to demonstrate one under an arranged test. Do not submit deliberately incorrect details to a live form just to produce an error.
The fictional preview marks an email field red and says only “Invalid.” A visitor needs to know which answer needs attention and how to fix it. W3C’s form-notification guidance connects useful error feedback with the affected field and an understandable correction.
On a small screen, swipe or scroll sideways to read the full table.
| Observed feedback | Proposed correction to review |
|---|---|
| Red border; “Invalid” | Email address: include the @ symbol and domain, such as [email protected]. |
That correction fits a missing email-format element; another error needs its own explanation. Check whether the person can return to the field without losing the useful work already entered. A designer should also verify how the error is conveyed to assistive technology.
Separate completion feedback from actual delivery.
Read the completion message in an available preview. Could a customer tell whether the request succeeded, failed or still needs something? If the message is unavailable, record that gap rather than submitting a real inquiry to uncover it.
A preview saying “received” does not prove that a real request reaches the team. Use the prelaunch path check for a separately arranged behavior test. If the message implies a booking while the form only requests an estimate, use the customer-promise check to resolve that wording mismatch.
Give the person fixing it an observation they can use.
Download the blank contact-form observation sheet (CSV). Use one row per attempted step. Record the device, input method, expected result, actual result and exact field or message. Keep customer information out of the sheet.
“A first-time estimate requester cannot provide the required job number” gives the team a decision to resolve. “The website needs to convert better” does not identify the obstacle. Assign the next check, then repeat the affected task after a correction and record what changed.
These selected checks are a starting point. W3C’s preliminary-check guidance warns that passing simple checks can leave substantial accessibility barriers undiscovered. This sheet is not accessibility certification or a prediction of more inquiries. Where specialist review is needed, pass along the concrete findings and keep the untested parts visible.