Checking Contact Form Labels and Error Messages on Mobile and Desktop before Launch

This article outlines steps to verify that contact form labels and error messages are clear and accessible across devices, ensuring a smooth user experience before the site goes live.

Setting Up Your Form Review Environment

Imagine a hypothetical author preparing a pre-launch review of a contact form for a small consulting firm. The materials at hand are a single-page contact form with four fields, a desktop screenshot at 1440 pixels wide, a phone screenshot at 390 pixels wide, and a short list of draft error strings. Nothing here has been tested yet; these are self-made examples meant to clarify what a review should cover.

Two candidate form titles sit on the desk. One reads “Tell us about your project”; the other is the flatter “Contact us.” The first invites longer input and may make the message field feel obligatory, while the second sets a modest expectation but says little about what happens after submission. That choice remains open, and it changes how the labels below should read.

Three field labels are drafted: “Full name,” “Email address,” and “What can we help with?” A fourth, “Company (optional),” is marked optional in one draft and left unmarked in another. On the phone screenshot, the longer question label wraps to two lines, and the optional note sits far from its input, so a reader scrolling quickly may not connect the two. That unresolved spacing is the clearest item to settle before anything else.

The error strings are similarly provisional. One draft says “Enter a valid email”; another says “That email doesn’t look right — check for a typo.” The first is short and fits a narrow phone width; the second is friendlier but may crowd the field on desktop. A third draft for the empty message field simply says “Required.” None of these has been shown to anyone.

What this hypothetical setup illustrates is that the review environment is mostly a set of choices: title tone, label wording, optional markers, and error phrasing, each visible at two widths. The next step is to lay these drafts side by side at both sizes and decide which version to carry forward, rather than treating any draft as settled.

Verifying Label Visibility and Association

Every form control — text field, checkbox, radio button, and drop-down menu — needs a label that describes its purpose, and that label must be associated with the control either explicitly or implicitly. For explicit association, the label element's for attribute must exactly match the id of the form control. Implicit association uses the label element as a container for both the control and the label text; this suits situations where a control cannot be labeled explicitly, though explicit labels are generally better supported by assistive technology.¹

A browser treats the associated label as a larger clickable area for selecting or activating the control, and assistive technology can refer to the correct label when presenting a control. Placing labels above form fields generally helps reduce horizontal scrolling for people with low vision and mobile device users, but the source notes this depends on other design aspects, such as nearby fields and content, and needs individual assessment.¹

Begin with the two screenshots rather than the field list: lay the 1440-pixel desktop view beside the 390-pixel phone view and read each label against its input box. On the phone image, you might mark where a label sits closest to the edge and note whether it still reads as belonging to the box below it. A useful self-check is to cover the input borders with your hand; if the label could plausibly belong to the field above, consider rewording it or moving it nearer its own box in the next draft.

Then take the draft labels and rewrite one in two versions to see which association survives a narrow column. For example, “What can we help with?” becomes “How can we help?” to keep the label on fewer lines. Compare both on the phone screenshot and note which keeps the question mark from wrapping alone. You can decide which version to carry into the next draft; the choice is yours, and either is defensible.

For the error strings, place each draft directly under its field on both screenshots and read only the label and the message together. If “Enter a valid email” sits far below its box on the phone view, consider a shorter message such as “Check this email.” Record which pair still reads as one unit, then set that pairing aside as your working version for the remaining review.

Checking Error Message Clarity and Placement

Error messages should be easy to understand and give simple instructions on how to resolve the problem. In-line feedback belongs at or near the form controls, and a list of errors can be placed at the top of the page before the form, with each entry referencing the label of the corresponding control. Where errors appear dynamically without a new page load, the source states the list container should have the role attribute set to alert.²

When errors occur, that top list should have a distinctive heading, and each item should give a concise description, indicate how to correct the mistake, and include an in-page link to the control. Form fields can be associated with their error message using aria-describedby, as in a first name input pointing to its error text. If submitted data contains errors, the source notes it is convenient to set focus to the first input with an error.²

You can start with the four draft error strings and match each one to the field it belongs to on both screenshots. Take “Enter a valid email” and decide whether it reads clearly when it sits directly beneath the email input at 390 pixels wide; then read the same pairing at 1440 pixels. If the message wraps to a second line on the phone view, note whether it still appears attached to that field or begins to look like it belongs to the next one. You might mark each pairing as clear, ambiguous, or misplaced, and keep that note beside the screenshot rather than in a separate list.

Consider testing one softer wording against the same placement. If “That email doesn’t look right — check for a typo” feels more helpful in your draft, you can imagine it under the email field on both screenshots and compare it with the shorter version. Ask yourself which one still points to the right field without relying on color alone, and whether either becomes confusing when the form sits in a narrow column.

For a message that applies to the whole form, you can draft a single sentence and decide where it should appear — above the fields or near the submit control — on each screenshot. The choice is yours; the aim is to make the message locate the problem before anyone has to search for it.

Testing Input Validation Feedback

