How to Build an Accessible Web Form with ARIA Labels

Imagine this: You’re on a website, trying to fill out a form. But you can’t see the screen. You rely entirely on a screen reader to tell you what each field is. Now imagine that same form has no labels… no hints… no guidance.

Scary, right?

This is what happens when web forms ignore accessibility — and millions of users face it every day. As responsible developers, we can fix this using a few simple attributes: ARIA labels.

Let’s make a world where everyone can fill a form — whether they can see it or not.

What are ARIA Labels?

ARIA stands for Accessible Rich Internet Applications. It’s a set of HTML attributes that helps assistive technologies — like screen readers — understand and interact with complex UIs.

Here are the three most common ARIA attributes used in forms:

Attribute	Purpose
aria-label	Provides an invisible label directly to an element
aria-labelledby	References another element’s ID to use as the label
aria-describedby	Adds extra help text by referencing an ID (for hints/instructions)

The Problem with Plain Forms

Here’s a basic (but broken) example:

<form>
  <input type="text" name="name" />
  <input type="email" name="email" />
  <button type="submit">Send</button>
</form>
Code language: HTML, XML (xml)

Looks fine, right?

But for screen readers, there’s no clue what each field is. It just says “edit, blank” with no context.

Let’s fix that — the accessible way.

Step-by-Step: Build an Accessible Form

Step 1: Add ARIA Labels

<form>
  <input type="text" name="name" aria-label="Full Name" />
  <input type="email" name="email" aria-label="Email Address" />
  <button type="submit">Send</button>
</form>
Code language: HTML, XML (xml)

Now, the screen reader will read “Full Name, edit” instead of just “edit.”

Step 2: Use aria-describedby for Helper Text

<label for="password">Password</label>
<input type="password" id="password" aria-describedby="passwordHelp" />
<small id="passwordHelp">Your password must be at least 8 characters long.</small>
Code language: HTML, XML (xml)

Now the screen reader will read the label, then the helper text.

Step 3: Group Related Inputs with fieldset and legend

<fieldset>
  <legend>Choose your gender</legend>
  <input type="radio" id="male" name="gender" value="male" />
  <label for="male">Male</label><br />
  
  <input type="radio" id="female" name="gender" value="female" />
  <label for="female">Female</label>
</fieldset>
Code language: HTML, XML (xml)

This improves screen reader flow and makes forms more understandable.

Step 4: Add Error Messages with ARIA Live

<div id="error" role="alert" aria-live="assertive" style="color: red;">
  Please enter a valid email.
</div>
Code language: HTML, XML (xml)

When the error appears, screen readers will immediately read it aloud.

Bonus: How to Test Your Form’s Accessibility

Here are some tools to check if your form is truly accessible:

• Google Lighthouse (Built into Chrome DevTools)
• axe DevTools (Browser extension)
• NVDA (Windows) or VoiceOver (Mac) — Real screen readers!
• Keyboard-only navigation — Try Tab, Enter, Space, Esc, and arrow keys only.

Try closing your eyes and filling the form with just a screen reader. You’ll instantly know what’s broken

Common Mistakes to Avoid

❌ Mistake	✅ Better Approach
Relying on placeholder as label	Use label tag or aria-label
Using aria-label when label exists	Prefer native <label> when possible
Forgetting to label buttons	Use aria-label like <button aria-label="Close popup">X</button>
Not testing keyboard navigation	Always test using only the keyboard

Conclusion: Accessibility is Deliciously Simple

Adding ARIA attributes may seem like extra work, but in reality — it takes just a few extra seconds and makes a world of difference for millions of users.

So next time you build a form — make it accessible. Not just because it’s the right thing to do… but because great devs build for everyone.

Download the Full Code Example