Form Accessibility Audit: 7 Mistakes to Check For

This is a checklist for reviewing a form that already exists: a signup page you inherited, a client's checkout, a contact form built by a plugin. For each of the seven mistakes below you get a quick way to spot it, the WCAG success criterion it fails, and the fix in a line or two. When you need the full reasoning and complete markup for building a form from scratch, read our guide to accessible forms: inputs, labels and errors. This page is for finding the problems first.

You need a browser, the keyboard, and ten minutes per form. Run an automated check first so you spend the ten minutes on what software cannot decide: our form label checker flags inputs with no accessible name, and a free scan covers the rest of the page. Automated checks find many problems but cannot confirm that a form conforms to WCAG, which is why the manual steps below matter.

1. Inputs with no associated label

How to spot it: click the visible label text. If the cursor does not jump into the field, the label is not tied to it. In the browser's accessibility inspector, the input's "Name" will be empty or will come from the placeholder.

Fails: 1.3.1 Info and Relationships and 3.3.2 Labels or Instructions.

<!-- Broken: text next to the input, not tied to it -->
<span>Email</span>
<input type="email" name="email">

<!-- Fixed: label for matches the input id -->
<label for="email">Email</label>
<input type="email" id="email" name="email">

2. Placeholder text doing the label's job

How to spot it: type one character into each field. If you can no longer tell what the field is for, the placeholder was the only label. The HTML standard is direct about this: the placeholder attribute should not be used as an alternative to a label.

Fails: 3.3.2 Labels or Instructions, because the instruction vanishes while the person is still filling the field in.

Fix: add a visible <label> that stays on screen. Keep the placeholder only for an example format, such as [email protected].

3. Errors shown only in red

How to spot it: submit the form empty, then take a screenshot and turn it to greyscale (most image editors and operating system color filters can). If you can no longer tell which fields are wrong, color is carrying the meaning alone.

Fails: 1.4.1 Use of Color, and usually 3.3.1 Error Identification, which asks for the error to be described in text.

Fix: put a written message next to the field that says what is wrong ("Enter an email address, like [email protected]"). An icon helps too, but the text is what counts.

4. Error messages a screen reader never announces

How to spot it: in the inspector, look at an invalid field after submitting. If it has no aria-invalid="true" and its error text is not referenced by aria-describedby, a screen reader user who tabs back to the field hears the label and nothing else. For a quick confirmation, turn on VoiceOver (Mac) or NVDA (Windows, free) and tab through.

Fails: 3.3.1 Error Identification. An error count or banner that appears without moving focus is a status message, so it also has to meet 4.1.3 Status Messages.

<!-- Broken: the message is only visible -->
<input type="email" id="email" class="is-red">
<p class="error">Invalid email</p>

<!-- Fixed: the field is marked invalid and points to its message -->
<input type="email" id="email" aria-invalid="true" aria-describedby="email-error">
<p id="email-error">Enter an email address, like [email protected]</p>

When to set and remove aria-invalid, and how to build an error summary for long forms, are covered step by step in the accessible forms guide.

5. Personal data fields without autocomplete

How to spot it: in the inspector, check the name, email, phone and address fields for an autocomplete attribute. Then try filling the form with the browser's autofill. If nothing fills, the attribute is missing or wrong.

Fails: 1.3.5 Identify Input Purpose, a Level AA criterion added in WCAG 2.1. It applies to fields that collect information about the user, for the purposes listed in WCAG's input purposes section, which match the HTML autofill tokens.

Fix: add the matching token: autocomplete="given-name", "family-name", "email", "tel", "postal-code" and so on. Autofill saves typing for people with motor impairments and memory load for people with cognitive disabilities.

6. Custom controls that trap the keyboard

How to spot it: put the mouse away and press Tab from the top of the page to the submit button. Open every date picker, dropdown and popup on the way. If focus gets stuck, disappears, or cannot leave a widget with Tab or Escape, you have found it. Our guide on how to test keyboard accessibility by hand walks through the full routine.

Fails: 2.1.2 No Keyboard Trap, and 2.1.1 Keyboard if a control cannot be operated at all.

Fix: prefer native elements (<select>, <input type="date">) where the design allows. For custom widgets, follow the matching pattern in the ARIA Authoring Practices Guide and return focus to the trigger when a popup closes. The keyboard and focus checker catches some of the markup causes, but only a person pressing keys can confirm the whole flow works.

7. Required fields marked only by an asterisk

How to spot it: look for a legend explaining the asterisk near the top of the form, and check the inspector for required or aria-required="true" on each mandatory input. A red star with neither is a guess for sighted users and silent for screen reader users.

Fails: 3.3.2 Labels or Instructions, which expects people to know what input is needed before they submit.

<!-- Broken: a decorative star, nothing in the markup -->
<label for="name">Name <span class="red">*</span></label>
<input id="name">

<!-- Fixed: the requirement is in the text and in the markup -->
<p>Fields marked * are required.</p>
<label for="name">Name *</label>
<input id="name" required>

How to report what you find

If the form belongs to a client or a manager, list each problem with three things: the field, the mistake number from this page, and the criterion it fails. "Email field: error shown in red only, fails 1.4.1 Use of Color" is something a developer can fix and a non-developer can follow. Group the findings by form rather than by criterion, because people fix one form at a time.

Your ten-minute form audit

• Run the form label checker or a free scan on the page first.
• Click every label: does it focus its field?
• Type in every field: is the label still visible?
• Submit empty: is every error written in text, next to its field?
• Inspect an invalid field: aria-invalid and aria-describedby present?
• Check personal data fields for autocomplete tokens.
• Tab through the whole form, including every widget, without the mouse.
• Confirm required fields are explained in text and marked with required.

Once you know what is broken, the accessible forms guide has the complete patterns to rebuild it.