A <select> element is usable only when users understand what the field is for. For users of assistive technologies, that understanding comes from the element’s accessible name. If a select element does A <select> element is usable only when users understand what the field is for. For users of assistive technologies, that understanding comes from the element’s accessible name. If a select element does not resolve to a programmatically determinable name, its purpose cannot be reliably identified, even if visible text appears nearby.
WCAG Success Criteria
4.1.2 — Name, Role, Value
User interface components must have a name and role that can be programmatically determined, and values that can be set by the user must be programmatically available to assistive technologies.
3.3.2 — Labels or Instructions
Users must be provided with labels or instructions when input is required.
In practice:
- 4.1.2 ensures assistive technologies can detect the label.
- 3.3.2 ensures users can understand the label.
A <select> without an accessible name commonly fails 4.1.2, and often 3.3.2 as well.
What an Accessible Name Means for <select>
The accessible name is the text that assistive technologies announce to identify the control.
It answers the question: “What information am I supposed to choose here?”
For example, with a proper label, a screen reader might announce:
“State, combo box, collapsed”
Without a name, it may announce only:
“Combo box, collapsed”
The control exists, but its purpose is missing.
How Screen Readers Use Labels
Screen readers do not infer meaning from visual layout or proximity. They rely on programmatic relationships in the DOM that are exposed through the accessibility tree, a structure browsers generate for assistive technologies.
“Programmatically associated” means the label is connected in the HTML in a way assistive technologies can detect, not merely placed nearby on the screen.
Role, Name, and Value for <select>
A <select> exposes:
- Role: typically combobox (or listbox when size > 1)
- Name: the label that identifies the field
- Value: the currently selected option
This is why <select> is directly relevant to Name, Role, Value (4.1.2), all three must be available programmatically.
Correct Markup Examples
These examples pass because the select resolves to a clear, accessible name.
Explicit <label> (recommended)
<label for="state">State</label>
<select id="state"></select>Wrapped label (implicit association)
<label>
State
<select></select>
</label>aria-label (use when a visible label is not possible)
<select aria-label="State"></select>aria-labelledby
<div id="state-label">State</div>
<select aria-labelledby="state-label"></select>Incorrect Markup Examples
These fail because the select does not resolve to an accessible name.
Visual text only (no programmatic relationship)
State:
<select></select>Sighted users can infer meaning. Assistive technologies cannot.
No label at all
<select></select>Broken aria-labelledby
<select aria-labelledby="missing-id"></select>If the referenced element does not exist or has no text, the name is missing.
About Multiple Labels (Important Clarification)
A form control must resolve to one computed accessible name.
Multiple <label> elements are allowed in HTML and will concatenate:
<label for="state">State</label>
<label for="state">Province</label>
<select id="state"></select>Accessible name becomes:
“State Province”
This may be confusing, but it is not inherently invalid. The issue is clarity, not automatic WCAG failure.
What Does Not Label a <select>
Placeholder-like options
<select>
<option>Select a state</option>
<option>Alabama</option>
</select>
The first option is announced as the current value, not as the label.
CSS positioning or visual proximity
Text placed near a select without a programmatic association does not create a label.
Why This Matters
When a <select> has no accessible name:
- Screen reader users must explore surrounding content to guess context
- Navigation becomes slower and error-prone
- Users may select incorrect values due to ambiguity
- Form completion rates drop, especially in long forms
The control is present, but its purpose is not reliably communicated.
How This Is Tested
Accessibility tools and manual audits verify that:
- Each
<select>resolves to a non-empty accessible name - Label associations are programmatically valid
- aria-labelledby references existing elements with text
- The name announced by assistive technologies is meaningful
In most cases, a missing accessible name is a clear failure under SC 4.1.2.
Rule of Thumb
If a screen reader user hears “combo box” without knowing what the choice is about, the select is not properly labelled.
Wrapping Up
Every <select> must resolve to a programmatically determinable accessible name. That name usually comes from a <label>, but may also come from ARIA when used correctly. What matters is not visual appearance, but whether assistive technologies can identify:
- What the control is
- What it represents
- What value is selected
A <select> without an accessible name leaves users guessing and fails the core purpose of accessible forms.
