5 minute read · Practical marketing guidance
On this page 5 sections
A customer fills in an inquiry form, presses the button and sees “Check your details.” The request has not been accepted, but the message leaves the customer to guess which detail needs attention.
For a Las Vegas or Henderson service business, review that moment separately from everything that happens after acceptance. The immediate question is whether the customer can understand the problem and continue. A rewritten sentence is a proposal until the website team implements it and observes the resulting behavior.
Find the rejected field before rewriting the message
Ask the website manager which condition produced the error. An empty required field and a value rejected by a format rule need different explanations. A failure affecting the whole form may require a different investigation entirely. Changing every message to “Please try again” leaves those distinctions unresolved.
W3C’s Error Identification guidance calls for automatically detected input errors to identify the affected item and describe the problem in text. Color or other visual cues can supplement that description; the guidance does not prescribe one display method.
Record the field’s visible label, the rejected condition and the actual rule used by the form. The owner should approve the business requirement, while the website manager confirms what the implementation accepts. If those disagree, settle the rule before writing a message that could direct customers toward another rejected entry.
Also establish who supplies the message. It might come from the browser or custom form behavior. The person responsible for the website needs that distinction to determine where a correction belongs; an editable message in one tool does not establish that it controls the error customers see.
Give a correction that matches the rule
W3C’s Error Suggestion guidance distinguishes identifying an error from offering help to fix it. When an error is automatically detected and a correction is known, provide that suggestion unless doing so would jeopardize security or the content’s purpose.
A customer-facing message should answer the immediate question, without an explanation of the software behind the form. The team still needs that technical understanding when approving the wording. An instruction can sound helpful while describing a rule the form does not actually use.
For example, a format hint cannot establish that an email address belongs to the customer or receives mail. Do not make the error copy promise verification that the form has not performed. If the implemented rule is unclear, assign that investigation instead of inventing a format requirement.
A fictional email-field rewrite brief
Imagine a Henderson upholstery-estimate business with one required field labeled “Email address.” The business, form, rules, entries, current and proposed messages, and checks below are wholly fictional. Nothing has been entered into a real form, submitted, implemented or tested.
For this example, assume the owner has approved requiring an email reply address and the website manager has confirmed the actual format rule. The team would still need to verify that the proposed wording fits that rule. These assumptions describe the fictional brief, not a reviewed customer website.
Current message for either condition: “Check your details.”
Proposed message when the field is blank: “Email address: Add the address where we can reply to your estimate inquiry.”
Proposed message for the assumed format error: “Email address: Check that the address includes a name, @ and domain, such as alex@example.com.”
The example address shows a shape, not universal validity or a verified mailbox. Use the format message only when it explains the actual rejection. Another implementation may require different wording.
This brief gives the editor two conditions to distinguish. It does not require the customer to read both messages, and it does not establish that either proposal has appeared on screen. The owner approves the intended meaning; the website manager handles the actual implementation and observation.
Check recovery, not just the new sentence
W3C’s form-notification tutorial discusses clear feedback near fields and overall error feedback. It also describes connecting messages with controls and helping users reach the affected input. The appropriate behavior needs review in the actual form.
For the fictional rewrite, the following observations remain pending:
- Find and understand: Check the actual message and field association, including what a tested assistive-technology combination announces.
- Correct and continue: Check whether keyboard users can reach and edit the field, whether unrelated ordinary entries remain, and what happens when an approved sample correction is entered.
- Resolve the right condition: Check that the corrected field’s error clears appropriately and that any remaining error is understandable. Record the actual outcome rather than assuming the wording change fixed recovery.
Clear wording with an unreachable field calls for behavior work. A correction rejected by an unexpected rule calls for validation investigation. Keep those assignments specific so the team addresses the observed problem.
Keep this review separate from later handoffs
For broader page and inquiry-path concerns, use the mobile website inquiry checklist. If a request is accepted but your staff cannot find or answer it, follow the separate inquiry handoff guide. Neither later receipt nor a successful customer inquiry is established by an error-copy proposal.
Form messages and recovery behavior can be discussed within an agreed website design scope. Email sales@rank.vegas with your website, the form page, the field label and the correction the current message leaves unclear.