Accessible HTML Forms: Labels, Instructions, Errors, and Keyboard Support

What makes a form accessible?

An accessible form communicates the name, purpose, state, and requirements of each control. It also preserves a logical path through the form and provides feedback that does not depend on sight, color, hearing, or pointer use alone.

In practical terms, people should be able to:

• recognize what the form is for;
• identify each field and its expected input;
• understand which fields are required;
• move through the controls in a logical order;
• operate the form with a keyboard or other input method;
• review and correct errors without losing their work;
• recognize when submission succeeds or fails; and
• complete the task without solving an avoidable accessibility barrier.

These qualities help many people, not only those using assistive technology. Clear form structure also helps people using small screens, entering unfamiliar information, working in distracting environments, or recovering from an input mistake.

Start with native HTML controls

Native HTML form elements already provide much of the keyboard behavior and accessibility information a form needs. Common controls include:

• <input> for short text, email addresses, telephone numbers, dates, and other defined input types;
• <textarea> for longer text;
• <select> and <option> for established choices;
• <input type="checkbox"> for independent choices;
• <input type="radio"> for one choice within a group;
• <button> for submission and other form actions;
• <fieldset> and <legend> for related controls; and
• <label> for naming controls.

A styled <div> does not automatically inherit the semantics or interaction behavior of a button, checkbox, or text field. Rebuilding native controls with generic elements usually creates additional work involving roles, keyboard events, focus management, states, and compatibility testing.

When a native element can express the intended control, it is generally the most durable starting point. This follows the same principle discussed in When ARIA Is Unnecessary: Let Native HTML Do the Work.

Use appropriate input types

Input types communicate purpose and can improve the experience on mobile devices. For example:

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

The email type may provide an appropriate mobile keyboard and basic format checking. Other useful types include tel, url, date, number, and password. The type should match the nature of the information rather than the desired visual appearance.

For example, a postal code may contain leading zeros or letters and is not a quantity used in calculations. A text input is often more appropriate than type="number".

Give every form control an accessible name

A visible <label> is the clearest way to identify most form controls. The label tells sighted users what the field means and gives assistive technologies a programmatic name to announce.

<label for="full-name">Full name</label>
<input
  type="text"
  id="full-name"
  name="full_name"
  autocomplete="name"
>

The label’s for value must match the control’s unique id. Selecting the label also moves focus to the associated input or toggles the associated checkbox or radio button, increasing the usable target area.

Do not rely on placeholder text as a label

Placeholder text is not a dependable replacement for a visible label. It disappears when a person enters information, often uses low visual contrast, and may be mistaken for a prefilled value.

A placeholder can occasionally provide a short example, but persistent instructions are usually clearer:

<label for="account-number">Account number</label>
<p id="account-number-hint">Enter the 10-digit number from your statement.</p>
<input
  type="text"
  id="account-number"
  name="account_number"
  inputmode="numeric"
  aria-describedby="account-number-hint"
>

Keep the visible label in the accessible name

Voice-control users may identify a control by saying the text they can see, such as “Select Email address.” If an aria-label replaces that visible wording with a different accessible name, the spoken command may no longer match the control.

Visible labels and accessible names should therefore agree. In most conventional forms, a properly associated HTML <label> removes the need for aria-label.

Use hidden labels only when the purpose remains visually clear

Some compact interfaces, such as a search form with a nearby heading and recognizable layout, may use a visually hidden label. This technique should not become a way to remove useful visible information merely for a cleaner appearance.

<label class="visually-hidden" for="site-search">Search this website</label>
<input
  type="search"
  id="site-search"
  name="q"
  autocomplete="off"
>
<button type="submit">Search</button>

The label should remain available in the accessibility tree. Hiding it with display: none or the hidden attribute would normally remove it from assistive technology as well.

Connect instructions and descriptions to their fields

Instructions should appear before a person needs them. If a field has a format requirement, character limit, privacy explanation, or other essential condition, communicate it before submission rather than revealing it only after an error.

<label for="password">Create a password</label>
<p id="password-requirements">
  Use at least 12 characters. Spaces are allowed.
</p>
<input
  type="password"
  id="password"
  name="password"
  autocomplete="new-password"
  aria-describedby="password-requirements"
>

aria-describedby creates a programmatic relationship between the field and supporting text. Many screen readers announce the description when the control receives focus.

