Which fields on your form have no label?

This is the accessibility failure that costs you the sale

Most automated accessibility findings make a page worse to use. A thin contrast ratio is tiring; a missing heading level is disorienting; a decorative image with no alt is noise. An unlabelled form field is different in kind, because it is the point where the visitor was about to give you something. A screen reader reaches it and announces “edit, blank”. There is nothing to guess from, no hint that survives the first keystroke, and no way to check the answer before submitting. The person does not file a complaint about it. They leave, and you record an abandoned checkout with no cause attached.

It is also, unusually, cheap to fix. Nearly every repeated failure on a real site traces back to one input component used everywhere — a design-system field that accepts a placeholder prop and never took a label one. Fixing it where it is defined repairs every form on the site in a single change, which is why this is worth reading before the harder criteria.

What the checker looks for

Four of these are failures with a named criterion. The rest are judgement calls a machine can surface but cannot settle, so they are reported separately and never counted as violations — a checker that inflates its own failure count is selling you something.

Form control with no accessible name at allFailureWCAG 2.1 SC 3.3.2 Labels or Instructions / SC 4.1.2 Name, Role, Value (Level A)

There is no <label> bound to it, no aria-label, no aria-labelledby, no wrapping label and no title. A screen reader announces the role and stops — “edit, blank” — so the person filling the form is told a box exists and never told what belongs in it. On a checkout or a contact form this is the failure that costs the transaction, not just the audit.

The fix: Give it a visible <label for="…"> whose for matches the control's id. That is the version everyone benefits from, including sighted people on a phone. Use aria-label only where a visible label genuinely cannot exist, such as a search box whose button already says Search.

Named only by its placeholderFailureWCAG 2.1 SC 3.3.2 Labels or Instructions (Level A)

The placeholder is doing the label's job. Two things go wrong: it disappears the moment someone types, so anyone who is interrupted, reviewing their answers or using voice input has no way back to what the field wanted; and placeholder text is rendered at a low contrast by default in every browser, so it frequently fails SC 1.4.3 as well. Support for announcing it at all varies by screen reader — it is a hint, not a name.

The fix: Add a real label and keep the placeholder for the example value if you want one: label “Card number”, placeholder “4242 4242 4242 4242”. If the design has no room for a label, the design has no room for the field.

Button with nothing to announceFailureWCAG 2.1 SC 4.1.2 Name, Role, Value (Level A)

The button has no text inside it, no aria-label and no title. Icon-only buttons are where this lives — a hamburger menu, a close X drawn in SVG, a magnifier that submits the search. A screen reader announces “button” and the listener has to activate it to find out what it does.

The fix: Add aria-label="Close" (or Search, or Menu) to the button itself, or put visually-hidden text inside it. Do not put the label on the SVG and hope: give the button the name.

Label pointing at an id that does not existFailureWCAG 2.1 SC 1.3.1 Info and Relationships (Level A)

A <label for="…"> names an element this page never renders — usually a renamed field, a copy-pasted block or a component that generates its ids at runtime. It looks correct in the design and it is inert in the accessibility tree: the label announces nothing, the control it was meant for is unnamed, and clicking the label does not focus anything.

The fix: Match the for attribute to the control's real id, or wrap the control in the label so the relationship cannot drift. If the id is generated, generate the for from the same value.

Named only by a title attributeReviewWCAG 2.1 SC 3.3.2 Labels or Instructions (Level A)

Most screen readers do fall back to title when nothing else names a control, so this is usually announced — which is why it sits in review rather than in the failure count. It is still the weakest option available: a title never appears for a touch user, appears only on hover for a mouse user, and several testing tools flag it on its own.

The fix: Promote it to a real label. The text is already written; it just needs to be in a <label> rather than an attribute.

Personal-data field with no autocomplete attributeReviewWCAG 2.1 SC 1.3.5 Identify Input Purpose (Level AA)

The field is named and works, and its name or type says it collects something about the person filling it in — email, phone, name, address, postcode or card. Level AA asks those to carry the matching autocomplete token so that browsers, password managers and assistive tools can fill and label them programmatically. This one is matched by shape, so read it as a prompt rather than a verdict.

The fix: Add the token from the HTML spec's list: autocomplete="email", "tel", "given-name", "postal-code", "cc-number". It also measurably raises completion on mobile forms, which is the argument that tends to get it shipped.

Two controls sharing one idReviewWCAG 2.1 SC 4.1.1 Parsing / SC 1.3.1 (Level A)

The id on this control appears more than once in the document — a repeated component, a form rendered twice, or a modal that duplicates the page's own form. Any label pointing at that id binds to whichever one the browser finds first, so at least one of the copies is silently unnamed even though the markup looks complete.

The fix: Make ids unique per render. If a component can appear twice on a page, it has to take its id from a prop or a generated suffix rather than hard-coding one.

Named by aria-label, with no visible labelVerify

