Accessible forms: labels, errors and buttons that work for everyone

A form is where a visitor becomes a customer, a subscriber or a patient. It is also where many websites quietly lose people. A field that only says what it wants until you start typing, an error shown only as a red border, a puzzle you cannot solve: each of these can stop someone from finishing. This article walks through what makes a form easy for everyone, including people who use a screen reader (software that reads the screen aloud), people who only use a keyboard, and people who find reading or remembering hard. You get short before-and-after code examples for your developer or AI builder, and checklists for a contact form, a checkout and a sign-up form.

Why forms go wrong so often

Forms are one of the most common problem areas on the web. In the WebAIM Million 2026, an automatic check of one million home pages, 51% of pages had form fields without a label. And that is only what a machine can find on a home page. Checkout and sign-up steps, where the stakes are higher, often have more.

The rules that most European accessibility laws build on are WCAG, the Web Content Accessibility Guidelines from the W3C. Several of their requirements are about forms: fields need labels or instructions, errors must be identified in text, and suggestions for fixing them should be given. The W3C’s forms tutorial covers them in detail. Below is the practical version.

Every field needs a visible label

A label is the text that says what a field is for: "Email address", "Postcode", "Message". It should be visible at all times, sit right next to the field, and be connected to it in the code, so a screen reader announces the label when someone lands in the field. A connected label has a bonus: clicking it puts the cursor in the field, which makes small checkboxes much easier to hit.

The most common mistake is using the placeholder (the grey hint text inside a field) as the only label. It disappears as soon as you type, so you cannot check what you were asked, it is often too pale to read, and some screen readers do not announce it. The Nielsen Norman Group lists these problems in its article on why placeholders are harmful.

<!-- Before: the hint disappears when you type, and nothing names the field -->
<input type="email" placeholder="Email address" />

<!-- After: a visible label, connected to the field through for and id -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email" />

If you need an example of the expected format, put it in a short help text under the label ("For example: 9000 Gent"), not only in the placeholder. Our repair guide on labels shows the fix step by step.

Group related choices

Radio buttons (round buttons where you choose one option) and groups of checkboxes need two kinds of label: one for each option, and one for the question as a whole. Without the question, a screen reader user may hear only "Yes, radio button, 1 of 2" and not know what they are saying yes to.

In code, the group is a fieldset and the question is its legend:

<!-- Before: the question is plain text, not linked to the options -->
<p>How should we contact you?</p>
<input type="radio" id="c-email" name="contact" /> <label for="c-email">Email</label>
<input type="radio" id="c-phone" name="contact" /> <label for="c-phone">Phone</label>

<!-- After: the options are grouped and the question names the group -->
<fieldset>
  <legend>How should we contact you?</legend>
  <input type="radio" id="c-email" name="contact" /> <label for="c-email">Email</label>
  <input type="radio" id="c-phone" name="contact" /> <label for="c-phone">Phone</label>
</fieldset>

The same goes for a date split into day, month and year fields, or an address block.

Required fields and instructions

Tell people before they start which fields they must fill in. Two common ways work well:

• Write "(required)" in the label of each required field. This is the clearest.
• Or use an asterisk (_) and explain it once at the top of the form: "Fields marked with _ are required."

Do not rely on colour alone, such as red labels for required fields: people who cannot tell colours apart will miss it. In the code, add the required attribute so screen readers announce "required" too.

Keep instructions short and put them before the field they are about, not after the submit button. A password rule like "At least 12 characters" belongs under the password label, where people see it before they type.

Ask only for what you need. Every extra field is one more chance for someone to give up. And do not make people type the same thing twice in one process: WCAG 2.2 added a requirement, Redundant Entry, that information already given should be filled in or offered for selection. A "Billing address same as delivery address" checkbox is the classic example.

Error messages that help people fix things

Everyone makes mistakes in forms. What matters is how quickly they can put them right. A good error message:

• Is written in text, not only shown as a red border or an icon. People who cannot tell certain colours apart may miss a red border, and screen readers do not announce colours at all.
• Sits next to the field it is about, so people can find it, and is connected to the field in code, so it is read aloud when someone returns to the field.
• Says how to fix the problem, not just that there is one. "Enter an email address in the format name@example.com" helps; "Invalid input" does not.
• Keeps what people already typed. Clearing the whole form after one error is a reason to leave.

For long forms, add a short summary at the top after submitting, listing each error as a link to its field, and move the keyboard focus (the place where typing goes) to that summary. The GOV.UK Design System shows a well-tested version of this pattern.

<!-- Before: only a red border, nothing a screen reader can announce -->
<input type="email" id="email" class="red-border" />

<!-- After: a text message, linked to the field -->
<label for="email">Email address</label>
<p id="email-error" class="error">Enter an email address in the format name@example.com</p>
<input
  type="email"
  id="email"
  name="email"
  autocomplete="email"
  aria-invalid="true"
  aria-describedby="email-error"
