Skip to content
Science-backed data on why AI says what it says
Browser usability

Form labels

A form label identifies the purpose of an input, selection, or text area. A useful label is understandable to the visitor and associated with the field so assistive technology can identify it.

Checked against BLURSOR’s measurements ·

What it means

Visitors should know what information a field requests before they type. A visible label such as 'Work email' remains useful after the field contains a value. An example inside the field can explain a format, but placeholder text alone disappears as typing begins.

The visual label and its relationship to the field are separate checks. Text placed nearby can look convincing while remaining unassociated in the markup. Conversely, an invisible ARIA name can identify a field to assistive technology without supplying the visible instructions other visitors need.

Illustrative example

Hypothetical example: a delivery enquiry

Suppose a delivery form contains an empty box with 'AB12 3CD' inside it. That example suggests a postal code but does not say whether the business wants the collection or delivery address. A persistent label reading 'Delivery postcode' answers that question; a separate example can explain the format.

This invented form illustrates a content decision. It does not claim that a particular website failed a test or that adding a label changes its conversion rate.

How BLURSOR measures it

In the report: Form fields without labels

BLURSOR compares fields without a detected name with the fields it inspected. The live browser probe counts visible inputs, selections, and text areas, excluding hidden inputs and button-like input types. It reuses the control-name routine, including associated labels and fallback text.

The detector accepts placeholders and title attributes as naming signals. A zero result therefore does not prove that every field has a persistent visible label. HTML estimates are less capable than the live probe: they cannot reliably resolve ordinary label relationships, so a correctly labeled field can still need manual confirmation.

What to do next

  1. Ask your developer to associate each visible label with its field, commonly through matching label-for and input-id values.
  2. Review required fields, expected formats, and error messages as part of the same journey. A label alone does not explain every input requirement.
  3. Test a complete enquiry or checkout with a keyboard and assistive technology, including validation errors and fields revealed by earlier choices.

What it cannot tell you

  • The checker does not submit the form or prove that validation, error recovery, or the receiving system works.
  • A measured zero and an unavailable result are different. The denominator describes inspected fields, not every field the application can display.

Sources and further reading

The definitions below describe the underlying concepts. The measurement section describes BLURSOR’s own checks.

Related explanations