axessia.eu

The most common mistake with form labels: what goes wrong and how do you prevent it?

A label that is visually present but not associated with the input field is the error that most often makes forms unusable for screen readers. This is how you recognise the problem and how you prevent it.

A form field without a properly linked label is the most common error we encounter on contact forms, checkout steps, and login screens. The label is often visually present, neatly positioned above or next to the input field, but it is not technically associated with that field in the source code. A screen reader then announces the field as "edit, empty" without explaining what the field is for.

The problem usually arises because a label and an input field appear to belong together visually, but the developer (or the site builder) has not established a technical relationship between them. For a sighted user, this makes no difference: they simply see the label. For someone using a screen reader, that visual proximity does not exist. What matters is the connection in the code, and it is missing more often than you would expect, even on sites that look well-designed.

Three variants of the same error

The most common form is the label that appears on screen but exists independently of the field in the code, without a technical link. The second form is the use of placeholder text within the field itself as the only explanation: as soon as the user begins typing, that text disappears, and a screen reader does not always treat a placeholder as a proper label anyway. The third form is especially common with icons: a search field with only a magnifying glass icon, or a button with only a pictogram, without text that a screen reader can read aloud.

All these variants share the characteristic that the error is usually not intentional. No one builds a form to make it inaccessible. It happens because a label looks correct visually and the builder assumes that settles the matter, while the technical link is a separate step that is easily overlooked, especially under time pressure or with a template that was not originally designed with accessibility in mind.

Why this carries more weight than it appears

A form is often the point at which a visitor actually wants to accomplish something: complete an order, create an account, get in touch. If the label is missing at exactly that moment, the process stops for some of your visitors, while the rest of the site works fine. Market surveillance authorities and reviewers therefore often look first at these kinds of bottlenecks in forms, because they directly affect whether someone can use your service.

Additionally, this error spreads easily. A label without a link in a single template for an address field often appears on dozens of pages at once, because the same component is reused everywhere. One missed link in the base template affects the entire checkout flow or the entire login screen.

How to test this yourself, and where an automated scan reaches its limits

An automated scan recognizes many of these errors well: it detects whether a label is technically linked to a field and whether an input field has no name at all. What a scan finds more difficult to assess is whether a label is accurate in content, whether a placeholder as the only explanation is clear enough, and whether the reading order for a screen reader makes sense. That is precisely why we note in every report what an automated test does and does not cover; so you know what still needs to be checked manually.

If you want to get a first impression yourself, the simplest test is to navigate through the form using only the keyboard and check whether each field gets a clear name when you tab to it. For a more thorough picture, including the checkout flow and login process, our full scan that looks beyond the homepage helps identify where labels are missing or disconnected from their field.

What an overlay widget cannot solve here

An accessibility widget pasted on top of the site cannot fix a missing link between a label and a field; that connection exists in the source code itself and must be corrected there. This is one of the reasons we do not sell overlays: they hide these kinds of errors from view, but a screen reader notices nothing different.

The solution itself is usually limited in scope: the developer links the label to the field, replaces a placeholder-as-label with a proper label, or adds invisible text to an icon button. It's not a major overhaul, but work that must be done carefully, per form and per template. In the knowledge base with explanations on each topic you will find how this and similar errors relate to the requirements in EN 301 549.

After the fix: document and monitor

A label you correct now can disappear again with the next template update—for example, when a designer restyls the form without rechecking the link. That's why a fix must not only be resolved technically, but also included in the improvement plan, making clear who is responsible and when it will be rechecked. How we structure that monitoring and review is explained on the page about how the assessment is conducted.

If you're unsure whether your own forms contain this error, you can often spot it in a few minutes with keyboard navigation. If you want a structured approach with a prioritized list, start with the free quick-scan, or first check out the frequently asked questions about what a scan does and does not check.

This article is general information and not legal advice.