How to fix: Select dropdowns missing labels

A label is the machine-readable name of a form control. WCAG Success Criterion 1.3.1 Info and Relationships requires that the relationship between a field and its label exist in code, not just in visual layout. When focus reaches a <select>, a screen reader announces its name, then its current value, so the user knows the menu is, say, "Country" and currently reads "United States," rather than hearing a list of options with no idea what they choose.

A <select> is part of the same labeling family as text inputs and textareas, but it is worth checking on its own because dropdowns are easy to overlook. Developers often place a heading or a visible word above a select without connecting it, assuming the proximity is enough. It is not: unless the text is tied to the control, assistive technology treats the select as unlabeled.

There are a few valid ways to provide the name. The most robust is a <label> whose for attribute matches the select's id, which also makes the label clickable to focus the menu. You can wrap the <select> inside a <label>. Or, when a visible label genuinely is not feasible, use aria-label with a literal string, or aria-labelledby pointing at the id of existing visible text. A bare <option> placeholder like "Choose one" is not a substitute for a real label.

Screen reader users are hit hardest. An unlabeled select is often announced only as "combo box" with its options, leaving the user to infer the purpose from the values, which fails completely when several dropdowns sit together, such as separate month, day, and year menus that all just read as lists of numbers.

Voice-control users who say "click country menu" depend on the programmatic name to target the right control, and people with cognitive disabilities benefit from a persistent, clearly associated label that does not rely on remembering which heading goes with which dropdown.

An unlabeled select is a Level A failure under SC 1.3.1, the same criterion that governs unlabeled text inputs, and missing form labels rank among the most common issues in the WebAIM Million report. Because dropdowns gather choices that drive checkout, shipping, plan selection, and filtering, the barrier maps almost directly to lost conversions, not just a compliance gap.

Unlabeled fields on a public form are also an easy, screenshot-ready finding for a plaintiff, and WCAG 2.1 Level AA, which includes every Level A criterion, is the benchmark U.S. courts apply to ADA claims. Accessibility lawsuits have risen year over year and mostly target businesses under $25 million in revenue, so clearing a trivially-detectable Level A failure removes an obvious audit item. The fix is typically a single <label> element or one aria-label attribute.

1. List every <select> element on the page, including ones tucked into filters, address blocks, and date pickers.
2. Give each select an id and add a <label for="that-id"> with clear, visible text naming what the menu controls.
3. If a visible label is not possible by design, add aria-label to the select, or point aria-labelledby at the id of existing visible text.
4. Do not rely on a placeholder <option> such as "Select one" as the label; it is not an accessible name and it disappears once a real value is chosen.
5. Confirm the association by clicking the label text and checking that it focuses the dropdown, then re-scan.

<span>Country</span>
<select name="country">
  <option>United States</option>
  <option>Canada</option>
</select>

<label for="country">Country</label>
<select id="country" name="country">
  <option>United States</option>
  <option>Canada</option>
</select>

AccessKnight selects every <select> element and checks, in order, for any one of: a <label for="id"> that matches the select's id, a <label> ancestor wrapping the select, an aria-label attribute, or an aria-labelledby attribute. If none of those is present, the dropdown is flagged as missing a label. A placeholder <option> alone never satisfies the check, because option text is the menu's content, not its accessible name. This is the same labeling logic AccessKnight applies to text inputs, run specifically against <select> menus.