Accessible Forms: A WCAG Checklist for Developers

An inaccessible form quietly turns people away — keyboard users who can’t reach the submit button, screen-reader users who hit an unlabelled field, anyone who can’t tell which input failed. This developer checklist walks through the markup that makes forms work for everyone and meets WCAG 2.2 AA.

1. Label every control

This is the single biggest win. Each input needs a programmatically associated <label> — either wrapping the input or linked with for/id.

<!-- Explicit association -->
<label for="email">Email address</label>
<input id="email" name="email" type="email" required />

<!-- Or wrap the input -->
<label>
  Email address
  <input name="email" type="email" required />
</label>

2. Make it keyboard-operable

• Every control must be reachable and usable with Tab and Enter/Space.
• Use real <button> and <input> elements, not clickable <div>s.
• Keep a visible focus indicator — never outline: none without a replacement.
• Ensure the DOM order matches the visual order so focus moves logically.

3. Group related fields

Radio buttons, checkboxes, and multi-part inputs (like an address) belong in a <fieldset> with a <legend> so the group has an accessible name.

<fieldset>
  <legend>How should we contact you?</legend>
  <label><input type="radio" name="contact" value="email" /> Email</label>
  <label><input type="radio" name="contact" value="phone" /> Phone</label>
</fieldset>

4. Announce errors

When validation fails, the user needs to know which field and why. Mark the field invalid, point it at its message, and put the message somewhere screen readers will announce.

<label for="email">Email</label>
<input
  id="email"
  name="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
/>
<p id="email-error" role="alert">
  Enter an email so we can reply.
</p>

5. Mark required fields honestly

Use the required attribute (it maps to aria-required) and indicate it visually in the label text, not with a bare asterisk that screen readers may skip. If most fields are required, mark the optional ones instead.

The WCAG 2.2 quick checklist

• Every input has a real, associated label.
• The whole form works with a keyboard, with a visible focus ring.
• Related controls are grouped with fieldset + legend.
• Errors are announced, tied to their field, and not colour-only.
• Required state is conveyed in text, not just visually.
• Inputs use correct types and autocomplete tokens for autofill.

Pair this with the form validation guide for accessible error handling, then generate labelled, standards-friendly markup with the HTML form code generator.