How to design an accessible inquiry form for a service website

Make the inquiry easy to complete

An accessible inquiry form uses clear labels, a logical sequence, understandable errors and controls that people can operate with a keyboard or assistive technology. It should ask only for information needed to respond to the visitor’s first inquiry.

An inquiry form is often the main way a visitor asks for help, a quote or a conversation. If the form is hard to complete, the rest of the site’s clarity does not matter. This guide explains how a service business can structure a contact or inquiry form so people can finish it without unnecessary friction.

The focus is on clear structure, labels, error handling and basic testing. It does not replace a full accessibility evaluation or project-specific advice about data collection.

Start with the information you actually need

Unnecessary fields add work for visitors. Ask only for what you need to respond usefully on the first reply. For many service businesses that is a name, a way to reply, a short description of the need, and perhaps a preferred contact time or service area.

Mark optional fields clearly. If a field is required, say so in the label or a visible instruction, not only through color. W3C guidance emphasizes associating a label with every form control and helping users avoid and correct mistakes.

Hypothetical example: a fictional residential repair company needs enough detail to decide whether a job is in its area and roughly how urgent it is. Its first-release form asks for name, email, ZIP code or neighborhood, a short description, and preferred contact method. It leaves payment details, full address history and account creation for later conversations.

Use clear labels and a logical order

Every control needs a visible label that explains what to enter. Placeholders are not a substitute for labels; they disappear when the visitor starts typing. Associate labels programmatically with their controls, for example using the label’s for attribute and the control’s matching id, or by nesting the control within its label.

Group related fields. Use a fieldset and legend for related choices such as preferred contact method. Keep visual order consistent with reading and tab order so keyboard and screen-reader users encounter fields in a sensible sequence.

MDN’s form-structure guidance explains labels and fieldsets. Prefer native input, select and button controls unless there is a clear reason to build a custom interaction; custom controls need additional keyboard and accessibility behavior.

Make required fields and errors understandable

Indicate required fields in text as well as any visual cue. When something goes wrong, name the field and explain what is needed in plain language. “Email is required” or “Please enter a valid email address” is clearer than “There was a problem.”

Show errors near the relevant field and keep previous input where possible. Associate field-specific help and errors using aria-describedby where appropriate, and mark invalid controls with aria-invalid. For longer forms, an error summary with links to affected fields can help users locate corrections.

Client-side checks give quick feedback; server-side checks remain essential because browser validation can be bypassed. Distinguish invalid input from a network failure. Announce asynchronous submission results through an appropriate status or alert region without relying on a color change alone.

Support keyboard, mobile and assistive technology use

Ensure every interactive element can be reached and operated with the keyboard, with a visible focus indicator. On narrow screens, avoid forced horizontal scrolling and keep touch targets comfortable to operate. Test that labels remain associated and error text stays readable when zoom is increased.

Do not rely on color alone to convey meaning. Pair color with text that explains the state. Check the actual tab sequence, menu behavior and submission feedback, rather than assuming that a responsive layout is automatically accessible.

These practices support the accessibility principles of making content perceivable, operable, understandable and robust. Preliminary checks reveal some problems, but do not establish full conformance.

Practical example: a discovery-call inquiry

A fictional consulting firm offers short discovery calls. Its inquiry form includes the fields below. This is a hypothetical illustration, not a description of Medivh Code’s current backend.

After a failed submission, the firm shows a summary of problems and a specific message for each affected field. A successful submission stores the request, sends an internal notification and displays what happens next. It states a response window only if the team can support it. No payment or account creation is required.

Real implementations must match the organization’s privacy policy, retention rules and technical environment. Storage, notification delivery and human review are separate events; confirmation text should not claim all three happened unless each was verified.

• Name (required)
• Work email (required)
• Organization (optional)
• Brief description of the question (required, multi-line)
• Preferred contact window (optional select)

Checklist before you treat the form as ready

Run these checks against the deployed form using non-sensitive sample data. Record what you tested and any remaining limits.

• Only necessary fields are present; optional fields are clearly marked.
• Every control has a visible, programmatically associated label.
• Required fields are indicated in text, not color alone.
• Error messages name the field and explain how to fix the problem.
• The form can be completed with keyboard only and focus is visible.
• The layout remains usable on a narrow screen without horizontal scrolling.
• A successful test submission is received by the intended backend process.
• Invalid, empty and oversized inputs produce clear, recoverable errors.
• Retry and network-error behavior preserve input without unintended duplicates.
• Confirmation text tells the visitor what actually happened and what comes next.
• Data handling matches the published privacy information.