Forms Accessibility Checklist

Forms are one of the most common accessibility barriers on the web. This checklist covers labels, grouping, validation, error handling, and assistive technology support to ensure every user can complete your forms. Your progress is saved automatically.

Interactive Forms

0 of 24 items complete

Labels and Instructions

Every input has a visible, persistent label Labels remain visible at all times — don't rely on placeholder text alone as a label (SC 3.3.2). Forms pattern
Labels are programmatically associated with inputs Use <label for="id"> or wrap the input inside a <label>. Screen readers must announce the label when the input receives focus.
Required fields are clearly indicated Use required or aria-required="true" and provide a visual indicator (not color alone). Explain the convention at the top of the form.
Help text and hints are linked with aria-describedby Format hints, character limits, or constraints should be associated with the input so screen readers announce them. ARIA guide
Placeholder text supplements but does not replace labels Placeholder text disappears on input and often has poor contrast. Use it only for example input, never as the sole label.

Grouping and Structure

Related inputs are grouped with <fieldset> and <legend> Radio button groups, checkbox groups, and address fields should be wrapped in a fieldset with a descriptive legend (SC 1.3.1). Forms pattern
Multi-step forms indicate progress and current step Use a progress indicator or step list. Each step should have a clear heading describing its purpose.
Form sections use semantic headings Long forms should be broken into sections with heading levels (h2, h3) to aid navigation. Semantic HTML guide
Tab order follows a logical sequence Don't use positive tabindex values. Ensure DOM order matches the visual layout so keyboard navigation is predictable.

Validation and Error Handling

Error messages identify the field and describe the problem Generic messages like "Invalid input" are not enough. State what's wrong and how to fix it (SC 3.3.1, 3.3.3). Forms pattern
Errors are associated with inputs via aria-describedby Link error messages to the input so screen readers announce the error when the field is focused. Use aria-invalid="true" on the field.
An error summary appears at the top of the form on submission List all errors with links to the relevant fields. Move focus to the summary so screen reader users are immediately aware of the issues.
Errors use multiple visual cues, not color alone Combine color with icons, text, or borders to indicate errors. Users who cannot perceive color must still identify invalid fields (SC 1.4.1).
Inline validation does not trigger before the user finishes input Avoid validating on every keystroke. Validate on blur or on submit to prevent premature error messages that confuse screen reader users.
Success states are communicated accessibly After successful submission, provide a clear confirmation message. Use role="status" or move focus to the confirmation. Toast pattern

Input Types and Autocomplete

Correct input types are used for data format Use type="email", type="tel", type="url", etc. to trigger the appropriate keyboard on mobile and enable browser validation.
Autocomplete attributes are set for personal data fields Use autocomplete="name", "email", "tel", "street-address", etc. to reduce redundant entry and support autofill (SC 1.3.5).
Password fields allow paste and password manager autofill Never block paste in password fields. Support password managers to reduce cognitive load (SC 3.3.8).
Custom controls expose name, role, and value Custom selects, date pickers, and toggles must have appropriate ARIA roles and state updates. Prefer native HTML elements where possible. ARIA guide

Keyboard and Interaction

All form controls are reachable and operable via keyboard Tab through the entire form. Every input, button, and custom control must be focusable and operable without a mouse (SC 2.1.1). Keyboard Testing guide
Focus indicators are visible on all form elements Inputs, selects, checkboxes, radios, and submit buttons must show a clear focus ring with at least 3:1 contrast (SC 2.4.7).
Changing a setting does not trigger unexpected context changes Don't auto-submit or navigate when a user selects an option. Use an explicit submit button unless the behavior is explained in advance (SC 3.2.2).
Users can review and correct data before final submission For legal, financial, or data-deletion actions, allow users to review, confirm, or undo submissions (SC 3.3.4, 3.3.6).
Touch targets for form controls are at least 24x24 CSS pixels Checkboxes, radio buttons, and small buttons need adequate target size for users with motor impairments (SC 2.5.8).

Frequently asked questions

What's the biggest mistake in form accessibility?

Treating the placeholder attribute as a label. Placeholders disappear when the user starts typing, can't be reliably read by all screen readers, and often fail contrast. Every input needs a real <label> element. The Form Labeling guide covers this in depth.

Should I use inline or summary error messages?

Both. Inline messages next to each field tell users what is wrong; a summary at the top tells screen reader users that errors exist and how many. Pair each inline error with aria-describedby on the field, and put summary errors in a role="alert" region. See the Forms pattern.

When should I use fieldset and legend?

Whenever you have a group of related inputs that share context — radio button groups, checkbox groups, address blocks, name fields (first + last). The <legend> gives the group an accessible name; without it, screen readers announce each input in isolation with no context.

Should I auto-submit on input change?

Almost never. Per WCAG 3.2.2, input changes shouldn't trigger context changes (form submission, redirect, page reload) without explicit user action. Use explicit Submit buttons. Auto-saving (in place, without navigation) is fine; auto-submitting is hostile.

What's the right way to mark required fields?

Use the required attribute (programmatic) AND a visible marker like * or "(required)" text. Don't rely on color alone (red asterisk on white isn't enough). Add a key at the top of the form if you use asterisks: "Fields marked with * are required."

How do I make error messages announce to screen readers?

Wire aria-describedby on the input to the error message's id. Add aria-invalid="true" to the input. Place the error message in or near the field so it announces when the field is focused. For server-side errors arriving after submit, also put a summary at the top of the form with role="alert".