← Back to SEO LearnNOTABIS SEO / LEARN

Accessibility · 16 September 2026

Unlabeled Form Controls: How to Fix Accessibility Findings

NOTABIS flags form controls that have neither an id nor an aria-label in measured HTML. Use the finding to inspect real label associations, because the check is a lightweight heuristic.

Quick answer

Every form control should have a clear accessible label that tells users what to enter or choose. NOTABIS reports unlabeled-form-control when an <input>, <select>, or <textarea> has neither an id nor an aria-label in the measured HTML. The rule is a lightweight heuristic: it does not prove that an id is actually connected to a <label> or that the label text is useful.

What the issue means

A visible label is normally associated explicitly with a control:

<label for="email">Email address</label>
<input id="email" name="email" type="email">

aria-labelledby or aria-label can provide an accessible name when a visible label is not practical, but a visible label is usually clearer for everyone. A placeholder is not a reliable replacement because it disappears while a user types.

Why it matters for SEO

Labels primarily improve accessibility and form completion, not rankings. Clear controls also make page purpose and interaction easier for users and assistive technology to understand. Search engines do not turn this heuristic into a direct ranking penalty, so fix controls that are genuinely unclear rather than adding meaningless attributes to every field.

How NOTABIS detects it

For each measured page, NOTABIS examines input, select, and textarea elements. It increments the count when neither an id nor an aria-label attribute is present. The unlabeled-form-control finding is page-scoped. It does not verify a matching <label for>, inspect aria-labelledby, evaluate label wording, or test keyboard and screen-reader behaviour. If a page contains a detected third-party control, the report may make the finding informational so ownership can be checked first.

How to check it yourself

Inspect the form in the DOM and accessibility tree. For each control, follow its associated label, aria-labelledby, or aria-label and confirm that the name describes the expected input. Test focus order, error messages, and mobile input behaviour with a keyboard and an assistive technology check.

How to fix it

Prefer a visible <label> with a matching control id, or wrap the control inside the label. Use aria-labelledby when the name comes from visible text elsewhere, and reserve aria-label for cases without suitable visible text. Keep IDs unique and do not use a placeholder as the only name.

<label for="company">Company</label>
<input id="company" name="company" autocomplete="organization">

After changing the template, verify the accessibility name rather than stopping when the NOTABIS count reaches zero. W3C’s form labelling guidance covers explicit and implicit associations.

When this is intentional or does not need fixing

Some hidden inputs are implementation details and do not need a user-facing label, although they should not be exposed as interactive controls. Third-party widgets may require vendor changes. Confirm ownership and rendered behaviour before altering a payment, challenge, or embedded control.

Related issues

Review missing main landmarks, empty link text, and missing H1 tags when auditing a page’s broader structure.

Run a NOTABIS audit

NOTABIS lists the number of controls that match its missing-id-and-label heuristic, so you can trace the result back to the page template and accessibility tree.

Measure before you change

See which issues affect your site.
Run a NOTABIS audit ↗