The Form Label Metric: The Unlabelled Input That Fails 3.3.2

Every form has a field that nobody labelled. It is usually the search box, or the discount code field, or the one extra input someone added late and never went back to finish. It looks fine, because it has a placeholder or an icon that tells a sighted user what it is for. To a screen reader user it announces as "edit text, blank," with no name, no purpose, and no way to know what to type. The label metric is the count of those fields, and most teams have never run it.

A label is a name, and the name has to be real

WCAG 2.2 Success Criterion 3.3.2, Labels or Instructions, requires labels or instructions when content requires user input. The label is the accessible name of the input, and it has to come from a real label element associated by id, or from an aria-label or aria-labelledby that names it. A placeholder is not a label: it disappears when the user types, and the screen reader does not expose it as the name. An icon is not a label: it has no text for the screen reader to read, and the title attribute some teams add to the icon is not reliably announced. A heading next to the field is not a label either, unless it is associated with the input. The test is simple: turn on a screen reader, tab to the field, and listen. If it announces the name, it has a label. If it announces "edit text, blank," it does not.

The same failure shows up under 1.3.1, Info and Relationships, which requires that information conveyed by presentation is available programmatically. A label that exists only as visual text next to the field is presentation. A label element tied to the input by id is structure. The distinction matters because the scanner can only check the structure. A scanner that counts visible text near inputs will pass a form that fails the screen reader test, and a scanner that counts label elements will catch it. The metric is only as good as the definition behind it, and the definition has to be the accessible name, not the visible text.

Count the fields, not the forms

Most teams measure label compliance per form: the checkout form passes, the search form passes, the newsletter form passes. The failure hides inside the form that passes, because one field in twelve has no label and the form-level check does not see it. Count per field instead: every input, select, and textarea on the site, checked for an accessible name, reported as a share of all fields. A checkout form with 23 fields and one unlabelled discount code field is 96% compliant and 100% broken for the shopper who needs that field. Redundant entry has the same shape: the retyping tax is invisible until you count the fields that ask for information the site already has. Heading order fails the same way: one skipped level breaks navigation for the user who depends on it, and the page-level check never sees it.

Fix the late additions first

The unlabelled fields cluster in the same place every time: the inputs added after the form was built. The discount code field, the gift message field, the search box in the header, the extra field marketing asked for last week. The original form went through review. The additions did not. The fix is a rule, not a project: no input ships without an accessible name, and the check runs in the deploy pipeline, not in the quarterly audit. The pipeline check is ten lines and it catches the field the day it is added, when the person who added it still remembers why. The quarterly audit catches it three months later, when nobody does.

Run the count this week. Tab through the checkout with a screen reader, listen for "edit text, blank," and fix every field that announces itself that way. The label is one line of markup, and the shopper who needs it has been waiting for it since the field was added.

Frequently asked questions

Why is a placeholder not a label?

Because the screen reader does not expose placeholder text as the accessible name, and the placeholder disappears when the user types. WCAG 2.2 Success Criterion 3.3.2 requires a label or instructions for user input. Use a real label element tied to the input by id, or an aria-label that names it.

Does an icon next to the field count as a label?

No. An icon has no text for the screen reader to announce, and a title attribute on the icon is not reliably exposed. Give the input an accessible name with a label element or aria-label, and keep the icon as decoration.

How should I measure label compliance?

Per field, not per form. Count every input, select, and textarea on the site, check each for an accessible name, and report the share that has one. A form that passes a form-level check can still contain one unlabelled field, and that field is the one the shopper needs.

Which fields are most often unlabelled?

The ones added after the form was built: the discount code field, the gift message field, the header search box. The original form went through review and the additions did not. Put the accessible-name check in the deploy pipeline so the field is caught the day it is added.