The description should remain concise. Associating several long paragraphs with one input can make the field cumbersome to navigate. Place broad instructions near the beginning of the form and reserve field-level descriptions for information specific to that control.

Do not communicate requirements through visual position alone

Instructions such as “Complete the fields on the right” or “Select one of the options below in green” depend on layout or color. Responsive designs may change position, and some users may not perceive the stated visual distinction.

Name the relevant section or field directly instead.

Group related form controls

A <fieldset> groups controls that share a question or category. Its <legend> provides the group’s name.

<fieldset>
  <legend>Preferred contact method</legend>

  <input type="radio" id="contact-email" name="contact_method" value="email">
  <label for="contact-email">Email</label>

  <input type="radio" id="contact-phone" name="contact_method" value="phone">
  <label for="contact-phone">Phone</label>

  <input type="radio" id="contact-text" name="contact_method" value="text">
  <label for="contact-text">Text message</label>
</fieldset>

Without the legend, a screen reader user moving directly among the radio buttons might hear “Email,” “Phone,” and “Text message” without the shared question “Preferred contact method.”

Fieldsets are especially useful for:

• radio-button questions;
• groups of related checkboxes;
• multiple fields that form one conceptual answer; and
• sections requiring a shared instruction.

Not every visual section needs a fieldset. Standard headings and paragraphs may be more appropriate when the content is not a group of related controls.

Identify required fields clearly

People should know which fields are required before attempting to submit the form. Use the HTML required attribute when a field must contain a value, and provide a visible indication as well.

<label for="contact-email">
  Email address <span aria-hidden="true">(required)</span>
</label>
<input
  type="email"
  id="contact-email"
  name="email"
  autocomplete="email"
  required
  aria-required="true"
>

For native HTML inputs, required already conveys the required state to modern browsers and assistive technologies. Adding aria-required="true" is often unnecessary, although it may appear in systems supporting older or customized patterns.

If an asterisk is used, explain its meaning near the beginning of the form. Do not depend on color alone to distinguish required and optional fields.

When nearly every field is required, it may be clearer to state that all fields are required unless marked optional. The form should use one consistent convention.

Make validation and errors understandable

Validation should help people recover from mistakes. An accessible error message identifies the affected field, explains the problem in plain language, and suggests a correction when one is known.

“Invalid input” is rarely enough. More useful messages include:

• “Enter an email address in the format [email protected].”
• “Choose a preferred contact method.”
• “The end date must be the same as or later than the start date.”
• “Enter the card number without spaces or dashes.”

Connect an error message to the field

<label for="email">Email address</label>
<input
  type="email"
  id="email"
  name="email"
  value="sam@example"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error">
  Enter a complete email address, such as [email protected].
</p>

aria-invalid="true" communicates that the current value has failed validation. It should generally be applied after validation identifies a problem, not placed on every empty field when the page first loads.

If a field already uses aria-describedby for instructions, the error message can be added to the same attribute:

aria-describedby="email-hint email-error"

Use an error summary for longer forms

When several fields contain errors, a summary near the beginning of the form helps people understand what happened. Each listed error can link to the relevant field.

<div class="error-summary" tabindex="-1" aria-labelledby="error-summary-title">
  <h2 id="error-summary-title">There are 2 problems with your submission</h2>
  <ul>
    <li><a href="#email">Enter a complete email address</a></li>
    <li><a href="#contact-method">Choose a preferred contact method</a></li>
  </ul>
</div>

After an unsuccessful submission, a script may move focus to the summary so keyboard and screen reader users encounter the feedback immediately. Focus movement should be intentional and tested; unexpected focus changes can be disorienting.

Do not identify errors by color alone

A red border can reinforce an error state, but it should not be the only signal. Include text explaining the error, maintain sufficient contrast, and preserve a programmatic relationship between the message and the field.

Preserve the person’s previous input

Except for sensitive values that should not be retained, avoid clearing completed fields after validation fails. Re-entering valid information increases effort and may prevent some people from completing the form.

Allow review before consequential submissions

Forms involving legal commitments, financial transactions, or significant data changes may require a confirmation, review, or reversal step. The person should be able to verify important information before the action becomes final.

Preserve keyboard and focus behavior

