Begin with the task someone came to finish
A service enquiry, application or support request should make its purpose clear before asking someone to type. Our recommendation is to explain what the form is for, what happens after submission, and which details are needed to begin. Ask only for information the receiving team can use. For an early conversation, a short description of the need may be more useful than requiring someone to produce a detailed technical brief.
Make instructions available while people write
W3C’s Web Accessibility Initiative recommends identifying required and optional fields and explaining relevant input formats. It also cautions that placeholder text is not a replacement for a label: that text disappears as someone types. Review each field with those points in mind. Use a visible label, explain unusual formats beside the field, and make the relationship between instructions and controls available to assistive technology. W3C WAI: Form Instructions.
Give errors a clear next step
W3C’s form notification guidance recommends concise messages that identify the affected control and explain how to correct the problem. Its examples include an error list with links to the relevant fields. Apply that principle to the actual request. A message such as “Enter an email address in this format: name@example.com” gives more direction than “Invalid input.” Check that someone using a screen reader can discover the feedback and reach the field that needs attention. W3C WAI: User Notification.
Distinguish receipt from the next decision
After submission, our suggested confirmation states what the system has actually completed. If the request has been stored for review, say that it was received. Give a reference when one is available and explain the next step without promising a response time the team cannot support. If the request failed, say so plainly and provide an appropriate way to try again or contact the team. Test the message against the receiving system’s recorded result.
Review a complete attempt, including recovery
Use a disposable test environment to try a normal submission, a missing required field and a failed server response. Include keyboard use and assistive technology in the review. Where appropriate, preserve non-sensitive entries after a validation error so corrections do not require starting again. Ask participants where the next step became unclear, then fix those specific obstacles. Record the tested scope and remaining gaps; use further testing to assess whether the changes helped.