Keep labels visible and connected to their fields
W3C’s form-label guidance explains that a control needs a label describing its purpose and an appropriate programmatic association. Text floating near a box is not necessarily connected in the code. Ask your developer to verify the relationship, especially where a page builder has replaced standard controls with a custom visual design.
Our recommendation is to use permanent visible labels such as “Email address” and “How can we help?” Do not make faint placeholder text the only explanation: it disappears when someone types. If an instruction matters after entry begins, keep it visible. For a preferred contact method, make clear whether selecting telephone changes which contact field becomes required.
Explain related choices as a group
A list of radio buttons makes little sense if its question is visually distant or not available to assistive technology. W3C describes grouping related controls using elements such as fieldset and legend. A developer should choose the appropriate structure; an owner can check whether the question and each option remain understandable together.
Illustrative group: “How would you prefer us to respond?” with “Email” and “Telephone” options. Explain that selecting a preference does not automatically make an appointment. Keep the language concrete. Avoid “Yes” and “No” options whose meaning depends on remembering a paragraph higher up the page, and do not preselect an unrelated marketing choice just to shorten the task.
Make mistakes recoverable
W3C’s notification guidance covers identifying errors and explaining corrections. A red outline alone does not tell someone what to fix. Provide a text message that names the issue and connects to the relevant field. For longer forms, a useful error summary can help someone find all outstanding problems without searching through the page.
Illustrative before: “Invalid input.” Illustrative after: “Enter an email address in the format name@example.com.” Do not erase a customer’s entire message because one field needs correction. Let people revisit what they entered, and do not announce success until the application has accepted the submission. The visible confirmation and any screen-reader announcement should communicate the same result.
Test the complete form, including alternatives
Our practical test uses four cases: a normal submission, a missing required field, an unusually long message and a keyboard-only submission. Confirm that controls can be reached, labels remain understandable and errors can be corrected. If the form includes a date picker, file upload or spam challenge, test that component rather than assuming the form builder has handled it.
Have someone familiar with screen-reader testing check the experience when accessibility matters to your implementation review. Automated checks can support the work but do not reveal every interaction problem. Keep a usable alternative contact route visible while defects are being fixed. The objective is a customer who can complete the task, not merely a form with fewer audit warnings.
Your practical checklist
- Keep permanent labels visible.
- Verify labels are connected to controls in the code.
- Group related choices with an understandable question.
- Describe errors in text and retain entered details.
- Confirm successful submission clearly.
- Test keyboard operation and any added widgets.
Written with AI-assisted research and drafting, with source checks and editorial review for this guidebook. Platform facts link to official documentation. Examples and recommendations are our own; no client results are implied. Sources reviewed October 8, 2026. About Getting Found Local