Accessible Forms

Ticketly loses a quarter of its customers at checkout, and the analytics can’t say why. Run the form with a screen reader and the reason is obvious: the fields announce “edit text, edit text, edit text”, the ticket-type radios announce “Standing, radio button” with no question, and when payment fails a red border appears that nobody without sight can perceive. Forms are where accessibility turns directly into money.

Every field gets a label

A <label> connected to an input does three things: it gives the field its accessible name, it shows sighted users what to type even after they start typing, and it makes the label text clickable, which enlarges the target.

<label for="full-name">Full name</label>
<input id="full-name" name="fullName" autocomplete="name">

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

Both forms work: for pointing at an id, or the input nested inside the label. You can confirm the link in the console: document.querySelector('#full-name').labels.length should be 1.

Group related choices

Radio buttons and checkboxes have two layers of meaning: each option, and the question they answer together. <fieldset> and <legend> carry the question:

<fieldset>
  <legend>Ticket type</legend>
  <label><input type="radio" name="ticket" value="standing"> Standing</label>
  <label><input type="radio" name="ticket" value="seated"> Seated</label>
  <label><input type="radio" name="ticket" value="vip"> VIP lounge</label>
</fieldset>

When focus enters the group, NVDA reads “Ticket type, grouping, Standing, radio button, not checked, 1 of 3”. Use the same pattern for a billing address block or a set of “notify me by” checkboxes.

Help people and browsers fill it in

Two attributes save a lot of typing, which matters most to people with motor or memory impairments.

The right type brings up the right keyboard on phones and gives basic validation: type="email", type="tel", inputmode="numeric" for a card number.

The autocomplete attribute declares what the field is for, so the browser can fill it from saved data. WCAG 1.3.5 Identify Input Purpose (AA) requires it for fields about the user. Common tokens: name, given-name, family-name, email, tel, street-address, postal-code, country, cc-name, cc-number, cc-exp, cc-csc, username, current-password, new-password.

Mark required fields with the required attribute, which screen readers announce, and with visible text such as “(required)”, not only an asterisk. And don’t ask twice: if the user typed their email at step 1, prefill it at step 3 (3.3.7 Redundant Entry).

Errors people can find and fix

This is where most forms fail. A good error has four parts, and the diagram shows how they connect:

1. Say which field is wrong, in text (3.3.1 Error Identification).
2. Say how to fix it (3.3.3 Error Suggestion): “Enter an email address like name@example.com”, not “Invalid input”.
3. Connect it programmatically: aria-invalid="true" on the field and aria-describedby pointing at the message.
4. Move focus to the first invalid field (or to an error summary at the top for long forms) so the user lands on the problem.

<label for="email">Email</label>
<input id="email" type="email" autocomplete="email" required>
<p id="email-error" class="error" hidden></p>

const form = document.querySelector('#checkout');
const email = form.querySelector('#email');
const error = form.querySelector('#email-error');

form.addEventListener('submit', (event) => {
  if (email.value.includes('@')) {
    email.removeAttribute('aria-invalid');
    email.removeAttribute('aria-describedby');
    error.hidden = true;
    return;
  }
  event.preventDefault();
  error.textContent = 'Enter an email address like name@example.com';
  error.hidden = false;
  email.setAttribute('aria-invalid', 'true');
  email.setAttribute('aria-describedby', 'email-error');
  email.focus();
});

The form uses novalidate in Ticketly’s markup (<form id="checkout" novalidate>) so this custom message replaces the browser’s built-in bubble, which varies between browsers and disappears quickly. That is a common choice; keeping native validation is also fine if you are happy with its messages.

For a long form with several errors, add an error summary at the top: a heading such as “There are 2 problems”, followed by a list of links, each pointing to the field it describes (<a href="#email">Enter an email address</a>). Move focus to the summary after a failed submit. Users hear how many problems there are, and each link takes them straight to a field.

Validate on submit or when the user leaves a field, not on every keystroke. Shouting “invalid email” while someone is still typing the first letters is noise for everyone and a flood of announcements for screen reader users.

Ticketly’s forms now speak clearly. The last piece of Section 2 covers content that isn’t text at all: images, icons and the data tables on the pricing page.