Form elements should not use title attribute as the only accessible name.

When a form element such as <input>, <select>, or <textarea> relies on the title attribute as its only accessible name, many users will not be able to identify the purpose of that control. The title attribute produces a tooltip that appears on mouse hover (and sometimes on keyboard focus), but it is not a visible, persistent label. Touch screen users never see it, since there is no hover equivalent on mobile devices. And many assistive technologies either ignore the title attribute entirely or treat it as a secondary description rather than the primary name of a control.

Screen reader users are the most directly affected. While some screen readers will fall back to title when no other accessible name exists, this behavior is inconsistent across software and versions. A user running one screen reader may hear the label; another may hear nothing at all, or just "edit text" with no context. Users with cognitive disabilities also lose out, because a visible, always-present label helps them understand what each field expects. Low vision users who rely on screen magnification may never encounter the tooltip, since it requires precise mouse positioning over the element.

Why this matters (WCAG 4.1.2)

WCAG Success Criterion 4.1.2 (Name, Role, Value) at Level A requires that all user interface components have a name that can be programmatically determined. While the title attribute can technically provide a programmatic name, its unreliable support in assistive technologies and its invisibility to touch and keyboard-only users make it a poor substitute for a proper label. The intent of 4.1.2 is that users can always identify a control's purpose, regardless of how they interact with the page.

How to fix it

Replace the title attribute with a visible <label> element, an aria-label attribute, or an aria-labelledby attribute. If the title attribute provides useful supplementary information (such as formatting hints), keep it alongside one of these alternatives, but never use it as the sole name.

The best option in most cases is a visible <label> element connected to the input through a for attribute. This gives every user a clear, visible indication of the field's purpose and increases the clickable area of the control.

If a visible label is not possible due to design constraints (for example, a search field with only a magnifying glass icon), use aria-label to provide an accessible name that screen readers can announce.

If a visible label exists elsewhere on the page but is not programmatically associated with the input, use aria-labelledby to point to that element's id.

Examples

Incorrect: title as the only accessible name

<input type="text" title="Enter your email address">

This input has no <label>, no aria-label, and no aria-labelledby. The only name comes from title, which many users will never see or hear.

Correct: visible <label> element

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

The <label> is always visible and programmatically associated with the input through the matching for and id attributes.

Correct: aria-label when no visible label is possible

<input type="search" aria-label="Search">
<button type="submit">
  <img src="search-icon.svg" alt="Search">
</button>

The aria-label gives screen readers a name for the search field, even though no visible <label> appears on screen.

Correct: title as a supplement to a visible label

<label for="date">Date of birth</label>
<input type="text" id="date" title="Use the format MM/DD/YYYY">

Here the title provides a formatting hint as extra context. The primary accessible name comes from the <label>, so the control is properly identified regardless of whether the tooltip is ever seen.

Correct: aria-labelledby pointing to existing text

<h2 id="billing-heading">Billing information</h2>
<input type="text" aria-labelledby="billing-heading" aria-label="Street address">

When the label text already exists on the page, aria-labelledby can reference it. In this example, aria-label adds specificity for the individual field.

Learn more:

W3C Reference

Understanding Success Criterion 3.3.2: Labels or Instructions

→

W3C Reference

H44: Using label elements to associate text labels with form controls

→

MDN Reference

HTML label element

→