ACCESSIBILITY

Home › Glossary › Accessibility· 9 ·

Accessible Forms

/ækˈsɛsəbəl fɔːrmz/noun

Filed underAccessibilityFront EndUX

In brief · quick answer

Accessible forms are form controls that every user can perceive, understand, and complete. This means every input has a visible and programmatically associated label, clear error messages, logical focus order, and sufficient touch or click target sizes. Poorly built forms are one of the most common barriers on the web and a frequent source of WCAG violations.

§ 1 Definition

Accessible forms follow a set of HTML and UX practices that ensure all users can complete forms successfully. At minimum: every form control must have a programmatically associated <label> element (WCAG 1.1.1, 1.3.1, 2.4.6). Labels cannot be placeholder text alone because placeholders disappear when the user starts typing and often lack sufficient contrast. Error messages must be clear, specific, and announced to screen readers via aria-describedby or aria-live regions (WCAG 3.3.1, 3.3.2). Required fields must be indicated in more than one way (not just colour, since that fails for colourblind users). The Tab order must follow the visual order of the form. Grouped inputs (radio buttons, checkboxes) must use <fieldset> and <legend>. Form submission must provide feedback (success or error) that is perceivable to all users. WCAG 2.2 added 3.3.7 Accessible Authentication (AA), requiring that authentication processes do not rely on cognitive function tests such as solving puzzles or transcribing distorted text, with an exception for objects or content personalisation.

§ 2 Labels: the most important part of an accessible form

Every form input must have a visible label that is programmatically associated with the input. The <label> element with the for attribute matching the input's id is the standard, most robust method. Wrapping the <label> around the <input> is also valid but less reliable in complex layouts. Never use placeholder text as a label replacement. Placeholder text disappears on input, has no programmatic association, typically has low contrast, and causes users to forget what the field is for after they start typing. The accessible name of a form field comes from the <label>, not from the placeholder. When a label is not possible visually (e.g., a search field with an icon button), use aria-label on the input. But visual labels are always preferred.

§ 3 Error handling and validation

Errors must be communicated clearly and immediately. Inline validation: errors should appear next to the relevant field, not only at the top of the form. The error message must be programmatically associated with the input via aria-describedby so screen readers announce it. Error messages must be specific: "Email address is required" is better than "Field is invalid". Success messages also need attention: after form submission, move focus to the success message or confirmation heading so the user knows something happened. For server-side validation, the page must manage focus to the first error after reload. WCAG 3.3.1 Error Identification (Level A) and 3.3.2 Labels or Instructions (Level A) cover the basics, while 3.3.4 Error Prevention (Level AA) applies to legal, financial, and data-destructive transactions.

§ 4 Grouping related controls

Radio buttons and checkboxes that belong together must be grouped with <fieldset> and labelled with a <legend>. This tells screen reader users that the options belong to the same group and announces the group label before each option's label. Without <fieldset>, a screen reader user navigating radio buttons hears "Option A, Option B, Option C" with no context indicating they are choices for the same question. The <fieldset> and <legend> pattern is one of the most frequently missed accessibility requirements in form design.

§ 5 In code

<!-- Accessible form field with label and error -->
<div>
  <label for="email">Email address</label>
  <input
    type="email"
    id="email"
    name="email"
    required
    aria-describedby="email-error"
  >
  <span id="email-error" role="alert">Please enter a valid email address.</span>
</div>

<!-- Radio group with fieldset and legend -->
<fieldset>
  <legend>Preferred contact method</legend>
  <label><input type="radio" name="contact" value="email"> Email</label>
  <label><input type="radio" name="contact" value="phone"> Phone</label>
</fieldset>

§ 6 Common questions

Q. Can I use aria-label instead of a visible label?: A. Only when a visible label is truly not possible (e.g., a search field with a magnifying glass icon button). Visible labels are better for everyone. They help users with cognitive disabilities, users whose language is not the page language, and anyone who needs to confirm what a field is for. Do not hide labels for aesthetic reasons.
Q. Does autocomplete help accessibility?: A. Yes. WCAG 1.3.5 Identify Input Purpose (Level AA) recommends adding autocomplete attributes to inputs that collect user data (name, address, email, phone, etc.). This allows users to autofill forms with browser-stored data, reducing effort for everyone and particularly benefiting users with motor or cognitive disabilities.

Key takeaways

Every input needs a visible, programmatically associated <label>.
Placeholder text is not a label. It disappears and has poor contrast.
Errors must be specific, associated with the input, and announced to screen readers.
Radio buttons and checkboxes need <fieldset> and <legend> grouping.
WCAG 2.2's Accessible Authentication requires cognitive-test-free authentication options.

How Atomic Glue helps

Atomic Glue builds accessible forms from scratch, not as a retrofit. Labels, error handling, grouping, and keyboard flow are built in from the first HTML element. Our Web Development services produce forms that work for everyone. Get in touch.

Get in touch

# Accessible Forms

Category: Accessibility (also: Front End, UX)

Author: Atomic Glue Team

## Definition

## Labels: the most important part of an accessible form

## Error handling and validation

## Grouping related controls

## In code

<!-- Accessible form field with label and error -->
<div>
  <label for="email">Email address</label>
  <input
    type="email"
    id="email"
    name="email"
    required
    aria-describedby="email-error"
  >
  <span id="email-error" role="alert">Please enter a valid email address.</span>
</div>

<!-- Radio group with fieldset and legend -->
<fieldset>
  <legend>Preferred contact method</legend>
  <label><input type="radio" name="contact" value="email"> Email</label>
  <label><input type="radio" name="contact" value="phone"> Phone</label>
</fieldset>

## Common questions

Q: Can I use aria-label instead of a visible label?

A: Only when a visible label is truly not possible (e.g., a search field with a magnifying glass icon button). Visible labels are better for everyone. They help users with cognitive disabilities, users whose language is not the page language, and anyone who needs to confirm what a field is for. Do not hide labels for aesthetic reasons.

Q: Does autocomplete help accessibility?

A: Yes. WCAG 1.3.5 Identify Input Purpose (Level AA) recommends adding autocomplete attributes to inputs that collect user data (name, address, email, phone, etc.). This allows users to autofill forms with browser-stored data, reducing effort for everyone and particularly benefiting users with motor or cognitive disabilities.

## Key takeaways

Every input needs a visible, programmatically associated <label>.
Placeholder text is not a label. It disappears and has poor contrast.
Errors must be specific, associated with the input, and announced to screen readers.
Radio buttons and checkboxes need <fieldset> and <legend> grouping.
WCAG 2.2's Accessible Authentication requires cognitive-test-free authentication options.

## Related entries

Last updated July 2026. Permalink: atomicglue.co/glossary/accessible-forms