A customer sees “Invalid data” but cannot tell which field needs fixing. The owner sees an unfinished request but cannot tell whether price, an unclear date format or an inaccessible button stopped the person. AI can help rewrite form copy. A polished draft, however, does not establish that someone can complete the form with a keyboard or screen reader.
This guide is for a small hotel, repair business or other service taking requests through a website. The deliverable is approved field copy and test scenarios for the website provider. It is an editorial workflow, not accessibility certification or a promise of more enquiries.
Establish what the form actually does
Do not start with “make this form friendly.” Describe its purpose in one sentence: for example, “send a repair enquiry, not book a confirmed appointment.” Then check each field and validation rule with the person responsible for the service.
Build a working register with these columns:
| Register field | What to record |
|---|---|
| Field code | Stable identifier, such as request-date |
| Reason for asking | The action that requires this information |
| Required status | An approved rule, not an AI assumption |
| Accepted input | The system’s actual formats and restrictions |
| Copy | Label, hint and separate error messages |
| After submission | Actual outcome and approved next step |
| Owner and version | Who confirms the rule and when it was checked |
If the team cannot explain why a field is needed, review the process first. AI should not add a date of birth, address or mandatory phone number simply because these appear on other forms. Use invented examples for copy editing rather than exporting real customer submissions.
Separate the label, hint and error
A label identifies the information to enter. A hint explains a required format before entry. An error describes a specific problem after validation. Do not ask the model to squeeze all three jobs into a decorative line.
W3C WAI recommends associating labels with form controls. Text displayed next to a field is not the same as a programmatic connection to it. For ordinary HTML fields, the provider will usually use a label element and the matching identifier.
WAI’s instructions guidance explains that placeholder text inside an empty field does not replace its label: it disappears during entry. Required input and formats must be understandable, and instructions must also be available to assistive technology.
AI’s practical assignment is narrow: suggest wording from approved rules, without changing those rules or generating implementation code that bypasses a separate review.
Example: a repair enquiry, not a booking
This is an invented example, not a test of a real website. Suppose a repair business requires “Email address for our reply,” “Service type” and “Preferred date.” A phone number is optional. The system accepts dates as day.month.year, while a staff member confirms the appointment separately.
For an empty date field, a draft could say “Enter your preferred date.” For a wrongly formatted entry, it could say “Enter your preferred date in day.month.year format.” These are different situations; a generic “Something went wrong” does not explain the action needed.
“Send enquiry” is a more accurate button label than “Book” when no booking occurs. Once the system has confirmed receipt, the message could say “Enquiry received. Your appointment date and time are not yet confirmed.” Do not add “We will reply within 15 minutes” unless the business has approved and can support that commitment.
A service outage is not a mistake in the customer’s date. The GOV.UK Design System distinguishes input problems from service problems the user cannot fix. For this example, the team must separately approve outage wording and a verified alternative contact route. Do not claim receipt when the system has not confirmed it.
Give AI a bounded assignment
Try this editorial prompt:
Draft English form copy using only the supplied field register. For every field code, return a label, short hint, message for an empty required field and message for each confirmed validation rule. Do not add fields, requirements, response deadlines, contact routes or a booking promise. Separate input errors from service failures. If a rule is undefined, write “Owner decision required.” Separately suggest the button label and a message for confirmed receipt. Do not publish anything.
Also request a list of contradictions: for example, a hint says the phone number is optional, but the system will not proceed without it. That is a decision for the process owner, not a reason to let the model choose the rule. Our working-brief guide explains the general approach.
Check language, then implementation
WAI’s writing guidance favours clear sentences, familiar words and explanations of unfamiliar abbreviations. Remove bureaucratic phrasing without deleting an important condition. If the site has Ukrainian and English forms, verify matching rules, not just translation grammar.
WAI recommends feedback about submission outcomes and an understandable route to correcting errors. Give your provider test scenarios, not only a file of new copy:
- An empty required field produces the corresponding message.
- An incorrectly formatted entry triggers the approved error for that condition.
- An optional field can be left empty.
- Successful submission and service failure produce different, truthful outcomes.
- A customer can locate the problem field and correct it.
Walk through the customer’s task
On a test version, ask the responsible person to complete the journey with a keyboard, without a mouse: reach fields, choose options, submit, find an error and correct it. Check visible focus, a logical navigation order and whether any control traps the person. With enlarged text, check that labels and messages do not cover the fields. These are preliminary checks, not a full audit; WAI expressly limits the conclusions of Easy Checks.
For screen-reader checking, involve someone who knows how to use the technology. Check whether they receive the label, hint, field state and outcome of the action. WAI recommends combining user involvement with standards evaluation: one person’s success does not prove accessibility for everyone.
Record the form version, scenario, device, browser, assistive technology, observation and person responsible for fixing the issue. Mark an unperformed test “not checked,” not “passed.” AI can organise this log; it cannot substitute for observations.
Takeaway: begin with one form and an approved register of its rules. AI drafts alternatives; a person confirms the meaning; the provider checks implementation; users help uncover barriers. Rewriting alone does not make a form accessible.
Author: Nadali. Prepared using AI. Primary sources checked on 28 October 2026. Nadali has not tested the invented form described here. The cover is an AI illustration of generic forms, not an image of a tested form.