Every interactive part of a form should be operable without a mouse. A person should be able to use Tab and Shift + Tab to move through controls in a logical order, use standard keys to operate choices, and see where keyboard focus is located.

Accessible keyboard behavior includes:

• a visible focus indicator;
• a focus order that follows the meaning and visual flow of the form;
• no keyboard traps;
• standard operation for checkboxes, radio buttons, select menus, and buttons;
• no positive tabindex values used to force an artificial order; and
• careful focus handling when content appears, disappears, or reports errors.

The document order should normally determine the focus order. CSS can change visual placement without changing the underlying DOM sequence, so a form that looks correctly arranged may still have a confusing keyboard path.

More detailed guidance is available in Keyboard Navigation Best Practices.

Use buttons for actions

Use a real <button> for form submission and other actions:

<button type="submit">Send message</button>

Button text should explain the action. “Send message,” “Create account,” and “Save address” communicate more than a general label such as “Submit.”

Declare the button type explicitly. Inside a form, a button without a type defaults to submission in HTML. A control intended to reveal help or add another field should use type="button".

Support autocomplete and familiar input purposes

The autocomplete attribute helps browsers and assistive tools recognize common information such as names, addresses, telephone numbers, usernames, and email addresses. This can reduce typing and support people with motor, cognitive, memory, or language-related barriers.

<label for="given-name">First name</label>
<input
  type="text"
  id="given-name"
  name="given_name"
  autocomplete="given-name"
>

<label for="family-name">Last name</label>
<input
  type="text"
  id="family-name"
  name="family_name"
  autocomplete="family-name"
>

<label for="phone">Phone number</label>
<input
  type="tel"
  id="phone"
  name="phone"
  autocomplete="tel"
>

Standardized autocomplete tokens are preferable to improvised values. Common tokens include:

• name;
• given-name;
• family-name;
• email;
• tel;
• street-address;
• postal-code;
• username;
• current-password; and
• new-password.

Avoid blocking password managers, pasted values, or browser autofill without a genuine security reason. Preventing these tools can create barriers and does not necessarily make authentication safer.

Handle dynamic forms carefully

Some forms reveal additional fields, update totals, add repeated sections, or display status messages without loading a new page. Dynamic behavior can remain accessible, but the change must be understandable and keyboard reachable.

Use a button to reveal optional fields

<button
  type="button"
  aria-expanded="false"
  aria-controls="additional-details"
>
  Add additional details
</button>

<div id="additional-details" hidden>
  <label for="details">Additional details</label>
  <textarea id="details" name="details"></textarea>
</div>

When the region opens, the script should update aria-expanded to true and remove the hidden attribute. Moving focus into the region may be appropriate in some interfaces, but not every expansion requires it. The person’s expected next action should guide the decision.

Announce important status changes

A status region can communicate asynchronous updates such as “Address saved” or “Three matching locations found.” Native HTML and ordinary focus movement should be considered first. When an update would otherwise remain unnoticed, a restrained live region may help:

<p id="form-status" role="status" aria-live="polite"></p>

Live regions should be tested with the actual interaction. Overuse can create repeated announcements, interruptions, or confusing feedback.

Do not hide unexpected consequences

Changing a selection should not unexpectedly submit the form, move focus, open a new page, or substantially change context without warning. A separate button is usually clearer for consequential actions.

Keep authentication and human verification accessible

Authentication forms should support password managers, copy and paste, and familiar browser behavior. Requiring people to transcribe, remember, or solve information unnecessarily can create cognitive and motor barriers.

CAPTCHAs are particularly difficult because many challenge types depend on vision, hearing, interpretation, or precise interaction. If abuse prevention is necessary, consider approaches that do not require every person to complete a puzzle. Where a challenge remains, provide accessible alternatives and a way to request help.

Security and accessibility are not opposing goals. A secure process should account for the tools people use to authenticate safely, including password managers, one-time codes, and assistive technologies.

A basic accessible contact form

The following example combines explicit labels, appropriate input types, autocomplete values, a grouped set of radio buttons, an optional description, and a clear submission action.