/>

aria-describedby connects the message to the field, and aria-invalid tells assistive technology the field needs attention.

Let browsers fill in the familiar parts

Browsers and password managers can fill in your name, address, email and phone number automatically, if the form tells them what each field is. That saves everyone typing, and it makes a real difference for people with motor impairments, memory difficulties or dyslexia. WCAG calls this Identify Input Purpose.

The autocomplete attribute does the job. Common values:

• name, or given-name and family-name for separate first and last name fields
• email and tel
• street-address, postal-code, address-level2 (the town or city) and country-name
• organization for a company name
• new-password on sign-up and current-password on log-in
• one-time-code for a code sent by text message

Use the matching field type as well: type="email" and type="tel" show the right keyboard on phones.

Buttons, keyboard use and security checks

Buttons that say what they do

The submit button should be a real button with a clear text: "Send message", "Place order", "Create account". Not "Submit", and never an unlabelled arrow icon. If a button only shows an icon, it needs a hidden name that a screen reader can announce.

<!-- Before: a clickable box with an icon, no name and no keyboard access -->
<div class="send" onclick="send()"><svg>...</svg></div>

<!-- After: a real button with a name -->
<button type="submit">Send message</button>

Our repair guide on button names covers icon buttons as well.

Everything works with a keyboard

Someone using only a keyboard should be able to reach every field with Tab, choose options with the arrow keys or Space, open custom dropdowns, and submit with Enter. Watch out for date pickers, custom dropdowns and "drag to upload" areas: they often only work with a mouse. Our 10-minute keyboard test shows how to check this yourself.

CAPTCHAs and their alternatives

A CAPTCHA is a test to prove you are not a robot: wavy letters to type, or photos to pick. For many people these are a wall. The W3C describes the problems in its note on the inaccessibility of CAPTCHA. WCAG 2.2 also added Accessible Authentication: logging in must not depend on remembering or retyping things, unless there is help such as allowing password managers and paste.

Gentler options to stop spam include invisible checks that run in the background, a hidden field that only robots fill in, and limiting how many messages one visitor can send. If you must use a visible test, offer more than one kind, such as an audio version next to a visual one. And never block pasting into password or code fields.

Time limits

If a form expires, people who read or type slowly may lose their work. WCAG’s Timing Adjustable asks that people can turn off or extend a time limit; a common way is a warning before time runs out, with at least 20 seconds to extend it in one simple action. Ticket sales and auctions can be exceptions.

Confirmation

After sending, show a clear message on screen, and make sure screen readers announce it too, for example by moving focus to it. For orders, bookings and anything with legal or financial consequences, let people review their answers before the final step, and say what happens next: "Thank you. We have sent a confirmation to name@example.com."

Checklists for common forms

Contact form

1. Every field has a visible label that stays when you type.
2. Required fields are marked in text, not only with colour.
3. Name, email and phone fields have the right autocomplete value.
4. Errors appear in text next to the field and explain the fix.
5. The button says "Send message" or similar.
6. Any spam protection works without solving a visual puzzle.
7. A confirmation appears and is announced after sending.

Checkout

1. The address fields use autocomplete, and "Same as delivery address" saves retyping.
2. Delivery and payment choices are grouped with a clear question.
3. Errors in the card or address fields are explained in words.
4. People can review the order before paying.
5. The final button says "Pay" or "Place order", not "Next".
6. Any time limit can be extended.
7. The confirmation page says what was ordered and what happens next.

Sign-up and log-in

1. Email and password fields have visible labels and the right autocomplete values.
2. Password rules are shown before typing.
3. Pasting and password managers work.
4. Codes sent by text or email can be pasted.
5. A button to show the password is a real button with a name.
6. Error messages say what is wrong without exposing which accounts exist.

What ibin can and cannot check in your forms

An automatic check can find fields without a label, buttons without a name and low-contrast text. ibin shows each one with a close-up picture of where it is and a repair guide, and a "Copy instructions for an AI tool" button gives you a ready prompt for Lovable, Bolt, v0 and similar tools. Automatic checks find roughly a third to half of all accessibility problems, though. Whether an error message is helpful, whether the steps make sense, or whether a CAPTCHA blocks people: that takes a person. Fill in your own form with the keyboard alone, make a mistake on purpose, and see what happens.

Check your forms

Check your contact page or checkout for free with ibin to find missing labels and nameless buttons. Then work through the checklists above and the repair guides. If you sign in, you can check up to 200 pages of the same site, and weekly checks tell you when a form change breaks something.

See how your own site does

Check a page for free, without an account. You get a plain list of what to fix first, with pictures of where each problem is.

Page address

Check this page

For example yourshop.com. One page takes about 20 seconds and it is free.