What 3.3.2 requires
Labels or instructions are provided when content requires user input.
People need to know what to type before they type it. A label names each field, and instructions give the format it takes, above all an unusual one or one with strict rules. Understanding 3.3.2 adds that “requires” here means accepts: optional fields need labels too.
The label has to be presented to everyone, not only to screen reader users. A field named in aria-label meets 4.1.2 and can still fail 3.3.2, because nothing on screen says what it is for. An icon can be the label when people widely understand it, as a magnifying glass is for a search box. Tying the label to its field in the markup is 1.3.1, and whether the label is clear is 2.4.6.
WCAG lists one failure: phone number fields set apart with punctuation and no text label (F82). The Understanding document also accepts invisible title labels on split phone fields under a visible “Phone number” legend, where what each field wants is plain on screen.
From the W3C
ACT rules for 3.3.2
No ACT rule covers 3.3.2 yet.
Common failures
Under each example: what axe-core and Rampa reported on the markup before the fix, in a run with Gemma 4 12B on 9 October 2026.
A field named only in aria-label
The newsletter form shows a heading and a button, and the field between them says nothing. Screen reader users hear “Email address”; everyone else has to guess from the button.
Before, fails 3.3.2
<h2>Brewing tips, once a month</h2>
<input id="newsletter" type="email" name="email"
aria-label="Email address"
autocomplete="email">
<button type="submit">Subscribe</button>After, passes
<h2>Brewing tips, once a month</h2>
<label for="newsletter">Email address</label>
<input id="newsletter" type="email" name="email"
autocomplete="email">
<button type="submit">Subscribe</button>- axe-core
Passes:
labelfinds an accessible name inaria-label.- Rampa
✗ #newsletter Nothing on screen tells what to enter in the field "Email address": its name is in aria-label, which only screen readers get. Evidence: "Email address" Patch: - <input id="newsletter" type="email" name="email" aria-label="Email address" autocomplete="email"> + <label for="newsletter">Email address</label> <input id="newsletter" type="email" name="email" aria-label="Email address" autocomplete="email"> confidence high · 1/1 runs · evidence verified · id a62e6272fc04
A label in a tooltip
The quantity box in the basket is named only in title, which shows as a tooltip when a mouse rests on it and not on a touch screen. On screen, it is a number next to a product.
Before, fails 3.3.2
<p>Ethiopia Yirgacheffe, whole bean, 250 g · £9.50</p>
<input id="qty-1" type="number" name="qty-1"
value="1" min="1" title="Quantity">After, passes
<p>Ethiopia Yirgacheffe, whole bean, 250 g · £9.50</p>
<label for="qty-1">Quantity</label>
<input id="qty-1" type="number" name="qty-1"
value="1" min="1">- axe-core
Passes:
labelaccepts a name fromtitle.- Rampa
✗ #qty-1 Nothing on screen tells what to enter in the field "Quantity": its name is in the title attribute, shown only as a tooltip. Evidence: "Quantity" Patch: - <input id="qty-1" type="number" name="qty-1" value="1" min="1" title="Quantity"> + <label for="qty-1">Quantity</label> <input id="qty-1" type="number" name="qty-1" value="1" min="1" title="Quantity"> confidence high · 1/1 runs · evidence verified · id 9313e75509a7
A format nobody explains
The gift card field only takes four capital letters, a hyphen and four digits, and nothing on screen says so: people find out from an error after they submit. A hint with an example, tied to the field, tells them first (technique G89).
Before, fails 3.3.2
<label for="gift-code">Gift card code</label>
<input id="gift-code" name="gift-code"
pattern="[A-Z]{4}-[0-9]{4}">After, passes
<label for="gift-code">Gift card code</label>
<input id="gift-code" name="gift-code"
pattern="[A-Z]{4}-[0-9]{4}"
aria-describedby="gift-code-hint">
<span id="gift-code-hint">For example, AURO-2024</span>- axe-core
Passes:
labelfinds the label, and no rule readspattern.- Rampa
✗ #gift-code The field "Gift card code" only accepts a set format (pattern="[A-Z]{4}-[0-9]{4}"), and nothing on screen explains it. Evidence: "Gift card code" Patch: - <input id="gift-code" name="gift-code" pattern="[A-Z]{4}-[0-9]{4}"> + <input id="gift-code" name="gift-code" pattern="[A-Z]{4}-[0-9]{4}" aria-describedby="gift-code-hint"> <span id="gift-code-hint">Four uppercase letters, a hyphen, and four digits (e.g., ABCD-1234)</span> confidence high · 1/1 runs · evidence verified · id ad77482a41b5
What axe-core checks
axe-core 4.14.0 maps one rule to 3.3.2: form-field-multiple-labels fails a field with more than one label element. Two rules mapped to 4.1.2 sit next to it: label fails a field with no accessible name, and select-name a select with none. Rampa runs all three and reports their failures as they are; a field they failed never goes to the model. The best practice label-title-only flags a field named only by title or aria-describedby, but Rampa runs only rules tagged with WCAG A and AA, so it is not part of a run.
| Rule | What it checks | Mapped to | In a Rampa run |
|---|---|---|---|
form-field-multiple-labels, rule page at Deque University | Form field must not have multiple label elements | 3.3.2 | runs |
label, rule page at Deque University | Form elements must have labels | 4.1.2 | runs |
select-name, rule page at Deque University | Select element must have an accessible name | 4.1.2 | runs |
label-title-only, rule page at Deque University | Form elements should have a visible label | best practice | not run: best practice |
No rule in a run asks whether the name is visible. A field named in aria-label or title, or by a label hidden with CSS, passes label, and no rule reads a pattern to see whether its format is explained.
Each rule links to its page at Deque University, which makes axe-core.
What Rampa judges, and how
What goes to the model
Two kinds of visible field that axe-core did not fail. A field whose name nobody sees: it comes from aria-label, title or a label hidden from view, and the field has no placeholder and, for a select, no option on show. And a field with a pattern. Buttons, checkboxes, radio buttons, file, range and color inputs, and hidden, disabled or read-only fields are left out.
What the model sees
- Where the name comes from:
aria-label, thetitleattribute, a hidden label, or a visible label. - The placeholder, or the option a
selectshows. - The
patternit enforces, if any. - The visible text just before and after the field, with the labels of other fields left out.
- The heading above it, the fieldset legend, and the buttons beside it, with whether they show text or only an icon.
- The page language, for writing out the format.
What it must answer
First, the visible text or icon that tells what to enter, and what the pattern requires in plain words; then a verdict, the problem (no visible label, or a format not explained), the field’s name copied as evidence, and a confidence.
What drops a claim
- The evidence is not the field’s name.
- A pass names a problem, or a fail names none.
- A missing label is claimed for a field the snapshot shows a visible label for, or whose name is on screen right beside it: a visible label not tied to the field still labels it, and the tie is 1.3.1.
- A missing label is claimed while the model quotes visible text that names the field.
- An unexplained format is claimed for a field without a
pattern, without saying what the pattern requires, or while a word on screen matches the pattern, since an example in the required format explains it.
The patch
Adds a visible label before an input, or, for a pattern, a hint after it tied with aria-describedby. A select or textarea gets no patch, since its start tag is not the whole element.
For every criterion
- Page content reaches the model marked as data, and the prompt tells it to ignore any instruction inside.
- Answers are cached by a hash of the prompt, the image, the model and its settings, so the same input never calls a model twice.
--runs 3asks three times and keeps the majority; when runs disagree, confidence drops. Findings below--min-confidence(medium by default) are hidden, and--verboselists them.- Claims dropped by verification are counted in every report, never shown as findings.
How Rampa was measured on it
No ACT rule covers 3.3.2, so no W3C test set measures it. The corrupted pairs below are its measurement.
Corrupted pairs: Rampa told 7 of 7 apart (labels moved off the screen), axe-core 0. A pair is a passing test page and a copy broken on purpose; a checker that gives both the same verdict is not judging.
Run on 9 October 2026: axe-core 4.14.0, Gemma 4 12B on a local GPU, reasoning off, one run, ACT test cases a9a1483e. Small samples and one run: read the numbers as a working pipeline, not as a result.
Read with these caveats
- The pairs take the passing pages of ACT rule cc0f0a, where every field has a visible label, and move each label into
aria-label. - The intact pages give the module no candidates, so the pairs test the corruption, not false positives. Example pages in the repository cover the pattern rule and a search box with an icon button.
Limitations
- A field labeled only by its placeholder is not reported: the WAI forms tutorial advises against it, but the Understanding document does not call it a failure.
- The Understanding document accepts invisible
titlelabels on split phone fields under a visible “Phone number” legend. The prompt tells the model that a group name over several fields names a section, not each field, so such fields may be reported. - Icons drawn with CSS pseudo-elements are not in the snapshot, so the model cannot see them.
- On 13 public pages it found no false positives once a select showing “English” beside a globe icon was taken out of scope, and few candidates at all, since most fields there have visible labels or placeholders.
- It judges web pages only.
Questions about 3.3.2
Is aria-label enough to meet WCAG 3.3.2?
No. aria-label gives the field an accessible name, which meets 4.1.2, but nothing shows on screen. The Understanding document says the labels or instructions must be presented to all users, not only to those using assistive technologies.
Is a placeholder a label?
The Understanding document does not call a field labeled only by its placeholder a 3.3.2 failure, so Rampa does not report one. The WAI forms tutorial advises against it: the hint disappears as soon as people type.
Does an icon count as a label?
It can. The Understanding document gives the example of a search box with a magnifying glass button, an icon people widely understand. Rampa tells the model so, and lists the buttons beside a field with whether they show text or only an icon.
Does 3.3.2 apply to optional fields?
Yes. The Understanding document says “requires” in the criterion means accepts, expects or allows, so every form field needs a label or instructions.
Does axe-core check 3.3.2?
One rule is mapped to it, form-field-multiple-labels. label and select-name, mapped to 4.1.2, check that a field has a name, and accept one that nobody sees.
Check your pages
Rampa is not on npm yet. Clone it and run it from source with Node.js 22.12 or newer and Chrome or Edge. --criteria 3.3.2 judges only this criterion; leave it out to run the eight that run by default.
With Ollama running, Rampa picks a local model by itself; node dist/cli.mjs doctor says what is missing.
git clone https://github.com/guilhermebsantiago/rampa-cli.git
cd rampa-cli
pnpm install && pnpm build
node dist/cli.mjs check https://example.com --criteria 3.3.2Checked against rampa-cli (commit 0459809) and the W3C sources on 9 October 2026.