Select element has no accessible name

What is this issue?

A <select> element has no accessible name, the text a screen reader announces to identify an element. It comes from the first source that applies, in order: aria-labelledby, aria-label, visible label text, then other fallbacks specific to the element type.

None of the standard naming methods are present: no <label for> pointing at the select’s id, no wrapping <label>, no aria-label, and no aria-labelledby referencing text elsewhere on the page. The select still announces its role and current value, but nothing describes what the choice is for.

Why does this matter?

A dropdown’s value only means something in relation to what it’s choosing between. “Combo box, Australia” tells a screen reader user a country-shaped value is selected, but not whether the field is asking for a shipping destination, a billing country, or a currency: three completely different consequences hidden behind an identical announcement.

This shows up constantly on filter bars and sort controls, where a design often relies on the dropdown’s position next to a results grid to convey meaning visually, with no text label at all. A sighted user reads “Sort by” printed beside the dropdown; a screen reader user gets no equivalent, since nothing connects that visible phrase to the select in the underlying code.

Who is affected?

• Screen reader users: hear a bare combo box announcement with the current value but no purpose, and have to explore the surrounding page to guess what the field controls.
• Voice control users: target a select by speaking its accessible name, such as “click Sort by.” With no name, the field can’t be addressed by voice command even though it’s fully visible on screen.
• Cognitive disabilities: users relying on a screen reader to reduce reading load lose the immediate context a named select would provide, increasing the chance of choosing the wrong option in a form with several unlabelled dropdowns close together.

What users experience

Halima uses NVDA on Windows to shop for running shoes on an e-commerce site. A filter bar has three dropdowns in a row (size, color, and sort order), none of which have a connected label, relying instead on icons and spacing to convey their purpose visually. NVDA announces “combo box, 9” as she tabs to the first one, giving her no way to confirm it’s the shoe size filter rather than a quantity selector, so she opens each dropdown fully and reads through its option list just to identify which filter she’s looking at before changing anything.

How do I fix it?

Connect the select to a <label> element with a matching for/id pair. This is the most reliable fix because it works in every screen reader with no ARIA required, and it enlarges the select’s clickable target to include the label text, which also benefits mouse and touch users.

<label for="sort-order">Sort by</label>
<select id="sort-order">

When the design genuinely has no room for visible label text (a single compact filter select embedded in a toolbar, say), add aria-label with a short description of what the select chooses, such as aria-label="Sort products by". This works because aria-label supplies a name directly to assistive technology without adding anything to the visible layout.

If descriptive text already exists nearby but can’t easily become a <label> (a heading grouping several filter controls together, for instance), use aria-labelledby pointing at that element’s id instead, so the select’s name reuses text that’s already on the page.

Code Examples

<select id="sort-order">
  <option value="relevance">Relevance</option>
  <option value="price-asc">Price: Low to High</option>
</select>

<!-- Method 1: for/id pair (broadest support) -->
<label for="sort-order">Sort by</label>
<select id="sort-order">
  <option value="relevance">Relevance</option>
  <option value="price-asc">Price: Low to High</option>
</select>

<!-- Method 2: aria-label (design has no room for visible text) -->
<select id="sort-order-compact" aria-label="Sort products by">
  <option value="relevance">Relevance</option>
  <option value="price-asc">Price: Low to High</option>
</select>

Method 1 gives the select a visible, connected label that benefits every user scanning the filter bar, not just screen reader users. Method 2 keeps a compact, icon-driven design intact while still supplying aria-label as the field’s accessible name, so the announced value always has a purpose attached to it.

Common Mistakes

Mistake: “The select sits right next to an icon that makes its purpose obvious.” An icon conveys meaning visually but contributes nothing to the accessible name computation unless it’s paired with text a screen reader can read. An icon alone, even a universally recognized one like a sort arrow, is invisible to assistive technology.

Mistake: “The first option already tells screen readers what the field is.” The first option is announced as the field’s current value, not its name: “combo box, Relevance” says what’s selected, not what’s being selected between. The select still needs its own label independent of whatever option happens to be chosen.

Mistake: “A placeholder-style disabled first option like ‘Choose a size’ works like a label.” That option is field content, not a field name, and it vanishes the moment a real option gets selected, exactly the same trap a placeholder attribute sets on a text input. A select needs a real label, aria-label, or aria-labelledby that persists regardless of which option is currently chosen.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s select-name rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. This page’s redflag-select-name frontmatter ID is a docs-slug alias RedFlag’s URL map uses so the extension’s “View docs” link resolves correctly; detection itself is unmodified, stock axe-core, not a RedFlag-authored check. The rule inspects every <select> element and checks whether the accessible name computation resolves to non-empty text through a <label for>/id pair, a wrapping <label>, aria-label, or aria-labelledby.

False negative: axe-core confirms a name exists; it can’t judge whether that name is accurate for the field. A <select id="sort-order"> labelled aria-label="Country" passes the automated check even though the label describes the wrong purpose. False positive: none typical for this check, since resolving to a non-empty accessible name is a binary condition. Manual step: read the announced name for every select and confirm it matches what the field actually filters, sorts, or chooses.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or VoiceOver running.
2. Tab to every <select> element on the page, paying particular attention to filter bars, sort controls, and compact toolbar dropdowns.
3. Listen to what’s announced immediately after the role: it should be a specific name plus the current value (“Sort by, combo box, Relevance”), not the value alone (“combo box, Relevance”).
4. Click directly on each visible label’s text (not the select itself) and confirm focus moves into the select, verifying the connection is programmatic and not just visual.
5. Open the browser’s accessibility inspector (Chrome DevTools → Elements → Accessibility pane) on one select and confirm the “Name” property matches the visible label text.

Related WCAG Success Criteria

4.1.2 Name, Role, Value: Every interface component must expose a name, role, and current value to assistive technology. An unlabelled select has a role (combo box) and a value (the selected option) but no name, which is this criterion’s requirement failing on its “name” element specifically.

3.3.2 Labels or Instructions: Labels or instructions must be provided when content requires user input. A select is a form of user input just as much as a text field, and this criterion requires a label to exist at all, regardless of whether it’s visible or supplied through aria-label.

Related Issues

Form input has no label covers the identical failure on text inputs, checkboxes, and textareas: the same accessible name mechanics applied to a different form control type.

Input only uses placeholder as its label documents the closest analogue to this rule’s “placeholder-style first option” mistake, applied to a native text input’s placeholder attribute instead of a select’s disabled option.

Related form inputs are missing fieldset and legend is worth checking when several related selects appear together, such as a date-of-birth split across day, month, and year dropdowns that need a shared group label.

Form field autocomplete attribute is missing or invalid is a related but distinct requirement for the same common select fields, like a country or state selector. A correctly labelled select can still be missing the metadata that enables browser autofill.

References

• W3C Understanding 4.1.2: Name, Role, Value
• W3C Technique H44: Using label elements to associate text labels with form controls
• MDN: The select element