WCAG 3.3.2 Labels or Instructions is a Level A success criterion that requires you to provide a label or instruction whenever content asks a user for input. In plain terms: every form field — a text box, dropdown, checkbox, or date picker, required or optional — must clearly tell the user what to enter before they type.
What 3.3.2 actually requires
The normative wording is short: “Labels or instructions are provided when content requires user input.” The W3C’s Understanding document explains the intent — to make sure people know what information is expected in each control so they can complete a form successfully.
Two things commonly trip people up:
- “Requires” does not mean “required field.” The W3C states plainly that the criterion applies to all form fields, optional ones included. The word “requires” refers to content that requires input, not to fields marked mandatory.
- 3.3.2 is about presence, not plumbing. This criterion only asks whether a label or instruction exists and is perceivable. Whether that label is correctly wired to the field in code is the job of 4.1.2 Name, Role, Value and 1.3.1 Info and Relationships. In real remediation you satisfy all three at once with a properly associated
<label>, which is why they’re easy to confuse.
A “label” can be text or an icon with a text alternative — a magnifying-glass icon can label a search field. An “instruction” is broader: a date-format hint, a password rule, or a sentence at the top of a form.
Who it affects
Clear labels disproportionately help people with cognitive, language, and learning disabilities, who the W3C names as primary beneficiaries — they rely on explicit guidance rather than inferring a field’s purpose from layout. But the impact is wider:
- Blind and low-vision users on screen readers (JAWS, NVDA, VoiceOver) hear nothing meaningful for an unlabeled box — often just “edit text” — and can’t tell a name field from an email field.
- Voice-control users (Dragon, Voice Control) target fields by their visible label. No label, no voice command.
- Everyone benefits from format instructions that prevent errors — a “MM/DD/YYYY” hint or a “minimum 8 characters” rule.
This is not a rare problem. In the 2026 WebAIM Million report, missing form input labels appeared on 51% of home pages analyzed, and 33.1% of all form inputs lacked a proper label — a defect WebAIM has flagged every year of the study.
Concrete failures and how to fix them
Placeholder text used as the only label
The single most common 3.3.2 failure. A placeholder looks like a label until the user clicks in and starts typing — then it disappears, taking the field’s purpose with it. Screen readers may skip it entirely.
<!-- FAILS 3.3.2: no persistent label -->
<input type="email" placeholder="Email address">
<!-- PASSES: visible, associated label; placeholder is an optional hint -->
<label for="email">Email address</label>
<input type="email" id="email" placeholder="you@example.com">Phone or date fields split into boxes with no text label
W3C failure F82 names this exactly: a phone number broken into three inputs surrounded by (, ), and - with no actual label. Sighted users guess from the punctuation; screen reader and voice users can’t. The F82 failure technique is the canonical citation here.
<!-- PASSES: group label via fieldset/legend, each part labeled -->
<fieldset>
<legend>Phone number</legend>
<label for="area">Area code</label>
<input id="area" type="text" inputmode="numeric" maxlength="3">
<label for="prefix">Prefix</label>
<input id="prefix" type="text" inputmode="numeric" maxlength="3">
<label for="line">Line number</label>
<input id="line" type="text" inputmode="numeric" maxlength="4">
</fieldset>A date field with no format instruction
A bare “Date of birth” box passes the label test but can still frustrate users who don’t know whether to type 06/29/2026 or 29/06/2026. The W3C technique G89: Providing expected data format and example closes that gap by describing the format in the label and offering a sample value:
<label for="dob">Date of birth (MM/DD/YYYY)</label>
<input id="dob" type="text" aria-describedby="dob-hint">
<span id="dob-hint">For example: 06/29/2026</span>“Name” instead of “Given name” and “Family name”
A single “Name” field is ambiguous across cultures and harder for cognitive-disability users. The Understanding document recommends separate, explicitly labeled fields. Small wording changes like this are pure 3.3.2 territory.
How to test for 3.3.2
You can audit most of this in minutes, but tools alone will not catch everything:
- Tab through every form. With your mouse aside, press Tab and confirm each field has a visible, persistent label — not just placeholder text that vanishes.
- Run a screen reader. Use NVDA (free) or VoiceOver to tab through the form. Each field should announce a clear name. “Edit text, blank” is a fail. See our screen readers guide.
- Delete the placeholders mentally. If removing placeholder text would leave a field unlabeled, it fails.
- Check format-sensitive fields. Dates, phone numbers, passwords, and ID numbers should carry a format hint or example.
- Scan, then verify by hand. Automated checkers flag missing
<label>associations well, but they can’t judge whether an instruction is clear or whether an icon-only label makes sense. Pair a scan with manual review.
For a deeper build-it-right walkthrough, our accessible forms guide covers labels, grouping, and error handling end to end, and ARIA labels and roles explains when aria-label is appropriate versus a visible <label>.
Why 3.3.2 matters legally
Forms are where transactions happen — checkout, contact, login, booking — so unlabeled fields don’t just annoy, they block people from buying or reaching you. That makes them a magnet for litigation.
Plaintiffs filed roughly 4,000+ digital accessibility lawsuits in 2024, per UsableNet’s 2024 year-end report, and unlabeled form fields are among the most frequently cited barriers because a tester can document them in seconds with a free screen reader — they simply tab to a box, hear “edit text, blank,” and screenshot it. That ease of proof matters: nearly two-thirds of those suits targeted companies with under $25 million in revenue, so the exposure isn’t limited to large brands.
The DOJ’s own web accessibility guidance points businesses to the Web Content Accessibility Guidelines as helpful technical guidance for meeting their ADA obligations, and in its 2024 Title II rule the Department formally adopted WCAG 2.1 Level AA as the standard for state and local government sites — which is why courts and plaintiffs routinely treat it as the practical reference point in private (Title III) cases too. As a Level A criterion, 3.3.2 sits below that AA bar, so a missing label is the cheapest barrier for a tester to find and the hardest defect to argue is a judgment call.
This is general information, not legal advice. Whether a specific unlabeled field creates ADA exposure depends on facts a qualified attorney should assess.
Fixing it the right way
The fix is almost always small, surgical code — a <label for="..."> tied to each input’s id, a <fieldset>/<legend> around grouped controls like the split phone field above, and a format hint wired with aria-describedby where one helps. It rarely touches your design.
This is exactly the kind of work an overlay widget can’t do, and 3.3.2 makes the reason concrete. A label isn’t a cosmetic layer you can paint on after the fact — it’s a relationship between two elements that has to exist in the DOM your form ships with. To author the correct <label>, an injected script would have to know that a given box collects an email rather than a coupon code, that “Name” should be split into given and family fields, or that a three-box phone group needs one <legend> — semantics only your team actually knows. So the overlay falls back to guessing from placeholder text (the very F82-style anti-pattern 3.3.2 exists to kill) or slapping a generic aria-label on whatever it finds, which can mislabel fields and make matters worse for the screen reader and voice-control users this criterion protects. That’s one of many reasons we’re anti-overlay: a guessed label is not a real one.
At Curbcut we add real, associated labels and instructions by hand, in your codebase, so the default form is conformant for everyone — not patched at runtime for some. Our accessibility audit finds every unlabeled and placeholder-only field, and our remediation service writes the <label>, <fieldset>, and format-hint code for each one. To see which of your fields fail 3.3.2 right now, start with a free scan and we’ll show you each box that announces as “edit text, blank” — and the exact markup that fixes it.