Accessible contact and booking forms

For most organizations, a form is where a website does its real work: a customer asks a question, books an appointment, requests a quote or pays a deposit. If someone using a screen reader, a keyboard or voice control cannot complete that form, they cannot reach you through your website at all.

This article covers the WCAG criteria that come up most often in forms, with a before-and-after example.

Labels and instructions

Every field needs a label that says what to enter. Two criteria apply:

• 3.3.2 Labels or Instructions (Level A) requires labels or instructions when content requires user input. If a field has a required format, such as a date as DD/MM/YYYY, say so before the person types.
• 1.3.1 Info and Relationships (Level A) requires that relationships conveyed visually are also available in code. A visible label is not enough on its own; it must be connected to its field so a screen reader announces "Email address, edit text" when the field receives focus.

Related groups of choices, such as a set of radio buttons for "Preferred contact method", should be grouped with a fieldset and legend so the question is read along with each option. Required fields should be identified in text, not by colour alone, and the meaning of any asterisk should be explained at the top of the form.

Input purpose and autocomplete

1.3.5 Identify Input Purpose (Level AA) requires that fields collecting information about the user, such as name, email, phone number or postal address, identify their purpose in code where the technology supports it. In HTML this is done with the autocomplete attribute, using values such as name, email, tel and postal-code.

This lets browsers fill in known details automatically, which helps people with motor impairments who find typing slow, and people with memory or cognitive disabilities. It also helps every customer on a phone.

Errors and how they are explained

Two criteria cover what happens when something goes wrong:

• 3.3.1 Error Identification (Level A): if an input error is automatically detected, the field in error is identified and the error is described to the user in text.
• 3.3.3 Error Suggestion (Level AA): if an error is detected and suggestions for correction are known, they are provided to the user, unless that would jeopardize security or purpose.

A red border on a field fails both: it relies on colour, and it does not say what is wrong. "Invalid input" is better but still unhelpful. "Enter a phone number with 10 digits, for example 204 555 0123" identifies the problem and suggests a fix.

Error messages should sit next to the field they describe and be connected to it in code, so a screen reader reads the message when the field receives focus.

Error prevention for bookings and payments

3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) applies to pages that create legal commitments or financial transactions, change or delete data the user controls, or submit test responses. A paid booking, a deposit or an order is covered. For these, at least one of the following must be true:

• Reversible: the submission can be cancelled or undone.
• Checked: the information is checked for errors and the user can correct them.
• Confirmed: the user can review and correct the information before final submission.

A review screen showing the date, time, service and price before the "Confirm booking" button is the most common way to meet this. A simple contact form that sends a message is generally not covered, although a review step does no harm.

Status messages

4.1.3 Status Messages (Level AA) applies to messages that appear without moving focus, such as "Thank you, your message has been sent", "3 time slots available" or "Sending...". These must be marked up so assistive technology announces them without the user having to go looking. Without this, a screen reader user may press Submit and hear nothing, then submit again.

CAPTCHAs

Image-based puzzles and distorted text are a significant barrier for people who are blind or have low vision, and for some people with cognitive disabilities. Under 1.1.1 Non-text Content, a CAPTCHA must have a text alternative that describes its purpose, and an alternative form using a different sense, such as an audio version, must be provided.

Many organizations can avoid visible CAPTCHAs entirely. Server-side spam filtering, a hidden "honeypot" field that only automated programs fill in, and rate limiting often reduce spam enough for a small business contact form. If a challenge is required, choose one that offers more than one way to pass it, and test it with a keyboard.

A before-and-after example

Here is a common pattern from a page builder form. It looks fine on screen, but the field has no label in code, and the error is shown only as red text that is not connected to the field.

<div class="field">
  <input type="text" placeholder="Phone *">
  <span class="red">Invalid</span>
</div>

The repaired version keeps the same appearance but adds a real label, identifies the input purpose, marks the field as required and in error, and connects a useful message:

<div class="field">
  <label for="phone">Phone (required)</label>
  <input type="tel" id="phone" name="phone"
         autocomplete="tel" required
         aria-invalid="true" aria-describedby="phone-error">
  <p id="phone-error" class="error">
    Enter a 10-digit phone number, for example 204 555 0123.
  </p>
</div>

The success message after submission would then be placed in a region with role="status" so it is announced when it appears.

Testing your forms

You can check the basics yourself: click on each label and see whether the cursor moves into its field, complete the form using only the keyboard, and submit it with a mistake to see what the error message says. Our checklist includes these steps, and our keyboard testing article explains the keys to use. Screen reader announcements need testing with tools such as NVDA and VoiceOver, which is part of our method.

Talk to us

If your contact or booking form is the main way customers reach you, it is usually the first thing we review. See our services or contact us to discuss your site.

Last reviewed October 2026.