accessibility

Accessible forms (labels and instructions)

By Chris Daniels, UX designer & frontend developer Published 25 July 2026

What makes a form accessible to screen-reader users?

An accessible form gives every control a real, programmatically-associated label and clear instructions, so a screen-reader user hears what each field is for before they fill it in. Without that, the form may look fine but announces as a row of nameless "edit text" boxes - usable by sight, a guessing game by ear.

Also known as: accessible forms, form labels, form accessibility, labels and instructions

Prefer to watch? Watch the recap 0:49

The demo

Focus each field below and read what a screen reader would say. Flip the labels off, and listen to the same form become a row of nameless boxes.

What this demo shows (text version)

A short sign-up form (full name, email, and a "how did you hear about us" dropdown) can be shown with or without proper labels. As you focus each field, a panel reports what a screen reader would announce. With labels off, the fields announce only their type - "edit text", "combo box" - with no name, so a screen-reader user has no idea what to type where. With proper labels on, each announces its name and type, like "Email address, edit text".

The inputs are identical; only whether their names are exposed to assistive technology changes. That's the heart of accessible forms: every control needs a real, associated label (a placeholder doesn't count), instructions linked to the field, required state stated in words, and errors tied back to the input. The test is whether the form could be completed by ear alone.

Every input needs a proper tied to it (or an equivalent accessible name) - a placeholder is not a label, and a visually-styled caption that isn't associated is invisible to assistive tech. Put instructions and formats in the label or in text linked to the field, mark required fields in words, and tie error messages to the input. A form that's only usable if you can see it is broken for everyone who can't.

The foundation is a real, associated label for every control - a bound to the input's id, or an equivalent like aria-label where a visible label truly can't exist. A placeholder doesn't count: it's low-contrast, vanishes on typing, and is unreliably announced. A caption that merely sits near the field, without association, is decoration as far as a screen reader is concerned.

Instructions and constraints have to be perceivable too. Put format hints ("DD/MM/YYYY"), requirements and examples in the label or in text linked with aria-describedby, so they're announced with the field rather than floating nearby. Mark required fields with the word "required", not colour or an asterisk alone, and group related controls (radios, checkboxes) under a fieldset and legend.

Errors must connect to their cause. Announce them, tie each message to its input, name the field and say how to fix it - "Email address: enter a valid address" - rather than a generic banner a screen-reader user can't map back to a control. The whole test is simple: could you complete this form with your eyes closed, by ear alone?