Select elements need accessible labels

Select elements require a programmatically associated label

Every select control must expose an accessible name through a programmatic label.

This occurs in dropdowns for address fields, filters, and custom-styled selects. It affects screen reader users, people using speech recognition, and anyone who relies on assistive technology to understand and operate form controls.

Why It Matters

Screen readers announce a control’s role and its name. Without a label, users may only hear “combo box,” making it unclear what the field is for and blocking form completion.

Speech recognition tools use labels to target controls (e.g., “Click Country”). Missing or ambiguous labels make voice interaction unreliable.

Clear labels also reduce cognitive load for users with memory, language, or attention difficulties, and improve overall form usability.

Common Causes

• Missing label element or no association between label and select
• Nearby text visually looks like a label but is not programmatically linked
• Using the first option (placeholder text) as the only label
• Depending on the title attribute instead of a real label or ARIA
• Duplicate id values breaking the label–select relationship
• Hiding the visible label without providing an accessible name

How to Fix

• Prefer an explicit label: add a label element with a for attribute that matches the select’s unique id.
• Alternatively, use an implicit label: wrap the select inside a label element.
• If the visible label text exists elsewhere (e.g., a heading), reference it with aria-labelledby on the select, pointing to the element’s id.
• Use aria-label only when a visible label cannot be shown; keep it short, accurate, and consistent with any on-screen text.
• For related fields, group with fieldset and legend to label the group; still provide a label for each select when needed.
• Do not rely on placeholder options as a substitute for a label; they can supplement instructions but not replace the accessible name.
• Ensure all id values are unique across the page.
• Recommendation: Keep labels concise (2–5 words) and unambiguous.

How to Test

• Keyboard check:
• Tab to each select. Focus order is logical and the focus indicator is visible.
• Open the list (Space or Alt+Down) and navigate with Arrow keys. Close with Esc.
• Accessibility tree check (all browsers):
• Inspect the select in DevTools and open the Accessibility/Properties panel.
• Confirm Name shows the intended label text (from label, aria-labelledby, or aria-label).
• Screen reader check:
• NVDA + Firefox/Chrome: Focus the select. NVDA should announce the label first, then “combo box,” and the current value.
• JAWS + Chrome/Edge: Same expectation—label, role, and state/value.
• VoiceOver (macOS/iOS) or TalkBack (Android): Swipe to the select; the label should be spoken before the role/value.
• Speech recognition check (Dragon or macOS Voice Control):
• Say “Click [label text].” The correct select should be targeted.

Simple checklist:

• The select exposes a non-empty Name in DevTools.
• A screen reader announces the label and role together.
• Voice command using the label text targets the control.

Good Example

<label for="country-select">Country</label>
<select id="country-select" name="country">
  <option value="">Select a country</option>
  <option value="us">United States</option>
  <option value="ca">Canada</option>
</select>

Bad Example

<p>Country</p>
<select name="country">
  <option value="us">United States</option>
  <option value="ca">Canada</option>
</select>

Quick Checklist

• Each select has an accessible name via label/for, implicit label, or ARIA.
• Label text is visible or, if not possible, provided via aria-label/aria-labelledby.
• Id values are unique and correctly referenced.
• Do not use placeholder options as the only label.
• Label text is concise, specific, and matches visible copy.
• Screen readers announce label, role, and value in that order.
• Voice commands using the label text can target the select.