Form Labels: Clear Labels and Instructions
Also called: Field labels, Input labels, Labels or instructions
Definition
Form labels are the visible texts that name what a form field expects, such as “Email address”. WCAG 3.3.2 requires labels or instructions wherever content asks for user input, including formats and required fields.
Form labels are the short texts next to a field that say what belongs in it: "First name", "Email address", "Date of birth (DD.MM.YYYY)". They are the difference between a form people fill in once and one they abandon after the third error. Good form labels are visible to everyone and connected to their field in the code, so screen readers announce them too.
What it means
WCAG 3.3.2 Labels or Instructions (Level A, WCAG 2.2) says: "Labels or instructions are provided when content requires user input." W3C reads "requires" as "accepts or expects", so the rule covers every field, not only the mandatory ones. Instructions should also explain unusual formats and which fields are required.
Each option in a group needs a label too: every radio button, every checkbox. W3C also warns against the opposite – so much text that the form becomes hard to use.
| Situation | Verdict |
|---|---|
Visible <label> linked with for/id (H44) |
Passes 3.3.2 and gives the field its accessible name |
| Date field with "DD.MM.YYYY" next to it (G89) | Passes – the format is explained |
Radio group with <fieldset> and <legend> (H71) |
Passes – the question and each option are labeled |
Name only in aria-label, nothing visible |
Can pass 4.1.2, but W3C says it can still fail 3.3.2 |
| Three phone-number boxes without text (F82) | Fails – layout and punctuation are not a label |
3.3.2 is about whether a label exists and is visible. Whether it is correctly connected in the code is covered by 1.3.1 and 4.1.2 – the topic of a missing form label.
Examples
<!-- Good: visible label, linked, with format hint -->
<label for="dob">Date of birth</label>
<input id="dob" name="dob" aria-describedby="dob-hint" required>
<p id="dob-hint">Format: DD.MM.YYYY</p>
<!-- Good: group of options -->
<fieldset>
<legend>Delivery</legend>
<input type="radio" id="std" name="ship"><label for="std">Standard (3–5 days)</label>
<input type="radio" id="exp" name="ship"><label for="exp">Express (1 day)</label>
</fieldset>
<!-- Bad: placeholder only -->
<input type="email" placeholder="Email">Place a visible label above or beside every field and link it with for and id. Mark required fields in the label ("Email (required)"), explain formats before the user types and group related options with fieldset and legend.
Rely on placeholders, icons or layout alone, hide all labels for a cleaner design, write vague labels such as "Field 1", or put long instructions at the end of the form where nobody reads them before typing.
How to check form labels
Questions
Can a placeholder replace a form label?
No. A placeholder vanishes as soon as someone starts typing, so users lose the information while they need it. Keep a visible label and use the placeholder only for an example, if at all.
Do hidden labels meet WCAG?
A label that only screen readers get, such as aria-label, can give a field its accessible name for 4.1.2. W3C notes it can still fail 3.3.2, because sighted users do not see it. A visible search field with a clear search button is a common, accepted case.
How do I mark required fields accessibly?
Say it in text, for example "(required)" in the label or an explanation at the start of the form, and add the required attribute so screen readers announce it. An asterisk alone needs that explanation.
Where should form labels go?
W3C technique G162 recommends predictable positions: above or to the left of text fields, and to the right of checkboxes and radio buttons. That keeps label and field clearly together, also when zoomed in.
Can allyWay fix form labels automatically?
Yes. allyWay finds fields without labels and gives them labels written by AI from your page content, so every form can be filled in. The automatic accessibility fixes are applied by the allyWay script; fixes that change what visitors see only go live after your approval, and every fix is logged. Start for free and make your forms usable for screen reader users.
Related terms
Missing Form Label: Error Explained and Fixed
A missing form label means an input field, checkbox, select or textarea has no programmatically associated label or other accessible name. Screen readers announce only the field type, so users do not know what to enter.
Read definition: Missing Form Label: Error Explained and FixedAccessible Name: What It Is and How It Is Computed
The accessible name is the text that browsers pass to assistive technology to identify an element – for example the words a screen reader announces for a button, link or form field. WCAG 4.1.2 requires a programmatically determinable name for every user interface component.
Read definition: Accessible Name: What It Is and How It Is Computedaria-label: How to Name Elements Correctly
aria-label is an ARIA attribute that sets the accessible name of an element as a text string. Screen readers announce this name instead of the element's content, so it is used mainly for controls without visible text, such as icon buttons.
Read definition: aria-label: How to Name Elements CorrectlyARIA Live Regions: Announce Status Messages
An ARIA live region is a part of the page marked with aria-live or a live role such as status or alert. When its content changes, screen readers announce the new text without the user having to move focus to it.
Read definition: ARIA Live Regions: Announce Status Messages