Accessible forms: labels, instructions and errors

A form is where a visitor signs up, pays or asks for help, so a form that people cannot complete ends the visit before the task is done. W3C's forms tutorial says accessible forms help screen reader users, who can identify and understand controls more easily when they are tied to labels and groups; speech input users, who use labels in voice commands; people with limited dexterity, who get a larger click area that includes the label; and people with cognitive disabilities, who benefit from clear layout, instructions and feedback. It ties its advice to four success criteria: 1.3.1 Info and Relationships, 2.4.6 Headings and Labels, 3.3.2 Labels or Instructions and 4.1.2 Name, Role, Value.

Missing labels are common. In WebAIM's February 2026 Million report, automated testing found missing form input labels on 51% of home pages, the third most common failure type after low contrast text and missing alternative text. This page is general information about WCAG, not legal advice.

The criteria at a glance

Criteria 3.3.7 and 3.3.8 are new in WCAG 2.2; what's new in WCAG 2.2 lists the others.

Labels for every field

A label is visible text that names a field. The HTML label element ties that text to its control, so software knows which words belong to which field. W3C's labeling tutorial recommends pairing for with id, and the two values must match exactly:

<label for="email">Email address</label>
<input type="email" id="email" name="email">

Every control needs one, including checkboxes, radio buttons and drop-downs. A control that cannot take an id, such as one a script generates, can sit inside its label, though W3C says explicit pairing is generally better supported. Buttons name themselves: a button from its content, an input button from its value, an image input from its alt.

• A label names the purpose. Criterion 2.4.6 asks that labels describe purpose, and a single word can do it. "Email address" does. "Enter here" does not.
• A label stays visible. W3C says most users prefer or need visible labels. It may be hidden visually where context makes the purpose clear, such as a search box beside a Search button, but it must stay in the code for screen reader and speech input users.
• A placeholder is not a label. W3C's instructions tutorial says placeholder text is not a replacement for labels. Our placeholder text guide covers its contrast and its proper use.

When the visible label and the accessible name differ

A control's accessible name is the text assistive technology announces for it. It can come from a label, aria-labelledby, aria-label or title, but W3C recommends the ARIA attributes only when the surrounding content makes the label clear, and does not recommend title. Two rules follow. First, W3C's Understanding page for 3.3.2 says a control can pass 4.1.2 through an accessible name and still fail 3.3.2 if the labels are not presented to all users, not just those using assistive technologies. Second, 2.5.3 Label in Name says the name must contain the text shown, because speech input users say what they see. A button that reads "Search" but is named "Find products" may not answer the spoken command "click Search". W3C lists the mismatch as failure F96.

Grouping related controls

A fieldset groups related controls, and its legend acts as their heading. W3C's grouping tutorial says grouping must be done visually and in the code, and that radio button groups should always use a fieldset:

<fieldset>
  <legend>Delivery method</legend>
  <input type="radio" name="delivery" id="standard" value="standard">
  <label for="standard">Standard</label>
  <input type="radio" name="delivery" id="express" value="express">
  <label for="express">Express</label>
</fieldset>

The same pattern suits checkboxes and blocks of related fields, such as separate shipping and billing addresses that share labels like Street and City. Screen readers may read a legend with every field, once, or rarely not at all, so keep legends short and make each label clear without repeating the legend. A div with role="group" and aria-labelledby is the ARIA alternative.

Instructions, required fields and autofill

Instructions say what a field expects. Criterion 3.3.2 asks for labels or instructions wherever content requires input, and W3C says that does not limit it to required fields. W3C's instructions tutorial names three places to put them:

• Before the form, for rules that apply to all of it, such as how required fields are marked. Placed before the form element, they are read before a screen reader switches to forms mode.
• In the label, as in "Expiration date (MM/YYYY)". W3C says this approach is reliable across browsers and assistive technologies.
• Beside the field, linked with aria-describedby. W3C says the linked text is announced after the label, but warns that instructions outside labels can be missed and are not supported by some older browsers and assistive technologies.

<label for="username">Username</label>
<input type="text" id="username" name="username" autocomplete="username" aria-describedby="username-hint">
<p id="username-hint">Letters and numbers, no spaces.</p>

Marking required fields

Say what is required in words. W3C's technique H90 puts the indication in the label, such as "First name (required)", or in the legend for radio buttons and checkboxes. If you use an asterisk, explain it at the start of the form. Add the required attribute too: MDN says assistive technology should announce the control as mandatory from it, and advises a visible indication near the control that uses more than color alone. aria-required is only a fallback and does not change what the browser enforces.

Letting browsers fill in what they know

Criterion 1.3.5 Identify Input Purpose (AA) asks that fields collecting information about the user, such as name, email and telephone, expose their purpose through the HTML autocomplete attribute (technique H98). MDN lists values such as name, email, tel, postal-code and new-password, and says made-up values fail because the purpose can no longer be determined.

