Texas Tech University

Accessible Forms

Quick Start: What You Need to Know

Forms are interaction points. If a user cannot identify what information is requested or how to fix an error, they cannot complete the task. Accessible forms rely on explicit labels programmatically linked to their inputs.

Immediate Actions:

  • Every input needs a <label> element
  • Connect labels to inputs using for and id attributes
  • Never use placeholder text as a replacement for a label
  • Group related checkboxes and radio buttons with <fieldset> and <legend>
  • Ensure error messages are text-based, not just color (e.g., don't just turn the border red)
  • Use standard HTML input types (e.g., type="email", type="tel") to trigger mobile keyboards

Why This Matters

When a screen reader user navigates to a form field (like a text box), the screen reader announces the field's "Accessible Name." This name usually comes from the <label> tag.

  • With a label: The user hears "First Name, edit text." They know exactly what to type.
  • Without a label: The user hears "Edit text." They have to guess what information is required based on surrounding text, which is often skipped in navigation.

Furthermore, clicking a <label> focuses its associated input, creating a larger click target for users with motor disabilities.

What to Look For: Detailed Checklist

Form Structure

Every form field (text inputs, dropdowns, textareas) must have a visible label that is programmatically associated with it.

The Rule: The for attribute on the label must match the id attribute on the input exactly.

Example:<label for="fname">Name</label> connects to <input id="fname">.

Placeholders (the grey text inside a box) disappear as soon as the user starts typing. This creates major accessibility issues:

  • Memory: Users with cognitive disabilities may forget what the field was for once the text vanishes.
  • Contrast: Default placeholder text often fails color contrast requirements.
  • Support: Some older screen readers do not read placeholders reliably.

When you have a group of related choices (like "Choose your shipping method"), individual labels aren't enough. You need a container that groups them together.

The Solution: Wrap the group in a <fieldset> tag and use a <legend> tag for the main question.

If a user makes a mistake, they need to know where the error is and how to fix it.

  • Don't rely on color alone (e.g., "Fields in red are required").
  • Provide text instructions (e.g., "Error: Email address is missing the @ symbol").
  • Ideally, link the error message to the field using aria-describedby.

Use the autocomplete attribute on common fields (name, email, address). This allows the browser to autofill the information, which helps users with motor disabilities type less and users with cognitive disabilities ensure accuracy.

Example:autocomplete="email" or autocomplete="tel"

Code Examples & Best Practices

Basic Text Input

Bad Example: Placeholder only

<!-- Visual only, no accessible name -->
<input type="text" placeholder="Enter your email">
A screen reader might just say "Edit text." Once the user types, the instruction "Enter your email" is gone visually.

Good Example: Explicit Label

<label for="email-addr">Email Address</label>
<input type="email" id="email-addr" autocomplete="email">
The label is permanently visible. Clicking the label focuses the input. Screen readers announce "Email Address, edit text."

Radio Buttons (Grouping)

Bad Example: Loose inputs

<p>Select your preferred contact method:</p>
<input type="radio" name="contact"> Email <br>
<input type="radio" name="contact"> Phone
A screen reader user tabbing into "Phone" might just hear "Phone, radio button not checked." They might miss the context question "Select your preferred contact method."

Good Example: Fieldset and Legend

<fieldset>
  <legend>Select your preferred contact method:</legend>
  
  <input type="radio" id="c-email" name="contact" value="email">
  <label for="c-email">Email</label><br>

  <input type="radio" id="c-phone" name="contact" value="phone">
  <label for="c-phone">Phone</label>
</fieldset>
When the user enters this group, the screen reader announces the legend ("Select your preferred contact method") before reading the specific option.

WCAG 2.1 Success Criteria Summary

The following WCAG 2.1 Level A and AA success criteria apply to forms:

1.3.1 Info and Relationships Level A

Information, structure, and relationships conveyed through presentation can be programmatically determined. This requires grouping related controls (like radio buttons) with fieldsets.

1.3.5 Identify Input Purpose Level AA

The purpose of each input field collecting information about the user can be programmatically determined (using autocomplete attributes).

3.3.2 Labels or Instructions Level A

Labels or instructions are provided when content requires user input. These labels must be clear and visible.

4.1.2 Name, Role, Value Level A

For all user interface components (forms), the name and role can be programmatically determined. This is achieved by properly linking <label> elements to inputs.

Real-World Impact: Why This Matters

The "Mystery Input" Game
Navigating without vision

A Texas Tech staff member who is blind is trying to register for a professional development workshop. He tabs through the registration form using his screen reader.

The first three fields announce clearly: "First Name," "Last Name," "R number." Then he hits a field where the screen reader simply says "Edit text."

He pauses. Is this for his email? His department code? His dietary restrictions? He explores the text around the box, but the developer used a visual layout table where the label "Department Code" is in a cell that isn't programmatically associated with the input. He has to guess, fill it out, and hope the form doesn't reject his submission.

The Disappearing Instruction
Cognitive load and placeholders

A student with a cognitive processing disorder is filling out a complex financial aid appeal. One field has a light grey instruction inside the box that says "Enter your adjusted gross income from line 11 of your 1040 tax return."

As soon as she clicks the box and types the first digit, the instruction disappears.

She stops to double-check her tax form, looks back at the screen, and the instruction is gone. She has to delete what she typed just to read the instruction again, then re-type it. This cycle of typing and deleting increases anxiety and the likelihood of error. If a permanent label had been used, the instruction would have remained visible.

Additional Resources

WCAG Guidelines and Understanding Documents

Testing Tools

Resources

Student Disability Services

Support and Accommodations

Human Resources (ADA)

Workplace accommodations and compliance

Contact Us

Reach out to our accessibility team

Report a Barrier

Encountered an issue? Let us know!

Digital Accessibility

© 2025  Texas Tech University Nov 25, 2025 11:33 AM