This is valid markup and not a violation — a screen reader announces the name. It is listed because it is where two real failures hide. First, a sighted person with a memory or attention difficulty gets no on-screen text at all, which is what SC 3.3.2 is for. Second, if there IS visible text near the control that differs from the aria-label, voice-control users who say what they see cannot operate it (SC 2.5.3 Label in Name).

The fix: Skim the list. Anything a person has to think about before answering deserves a visible label; keep aria-label for controls whose purpose is already obvious on screen.

The five ways a control can get a name, in the order to prefer them

A screen reader resolves the accessible name by walking a list. Knowing the list is most of the fix, because the argument on a design team is almost never “should this be accessible” — it is “where do we put the words”.

1. A visible <label for> bound by id. Everyone benefits, including a sighted person on a phone, and the label doubles the tap target because clicking it focuses the field. This is the answer unless there is a reason it cannot be.
2. A label wrapping the control. Same result with no id to keep in sync, which makes it the safer option inside a component that can render twice on one page.
3. aria-labelledby pointing at text already on the page — a section heading above a group of fields, for instance. Nothing is duplicated and nothing can drift out of step.
4. aria-label, for the narrow case where a visible label genuinely would be redundant: a search box sitting beside a button that says Search. Keep the text matching what is on screen.
5. A title attribute, which is the fallback of last resort. It is announced by most screen readers and by nothing else — no touch user ever sees it. If you are reaching for it, the words exist; put them in a label.

A placeholder is not on that list. It is a hint about the format of the value, it is not part of the accessible name computation in any reliable way, and it is gone as soon as the field has content.

Common questions

What does this checker actually read?

One URL, once. It fetches the page you enter, takes the HTML your server returns, and walks every <input>, <select>, <textarea> and <button> in it. For each one it asks the same question a screen reader asks: is there an accessible name here, and where does it come from — a bound <label>, a label wrapped around it, aria-label, aria-labelledby, the button's own text, or nothing. It does not render the page, run your JavaScript or crawl beyond the address you typed; all three of those are the full scan, which is a different tool on this site and also free.

Is a placeholder a label?

No, and this is the single most common disagreement people have with the result. A placeholder is a hint, not a name. It disappears the instant someone types, so anyone who is interrupted, reviewing their answers, using voice input or coming back to a half-filled form has no way to recover what the field wanted. Browsers render it at a low contrast by default, so it usually fails SC 1.4.3 as well, and whether a screen reader announces it at all varies by product. Keep the placeholder for an example value if you want one — label “Card number”, placeholder “4242 4242 4242 4242” — but the label has to exist.

Our inputs use aria-label. Does this count that as a pass?

Yes. aria-label is a real accessible name and this tool never counts it as a violation. It does list those controls separately, in a verify band, for two reasons worth a minute of your time. A sighted person with a memory or attention difficulty gets no on-screen text at all, which is exactly what SC 3.3.2 exists for. And if there is visible text near the control that differs from the aria-label, voice-control users who say what they see cannot operate it — that is SC 2.5.3, Label in Name, and it is a level A failure hiding behind correct-looking markup.

Why is my submit button not flagged when it has no text?

Because <input type="submit"> and <input type="reset"> carry a browser-supplied default name even with no value attribute — a screen reader announces “Submit” — so calling them failures would be wrong. <button> is different: it takes its name from its own content, so an icon-only button with an SVG inside and no aria-label genuinely has nothing to announce, and that one is reported. A button named by a nested image's alt text or by visually-hidden span text passes.

It found nothing, but my page has a form. What happened?

Almost always client-side rendering. If the form is built by React, Vue or an embedded widget after the document arrives, it is not in the HTML your server sent and this reader cannot see it — same limitation as the alt text checker and the overlay checker on this site, and the same honest answer. The free scan renders each page in a real browser before measuring it, so it sees what your visitors see. Run that one instead. It is also worth checking a page that actually carries the form: home pages often have nothing but a newsletter box, while the failures live on contact, signup and checkout.

How much does this failure class actually matter?

Of the automated failures, this is the one that costs money rather than goodwill. A missing alt attribute makes a page worse to use; an unlabelled payment field makes it impossible to complete, and the person leaves without telling you why. WebAIM's annual survey of the top million home pages has found missing input labels on a large share of every page carrying a form, every year it has run — which also means the problem is routine rather than exotic, and usually one component away from fixed.

Does the autocomplete finding mean I am failing WCAG?

It means you might be, and it is deliberately in the review band rather than the failure count. SC 1.3.5 (level AA) asks fields collecting information about the user to carry the matching autocomplete token so browsers, password managers and assistive tools can identify them. This tool matches the field by its type, name and id, which is a shape rather than a certainty — a field called “company” on a B2B form may not be about the person filling it in. Read it as a prompt. Adding the token also measurably raises completion on phones, which is usually the argument that gets it shipped.

Does this store my domain?

No. The check is a single HTTP GET of the page you name, run inside the request and discarded when it answers. There is no account, no email field and no row written anywhere. If you go on to run the free scan, that one does keep a report so you can come back to it, which is the whole point of a report.