Not making people repeat or remember

Two criteria that are new in WCAG 2.2 apply to longer forms. 3.3.7 Redundant Entry (A) says information already given in the same process is filled in or available to select, with exceptions for essential re-entry, security and information that is no longer valid. W3C's example is a checkbox saying the billing address is the same as the shipping address. 3.3.8 Accessible Authentication (Minimum) (AA) says no step in an authentication process may require a cognitive function test, such as remembering a password or solving a puzzle, unless that step offers another method, a mechanism that assists (W3C lists password manager support and copy and paste), or one of two narrower exceptions for recognizing objects or identifying the user's own non-text content. W3C says a page that blocks pasting, or stops password managers from filling the fields, fails unless it provides an alternative, so let them work. Our CAPTCHA accessibility guide covers the puzzle side.

Error messages and validation

Criterion 3.3.1 Error Identification says that when a page detects an input error, such as an empty required field or a value in the wrong format, the item in error is identified and the error is described in text. W3C says redisplaying the form with no other hint does not meet it, and that color and images may add to text but not replace it. 3.3.3 Error Suggestion adds that when the fix is known, the message says what it is, unless that would jeopardize the security or purpose of the content. A message saying only that an email address is not valid meets 3.3.1. One that also gives the expected format meets both. W3C's notifications tutorial shows a workable pattern:

• A summary at the top. Each item names the field by its label, describes the problem, says how to fix it and links to the field.
• A message beside each field, marked with text such as "Error:" and connected with aria-describedby. Color and icons can add to the text but not replace it.
• Focus on the first field with an error, which the tutorial calls convenient.
• A live region when the page updates without reloading. The tutorial uses role="alert", and criterion 4.1.3 Status Messages (AA) asks that status messages, which include the existence of errors, be exposed through a role or property so they are presented without taking focus.

<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email" aria-describedby="email-error" aria-invalid="true">
<p id="email-error">Error: enter an address in the format name@example.com.</p>

W3C lists aria-invalid as technique ARIA21. Built-in browser validation can meet 3.3.1, but W3C notes its default messages are generally quite generic, so write specific ones. For pages that cause legal commitments or financial transactions, or that modify or delete the user's data, 3.3.4 Error Prevention asks that at least one of three is true: submissions are reversible, entered data is checked and can be corrected, or a step lets people review, confirm and correct before finalizing. More detail is in our guide to accessible error messages.

Custom controls and name, role, value

Criterion 4.1.2 Name, Role, Value (A) covers all user interface components, including form elements, links and components generated by scripts. Each needs a name and role that software can determine, states and values that can be set through code, and a way for assistive technology to hear about changes. W3C says standard HTML controls already meet it when used according to the specification, and that controls built from scripts, or given a different role, need extra measures. Use input, select, textarea and button where they fit, and test any custom date picker, combobox or toggle.

W3C's failure F68 is the plainest case: a control with no name assistive technology can read, such as label text beside an input with nothing joining them, or a label not linked to its input. F111 covers a control with visible label text but no accessible name. Our ARIA basics and buttons vs links guides cover roles, states and choosing the right element.

Check it yourself

These five checks are our own routine, not a W3C procedure, and take a few minutes per form:

1. Click each label. Focus should move to its field, or the checkbox or radio button should toggle. A label that does nothing is not tied to its field.
2. Tab through without a mouse. Focus should follow reading order and stay visible. The keyboard accessibility test has the full routine.
3. Listen with a screen reader. Each field should announce its label, type, any instruction and, after a bad submission, its error. How screen readers read a page explains what you will hear.
4. Submit it wrongly on purpose. Is each problem named in text, beside the field and in a summary? Where does focus land?
5. Read the markup for inputs with no label, placeholder-only fields, invalid autocomplete values and custom controls with no role.

The accessibility bookmarklet runs in your browser on the page as rendered, including staging and logged-in pages, and lists fields with no label and fields labeled only by their placeholder. The WCAG audit checklist tracks all 55 Level A and AA criteria and exports CSV. Scan my site for free runs 16 rule-based checks on up to 3 pages, one of which flags form fields with no label. These check that a name exists, not what it says, and none checks grouping, instructions or autocomplete values, submits a form or tests a script-built control, so the five checks above still matter. What we check lists every rule, and why scanners miss issues explains the limit. For the whole site, see how to test website accessibility and the guide to making a website accessible.

Keep it checked

A form that is labeled today can lose a label in a template change, a plugin update or a redesign. GotAlt checks the pages you monitor every week. It compares each image's alt text with the image itself (up to six images per page), runs its rule checks, opens monitored pages in a browser for contrast and other checks that need a rendered page (see what we check), and reports what changed. Plans are from $69 a month. Audit my whole site from $69/mo.