Accessible Forms

Understanding Accessible Forms

Accessible forms clearly identify each control, explain what information is required, provide understandable instructions and errors, and remain usable with different input methods and assistive technologies.

HTML includes built-in elements and attributes for creating accessible forms. Using native controls, properly associated labels, meaningful grouping, clear instructions, and understandable validation messages gives browsers and assistive technologies the information needed to present a form effectively.

Use Native Form Controls

Native HTML form elements such as <input>, <select>, <textarea>, and <button> include built-in semantics and keyboard behavior that browsers and assistive technologies already understand.

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

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

Avoid recreating ordinary form controls with generic elements such as <div> or <span> when a native HTML control already provides the required behavior.

Label Form Controls

Most form controls need a visible label that clearly describes the information the visitor should enter or select. A label can be explicitly associated with a control by matching the label's for attribute with the control's id.

<label for="first-name">First Name</label>
<input type="text" id="first-name" name="first-name">

This association allows assistive technology to identify the control by its label. It also makes the label itself clickable, which can make small controls such as checkboxes and radio buttons easier to activate.

Labels for Checkboxes and Radio Buttons

Checkboxes and radio buttons should also have labels that explain each choice.

<input type="checkbox" id="newsletter" name="newsletter">
<label for="newsletter">Subscribe to the gardening newsletter</label>

Do Not Replace Labels with Placeholder Text

The placeholder attribute can provide a short example or hint inside an input, but it should not normally replace a visible label.

<label for="phone">Phone Number</label>
<input type="tel" id="phone" name="phone" placeholder="555-123-4567">

Placeholder text disappears when a visitor begins typing and may be difficult to see depending on its styling. Keeping the label visible ensures the purpose of the field remains available while the form is being completed or reviewed.

Identify Required Fields

Visitors should be able to determine which fields must be completed before submitting a form. The HTML required attribute identifies a control that requires a value.

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

The visible label or nearby instructions should also explain that the field is required rather than relying only on color, an icon, or another visual treatment.

If an asterisk is used to identify required fields, explain its meaning before the form, such as Fields marked with an * are required.

Provide Instructions and Help

When a field requires a particular format or has special requirements, provide the instructions before the visitor is expected to submit the form.

<label for="password">Password</label>
<p id="password-help">Use at least 12 characters.</p>
<input type="password" id="password" name="password" aria-describedby="password-help">

The aria-describedby attribute can associate additional explanatory text with a form control when native labeling alone does not communicate all of the necessary information.

ARIA should supplement appropriate HTML rather than replace a native <label> when one can be used.

Group Related Controls

Use <fieldset> and <legend> when several controls belong to the same question or group. This is especially useful for sets of radio buttons and related checkboxes.

<fieldset>
  <legend>Preferred Contact Method</legend>

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

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

The <legend> describes the purpose of the entire group, while each individual control still has its own label.

Choose Appropriate Input Types

Choose an HTML input type that matches the information being requested. Appropriate types can provide useful browser behavior, validation, and more suitable controls on touchscreen devices.

Use the input type that represents the expected value rather than using type="text" for every field.

Form Errors and Validation

When form validation fails, visitors should be told what went wrong and how to correct it. Do not rely only on changing a field's border or text color to indicate an error.

An effective error message identifies the affected field and explains the problem:

<label for="email">Email Address</label>
<input type="email" id="email" name="email" aria-describedby="email-error">
<p id="email-error">Enter an email address in the format name@example.com.</p>

For longer forms, an error summary near the beginning of the form can help visitors understand which fields need attention. Whenever possible, preserve values that were entered correctly so visitors do not have to complete the entire form again.

Do Not Depend on Color Alone

Color can reinforce an error state, but it should not be the only indication that something is wrong. Combine visual styling with text that clearly explains the error.

Keyboard Access

Form controls should be usable without a mouse. Native HTML controls normally participate in keyboard navigation automatically, allowing visitors to move through interactive elements and operate them using familiar keyboard commands.

Avoid using positive tabindex values such as tabindex="1" or tabindex="2" to manually create a tab sequence. In most cases, placing form controls in a logical HTML source order produces the most predictable keyboard order.

Visible focus indicators should also remain available so keyboard users can see which control is currently active. Keyboard navigation and focus behavior are covered in greater detail in the following tutorials.

Accessible Form Example

The following example combines visible labels, required-field information, related controls, descriptive help text, and native HTML form elements.

<form action="/contact-response.php" method="post">
  <p>Fields marked with an * are required.</p>

  <label for="name">Name *</label>
  <input type="text" id="name" name="name" required>

  <label for="email">Email Address *</label>
  <input type="email" id="email" name="email" required>

  <fieldset>
    <legend>Preferred Contact Method</legend>

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

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

  <label for="message">Message *</label>
  <textarea id="message" name="message" rows="6" required></textarea>

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

Try changing the labels, removing a label association, or adding another form control. Check whether the purpose of every field remains clear and whether the controls follow a logical order.

Best Practices

• Use native HTML form controls whenever they provide the required behavior.
• Give form controls clear visible labels.
• Associate each <label> with its control using matching for and id values.
• Do not use placeholder text as a substitute for a visible label.
• Clearly identify required fields and explain any symbols used to mark them.
• Provide instructions before visitors encounter fields with special requirements.
• Use <fieldset> and <legend> to identify groups of related controls when appropriate.
• Choose input types that match the information being requested.
• Write validation messages that identify the problem and explain how to correct it.
• Do not communicate required fields or errors through color alone.
• Keep controls in a logical source order and avoid unnecessary positive tabindex values.
• Preserve visible keyboard focus indicators.

Summary

Accessible forms use meaningful HTML to communicate the purpose, requirements, and relationships of form controls. Native controls, visible labels, appropriate input types, fieldsets, legends, and clear instructions provide a strong accessibility foundation.

Forms should also remain understandable when something goes wrong. Clear validation messages, logical keyboard navigation, visible focus, and information that does not depend on color alone help more visitors complete forms successfully.