Validation feedback is not limited to the message text itself. The W3C guidance states that custom validation must notify users in an accessible way, and that required input should be clearly identified using labels. The required attribute can also be added to form controls to programmatically indicate that they are required, while the label displays “(required)” for users without assistive technology or on older browsers.³

The guidance also notes that validation should be forgiving of different input formats, citing telephone numbers written with different separators and postal codes that are not confined to numbers in some countries. Finally, client-side validation alone does not ensure security, so data needs to be validated on the server side as well.³

Take the draft error strings and pair each one with a specific field before deciding on wording. You might write a short note beside each field — for example, “Enter a valid email” next to Email address — and then read it on both screenshots to see whether the message still points clearly to its field in the narrow 390-pixel view.

Consider choosing between a direct phrasing and a softer one for the same field. “Enter a valid email” is compact; “That email doesn’t look right — check for a typo” is warmer but longer. Read both on the phone screenshot and decide which one still feels tied to the email field rather than floating as general text. You can keep the softer version if it holds together at that width, or stay with the direct one if brevity matters more to you.

For a message that concerns the whole form, draft one sentence and place it in two candidate positions — above the fields and near the submit control — then mark which position you would keep on each screenshot. Note your reasons in a line or two so the choice is recorded before launch. These are self-made comparisons, not tested results, and the final wording remains your call.

Reviewing Instructions for Data Formats

Instructions should state any required and optional input, data formats, and other relevant information. Where relevant, the source says to give overall instructions that apply to the whole form—such as required and optional input, allowed data formats, and timing limitations—and to place them before the form element so screen readers read them before switching to Forms Mode. The source's example notes how required fields are marked, the expected format for main data fields, and where to find help for each input.⁴

Relevant instructions can also go within labels, for example to indicate required fields and data formats; for simple cases, instructions within labels may be sufficient, as in an “Expiration date (MM/YYYY)” label. Instructions outside labels allow more flexible positioning but can be missed and are not supported by some older browsers and assistive technologies that don't implement WAI-ARIA. One approach uses the aria-labelledby attribute, though the source notes it was not fully supported by all browsers and assistive technologies at the time of writing, so the for and id attributes are also used for backward compatibility. Another uses aria-describedby, whose referenced information is made available after the label and other information is announced.⁴

Take the four field labels and do one deliberate rewrite pass on the narrow screenshot. You might shorten “What can we help with?” to “How can we help?” and then read the phone view to see whether the shorter label still sits close enough to its input that the pairing is obvious. If it does, note that choice beside the desktop version as well; if it drifts, you can keep the longer wording and accept a two-line label.

Then decide how optional fields announce themselves. Rather than marking every field, you can mark only “Company” as optional and leave the other three unmarked, then read both screenshots to check that the distinction is visible without extra explanation.

For the whole-form message, draft one sentence such as “Please check the highlighted fields” and compare it in two positions: above the first field and just above the submit control. Choose the position where a reader who has already scrolled to the button would still see it, and record your reason for the choice.

Finalizing Accessibility Checks Across Devices

You can close this pass by gathering your own four-field form, the two screenshots, and the draft error strings into one comparison you can annotate. Decide first which parts you will treat as fixed before you change anything: the field order, the optional marker, and the submit control wording. Write those three decisions at the top of your working note so later wording edits do not quietly reopen them.

Take the three labels you have already shortened for the narrow view and read each one against its answer on the phone screenshot. You might ask, for each pair, whether the label still names the kind of answer expected without relying on the desktop column for context. If one label now reads too vaguely, consider restoring a single descriptive word rather than a whole phrase. A useful author move is to keep both versions side by side and choose the one that survives the narrower width, not the one that sounds better on the larger screen.

Then settle the optional field. You can decide that only the company field carries an optional marker and that the other three remain unmarked. Check that choice on both screenshots by reading each label once without the marker, then again with it. If the unmarked fields could be read as optional, you might add one short sentence above the form instead of repeating the word on every label.

For the error strings, select a single field and commit to one phrasing. Suppose you keep the direct “Enter a valid email.” Read it under its field on both screenshots and ask whether it names the problem and the expected answer without requiring the label to be re-read. If you choose the softer version instead, decide once and apply it to that field everywhere in your drafts.

Finally, choose where the whole-form sentence sits. Read your chosen sentence above the fields on one screenshot and beside the submit control on the other, then pick the position you can defend without further changes. Record that choice as the end point of this pass, not as a new question to reopen.

Frequently asked questions

How should I begin comparing the two screenshots before looking at the field list?

Begin with the two screenshots rather than the field list: lay the 1440-pixel desktop view beside the 390-pixel phone view and read each label against its input box. On the phone image, you might mark where a label sits closest to the edge and note whether it still reads as belonging to the box below it.

What should I do with the draft error strings before deciding on their wording?

Take the draft error strings and pair each one with a specific field before deciding on wording.

How should I choose where to place the whole-form sentence?

Finally, choose where the whole-form sentence sits. Read your chosen sentence above the fields on one screenshot and beside the submit control on the other, then pick the position you can defend without further changes.