Form label coverage: counting inputs with no accessible name
Every form on a site has a few inputs with no accessible name. A search box with a placeholder and no label. A quantity field with a visual label that is not programmatically connected. A date picker built from three selects with no group label. Each one is invisible to a screen reader user, who hears edit text, blank, and has to guess what the field wants. The failure is WCAG 4.1.2 Name Role Value and 3.3.2 Labels or Instructions, and it is the most common form failure on the web.
Measure it as coverage. Count the inputs on a page, count the ones with an accessible name, and the ratio is the form label coverage for that page. A site at 100 percent has forms a screen reader can use. A site at 70 percent has three inputs in ten that are guesswork, and the guesswork is concentrated in exactly the forms that matter: checkout, search, and account creation.
Placeholders are not labels
The single most common cause is the placeholder used as a label. A placeholder disappears when the user starts typing, which means the label disappears at the exact moment the user needs it most. It also fails contrast requirements in most implementations, and screen readers handle it inconsistently. A visible label connected with a for attribute, or an aria-label where a visible label genuinely cannot exist, is the fix. The placeholder can stay as a hint. It cannot stay as the only name the field has.
The second cause is the visual label that is not connected. The words are on the page, next to the field, and sighted users read them fine. But the label element has no for attribute, or the input has no id, so the programmatic connection does not exist and the screen reader never announces the label. This is a one line fix per field, and it is the fix that moves the coverage number fastest.
Where the unnamed inputs hide
They hide in the components teams reuse without thinking: the search box in the header, the quantity steppers in the cart, the filters on a listing page, the date pickers in a booking flow. Each component is built once and shipped everywhere, so one unnamed input becomes fifty unnamed inputs across the site, and the coverage number drops by ten points from a single component.
That is why the metric is worth tracking by component, not just by page. Fix the search component and the coverage jumps across every page that uses it. Fix the filter component and the listing pages follow. The rate tells you which component to fix first, which is the question a raw count of issues never answers.
The number to watch
Put form label coverage on the dashboard next to the other rates, and set the target at 100 percent for every form a shopper or a visitor has to complete. Run it weekly, split it by component, and fix the worst component first. An input with no name is a door with no sign on it. The fix is a label, and the label costs nothing.
Keep reading: Alt text coverage and the decorative error, ARIA label coverage and the overuse problem.
Frequently asked questions
What is form label coverage?
The share of form inputs on a page that have an accessible name, counted against all inputs. A page at 100 percent has every input named. A page at 70 percent has three inputs in ten that a screen reader announces as blank.
Can a placeholder be the label for an input?
No. A placeholder disappears when the user starts typing, fails contrast in most implementations, and is handled inconsistently by screen readers. Use a visible label connected with a for attribute, or an aria-label where no visible label can exist.
Which WCAG criteria require accessible names?
4.1.2 Name Role Value requires every interface component to have a name, and 3.3.2 Labels or Instructions requires labels or instructions where input is needed. An unnamed input fails both.
Why track this by component instead of by page?
Because one unnamed input in a reused component becomes fifty unnamed inputs across the site. Fixing the component moves the coverage number everywhere at once, which is the fastest path to 100 percent.