<form action="/contact" method="post">
  <p>Fields marked “required” must be completed.</p>

  <div>
    <label for="name">Full name (required)</label>
    <input
      type="text"
      id="name"
      name="name"
      autocomplete="name"
      required
    >
  </div>

  <div>
    <label for="email">Email address (required)</label>
    <input
      type="email"
      id="email"
      name="email"
      autocomplete="email"
      required
    >
  </div>

  <fieldset>
    <legend>Preferred reply method</legend>

    <input
      type="radio"
      id="reply-email"
      name="reply_method"
      value="email"
      required
    >
    <label for="reply-email">Email</label>

    <input
      type="radio"
      id="reply-phone"
      name="reply_method"
      value="phone"
    >
    <label for="reply-phone">Phone</label>
  </fieldset>

  <div>
    <label for="message">Message (required)</label>
    <p id="message-hint">
      Do not include passwords or other sensitive information.
    </p>
    <textarea
      id="message"
      name="message"
      rows="8"
      aria-describedby="message-hint"
      required
    ></textarea>
  </div>

  <button type="submit">Send message</button>
</form>

CSS may change the presentation, but it should not remove labels, visible focus styles, error text, or the logical relationships expressed in the HTML.

How to test an accessible form

Automated accessibility tools can identify missing labels, duplicate IDs, low contrast, and some invalid ARIA relationships. They cannot determine whether every instruction is understandable, the focus order makes sense, or an error message genuinely helps someone recover.

Form testing should combine automated checks with direct interaction.

Test with a keyboard

1. Start before the form and use Tab to move through every control.
2. Confirm that the focus indicator remains visible.
3. Check that the focus order follows the form’s meaning.
4. Operate radio buttons, checkboxes, select menus, and buttons without a mouse.
5. Trigger validation errors and confirm that they can be found and corrected.
6. Open and close any dynamic sections.
7. Confirm that focus does not become trapped or unexpectedly disappear.

Inspect names and relationships

• Does every control have a meaningful accessible name?
• Do labels refer to unique IDs?
• Are hints and errors programmatically associated with their fields?
• Do fieldsets have useful legends?
• Are required and invalid states communicated without relying on color?
• Does the accessible name contain the visible label text?

Test with assistive technology

When possible, test representative workflows with screen readers, screen magnification, voice control, and mobile accessibility features. Testing with disabled users provides insight that automated rules and short technical checks cannot reproduce.

Form accessibility should also be reviewed across browsers and devices. Native controls and assistive technologies can behave differently, making browser interoperability part of practical accessibility work.

How accessible forms relate to WCAG

The Web Content Accessibility Guidelines address forms through several related requirements rather than one isolated “forms” rule. Relevant areas include:

• information and relationships conveyed programmatically;
• keyboard access and visible focus;
• headings and labels that describe purpose;
• instructions provided when input is required;
• error identification and correction suggestions;
• contrast for text, controls, states, and focus indicators;
• identification of common input purposes;
• prevention of redundant entry where applicable; and
• accessible authentication.

WCAG is most useful when understood as a foundation for human access rather than a final design checklist. See Understanding WCAG: A Foundation for Web Accessibility for broader context.

The W3C Web Accessibility Initiative also maintains detailed external guidance in its Forms Tutorial.

Accessible form checklist

• Use native HTML controls whenever they fit the interaction.
• Provide a persistent, meaningful label for every form control.
• Do not use placeholder text as the only label or instruction.
• Associate labels, hints, and errors programmatically with their controls.
• Use fieldsets and legends for related choices.
• Identify required fields before submission.
• Provide clear, specific error messages.
• Do not use color as the only indication of an error or state.
• Preserve valid information when validation fails.
• Maintain a logical keyboard and DOM order.
• Keep focus indicators visible.
• Use descriptive button text and explicit button types.
• Apply appropriate input types and autocomplete tokens.
• Support password managers, copy and paste, and accessible authentication.
• Announce dynamic updates only when the change would otherwise be missed.
• Test the complete task, not only the individual controls.

Accessible forms depend on clear relationships

The strongest accessible forms are often built from ordinary HTML used carefully. Labels name controls. Instructions explain requirements. Fieldsets establish groups. Buttons describe actions. Error messages help people recover. The document order preserves a predictable path through the task.

ARIA can clarify relationships that HTML does not express by itself, but it should support the structure rather than replace it. The broader goal is not to add accessibility after the form has been designed. It is to make the form understandable and operable from the beginning.

For related design guidance, see Form Design Best Practices: Clear, Accessible Web Forms. That broader design perspective and the technical structure covered here work together: a form needs both understandable interaction and dependable markup.