How do you build an accessible form?

HTMLAccessibility

The short answer

An accessible form has every field tied to a real label, groups related controls, and reports validation errors in a way assistive technology can announce. Most of this comes from using the right HTML: a <label> linked to its input, a <fieldset> around a group, and the required and type attributes. ARIA fills the small gaps, mainly for connecting error messages and marking invalid fields.

Associate a label with every field

The most important rule is that each input has a programmatic label, not just text near it. Associate them with matching for and id:

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

Now clicking the label focuses the input, and a screen reader announces "Email address" when the field gains focus. A placeholder is not a label: it disappears on input and is not reliably announced.

Use <fieldset> and <legend> to give a set of related inputs a shared name. This matters most for radio buttons and checkboxes, where each option needs the group's context:

<fieldset>
  <legend>Notification method</legend>
  <label>
    <input type="radio" name="notify" value="email" /> Email
  </label>
  <label>
    <input type="radio" name="notify" value="sms" /> SMS
  </label>
</fieldset>

The screen reader announces the legend with each option, so "Email, Notification method" is clear.

Report errors so they are announced

Three attributes connect a field to its error. aria-invalid marks the field as in error, aria-describedby points to the message, and a live region makes the message announce when it appears:

<label for="password">Password</label>
<input
  id="password"
  type="password"
  aria-invalid="true"
  aria-describedby="password-error"
/>
<p id="password-error" role="alert">
  Password must be at least 8 characters.
</p>

When focus lands on the field, the description is read along with the label. Insert or populate the error in response to validation, not at initial page load: a role="alert" region announces content that is added or changed after it is already in the page, so a message that is present when the page first loads is often not announced.

Let native validation help

The browser gives useful behavior for free. type selects the right keyboard and basic checks, and required marks a field as mandatory:

<input type="email" required />

Native constraints are exposed to assistive technology automatically, so lean on them before writing custom validation.

Interview Tip

If you remember one thing, make it the label association: every input needs a <label> connected by for and id, and a placeholder does not count. From there, build out the answer with <fieldset> and <legend> for groups, and the aria-invalid plus aria-describedby pairing for errors. Mentioning that native type and required are exposed to assistive technology for free shows you prefer the platform over reinventing it.

Why interviewers ask this

Forms are where accessibility has the highest stakes: sign up, checkout, and settings all depend on them, and a missing label or an unannounced error can block a user entirely. Interviewers want to see that you connect labels correctly, group related fields, and surface validation errors to assistive technology. It is a focused test of whether you can ship a form everyone can actually complete.

Table of Contents