Plain language and accessible design can make an online request easier to understand without hiding what matters
By Arbab Naseebullah Kasi, Chief Executive Officer - CEO, Feel Worldwide Foundation Inc.
A calm workspace for a clearer digital task.
Someone opens a registration page with a simple intention: join an activity, request information or arrange a service. Before long, they are trying to interpret an unfamiliar label, decide whether a question applies to them and work out why the page has rejected an answer.
The organisation may see a small form. The person completing it encounters a sequence of decisions. Each unclear instruction creates another task before they can finish the one they came to do.
A better form begins with understanding that experience. Its purpose is to help people provide the information genuinely needed for a clear next step. Making it visually shorter can help in some circumstances, but removing explanations, shrinking controls or hiding labels can make a compact page harder to use.
For a small business, community organisation or educational programme, improving a form is a practical piece of service design. It requires attention to the questions, the controls and what happens after submission. None of those elements should be left for the user to guess.
Know why each question is there
Before adjusting colours or spacing, review what the organisation is asking. For each question, identify who uses the answer and what decision or action it supports. If nobody can explain that connection, reconsider whether the question belongs in this form.
The GOV.UK Design System's question-page guidance offers a useful public example. It tells service teams to understand why they ask each question and request only information they need. It also recommends allowing uncertainty as an answer when that is valid, and avoiding requests to re-enter information already supplied within the same journey. These are design recommendations, not proof that one layout will work for every service.
Consider an illustrative registration for a public introductory workshop. An email address may be needed to send joining details. A question about a participant's employer may have no bearing on registration. If the team only hopes the answer might be interesting later, that is a weak reason to make it compulsory now.
This example is hypothetical. The relevant questions will depend on the actual activity. The point is to make the reason for collection explicit before building the page, rather than treating every available field as an invitation to collect more information.
Explain the task before asking for effort
A person should be able to tell what the form does, who it is for and what completing it will accomplish. An expression of interest, an application and a confirmed booking are different actions. Use language that preserves those differences.
If supporting documents are required, explain that before someone reaches the upload step. If an appointment depends on availability, say so before the person assumes they have reserved a time. Give an estimated completion time only when you have a reasonable basis for it, including the effort of finding any required information.
Plain language helps here because it makes the action visible. “Tell us which session you want to attend” is more useful than a label such as “Programme preference specification.” The wording should suit the audience without talking down to them.
Explain specialised terms where they are necessary. Avoid asking people to decode the organisation's internal department names or administrative categories. A person may understand their own need perfectly well while having no reason to know how your team files it.
Keep the question visible while it is answered
A label tells the user what a field is for. It needs to remain understandable when the field contains an answer and when someone moves back through the form to check their work.
W3C's guidance on labelling form controls explains that labels should identify the purpose of fields, checkboxes and other controls, and be associated with those controls in the code. That association helps assistive technology present the correct label and can provide a larger clickable area. A visually attractive caption beside a field is not enough if the technical relationship is missing.
For a team using a website builder, this is a reason to check the actual form component rather than assume its appearance proves accessibility. Keep a clear visible label and put examples or supporting instructions where they remain available. Pale example text inside an empty box should not carry all the information a person needs once they start typing.
Use optional questions sparingly and identify them clearly. Do not make a person discover which answers are required through repeated failed submissions. The same care applies to choices: people should understand whether they can select one answer or several.
Let the structure follow the task
There is no useful universal rule that every form should fit on one screen. A short, familiar request may work well on a single page. A longer application may benefit from separate stages with a clear way to review previous answers.
Think about the decisions the person must make together. Related questions can belong together, while an unrelated request may need explanation or removal. Avoid splitting a simple action into so many screens that navigation becomes the main activity.
An illustrative event form might first establish the session, then ask for contact information and any necessary participation arrangements. That sequence should be tested with the people who will use it. It is a starting hypothesis, not a template that every event should adopt.
Pay particular attention to the back button. People may realise that an earlier answer needs correction. If returning to it unexpectedly clears their work, the form has created a cost for checking carefully. Decide how answers should be preserved, and test that behaviour rather than relying on an intention written in a specification.
Make controls easier to use
A form can be understandable yet difficult to operate. Small controls placed close together may be hard to select, especially on a phone or for someone using an alternative input method.
There is a concrete numerical reference in WCAG 2.2. Success Criterion 2.5.8, at Level AA, specifies a pointer target of at least 24 by 24 CSS pixels, with exceptions including sufficient spacing and certain inline controls. W3C's explanation of the target-size criterion also notes that larger targets can help users. CSS pixels are a web layout unit, not a promise about a button's physical size on every device. Meeting this one criterion does not establish that a whole form is accessible or legally compliant.
For the person commissioning a form, the practical request is straightforward: make the controls comfortable to activate and have their implementation checked. Do not compress the page by making important buttons tiny.
Also try moving through the form with a keyboard. Can you reach each control, see where the focus is and complete the task without a mouse? Test enlargement and small screens. These checks can expose problems, but they do not replace evaluation with disabled users and appropriate accessibility expertise.
Help people recover from mistakes
An error message should tell someone what needs attention and how to correct it. A red border or a general message that something went wrong leaves too much work for the person completing the form.
W3C's form-notification tutorial recommends error summaries that identify the relevant controls, describe the problem clearly and explain how to fix it. It also describes linking an error to its field and making updates available to assistive technology. This is practical guidance about recovery, not a recommendation to overwhelm users with alerts.
For example, an illustrative date field could explain the expected format and show an unambiguous example. If the service can accept several sensible formats safely, the team should consider doing that instead of forcing people to reproduce an arbitrary pattern.
Preserve valid answers when another answer needs correction. Avoid blaming language. The immediate purpose is to help the person finish accurately, not to announce that the system has caught them doing something wrong.
Some failures belong to the service rather than the user. If an upload fails because the service is unavailable, do not present it as a mistake in their answer. Explain what can be done next, using only support routes and recovery options that actually exist.
Finish with a clear account of what happened
Submission is not the end of the user's need for information. They may still wonder whether the request arrived, whether a place is confirmed or whether another action is required.
The GOV.UK confirmation-page pattern recommends explaining what happens next and when, providing contact details and offering a way to save a record. Its public example distinguishes an application being completed from a later decision about registration. That distinction is useful for many services beyond government.
For the illustrative workshop, a confirmation should accurately state whether the person has booked a place or merely requested one. If an email has actually been sent, the page can say so. If the system has only accepted the request, avoid implying that a human has reviewed it.
State a response time only if the team can reasonably support it. An impressive promise on the final page is not a substitute for a working process behind the form.
Observe where the effort goes
Before release, ask people unfamiliar with the form to attempt a realistic task using non-sensitive test information. Watch for hesitation and wrong turns without immediately explaining what the page meant to say. Their questions can reveal assumptions the designers no longer notice.
Include people with different access needs and ways of using technology. Make participation voluntary and handle test information carefully. Do not require someone to disclose a private circumstance merely to demonstrate a design problem.
After release, use proportionate evidence to guide revisions. Repeated requests for help, validation failures and incomplete journeys may suggest where to investigate. An abandoned form does not automatically mean poor design; someone may discover the service is unsuitable or decide not to continue. Likewise, a high completion rate does not prove that the information collected was necessary or that the experience was accessible.
Choose one important form and examine the whole journey, from the invitation to the confirmation. Remove an unnecessary question, clarify an instruction or repair an obstacle, then check whether the change helps the intended users. The aim is a service people can understand and use with confidence, not merely a page that looks efficient to its owner.
Which question or step in a form you use could be made easier for someone encountering it for the first time?
