Do not ship form controls without accessible names
A field sits next to visible text with no code joining the two, so the name every sighted user reads never reaches assistive technology. F68 is the failure technique for it, which makes a match a defect on your form rather than a technique you can claim. Six things can supply that name. A label element tied to the field by its for attribute, a label wrapped around the field, aria-label, aria-labelledby, alt text on an image button, or a title attribute. Any one of them ends the failure. F68's own reach is narrower than most people assume, because it covers input, textarea and select and leaves submit buttons, reset buttons and plain buttons outside. A button with no name still breaks the rule. It just is not filed here.
How we find it in an audit
This one automates about as well as anything in the set. Every scanner we run lists the controls with no accessible name, and we confirm each hit in the browser's accessibility tree so the report describes what the API actually exposes rather than what the markup looks like. Then a reviewer goes after the quieter version, which is a name that exists and is wrong. A placeholder standing in for a label passes a scanner and disappears the moment somebody types.
How affected users experience it
Tabbing into the field, a screen-reader user hears edit text and nothing else. They guess from whatever came before, which is harmless on a newsletter signup and expensive on a payment form, where a wrong guess files a card number as a house number. Voice-control users are stuck harder still. Their command is click Email, and if no Email exists in the accessibility tree, there is nothing for the software to click.
Passes vs. fails
Passes
<label for="email">Email</label>
<input type="text" id="email" name="email">Fails
Email <input type="text" name="email">How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Image button has non-empty accessible nameA tool can check this
- Link has non-empty accessible nameA tool can check this
- ARIA attribute is defined in WAI-ARIAA tool can check this
- ARIA state or property has valid valueA tool can check this
- Element with role attribute has required states and propertiesA tool can check this
- Form field has non-empty accessible nameA tool can check this
- Role attribute has valid valueA tool can check this
- ARIA state or property is permittedA tool can check this
- Button has non-empty accessible nameA tool can check this
- Element with aria-hidden has no content in sequential focus navigationA tool can check this
- Element with presentational children has no focusable contentA tool can check this
- Menuitem has non-empty accessible nameA tool can check this
- Summary element has non-empty accessible nameA tool can check this
- Iframe element has non-empty accessible nameA tool can check this
- Iframe elements with identical accessible names have equivalent purposeA tool finds candidates, you decide
The other techniques filed under this rule
23 guides on this site are filed under 4.1.2 Name, Role, Value. W3C documents this one as a failure of that rule, so it describes a way the rule gets broken rather than a way to pass it.
- ARIA4sufficientGive custom widgets a real ARIA role
- ARIA5sufficientExpose widget state with ARIA attributes
- ARIA14sufficientLabel icon-only controls with aria-label
- ARIA16sufficientName controls from visible text with aria-labelledby
- G10sufficientBuild custom components on accessibility-supported tech
- G108sufficientExpose name, role, and changes through markup
This guide is our interpretation of W3C technique F68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined name. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.