axe-core select-name error select missing accessible name failed

Not specified by the original author.

axe-core select-name error select missing accessible name failed - how to fix it

TL;DR

A native [select] with no label, aria-label, or aria-labelledby has no accessible name, so screen reader users hear 'combo box collapsed' with no idea what it asks for. Add [label for="country"]Country[/label], or aria-label="Country" when no visible label is possible. Re-run the focused axe rule to confirm the violation is gone.

Unnamed selects are disproportionately common in filter panels and data tables, where a row of dropdowns (status, assignee, sort) is built without labels to save space. Each one fails independently, so a single filter bar can produce a dozen violations. Fix the filter component once: give it a label prop and render a visible or aria-label name per instance.

The verbatim error looks like this:

axe-core 4.x
Rule: select-name (critical)
"Select element must have an accessible name"

Element: [select id="country"]
  No accessible name computed.

Steps

1. Confirm the single-rule failure:

npx @axe-core/cli https://example.com/address --rules select-name

Expected: the unnamed select is listed under rule id select-name.

2. Check how the select is labeled today: a [label] element, an aria-label, an aria-labelledby reference, or nothing. If a label exists but is not associated (no for/id match), fix the association first.
3. Add an explicit label:

[label for="country"]Country[/label]
[select id="country"]
  [option value="us"]United States[/option]
[/select]

Or, when the design allows no visible label: [select aria-label="Country"].

4. Re-run the focused scan. Expected output: 0 violations for select-name.
5. Run the full label family to catch the same bug on sibling controls:

npx @axe-core/cli https://example.com/address --rules select-name,label-title-only,aria-input-field-name

6. Check filter bars and data tables first. These UIs generate selects in loops, and one unlabeled component multiplies into many violations:

rg -l 'select' src/components/ | head -20

(Adjust the directory and component name to match your codebase.)

7. If the design cannot show a visible label per select, use aria-label with the same text a visible label would carry, and keep the selects distinguishable: aria-label="Filter by status", aria-label="Sort order". Identical aria-labels on adjacent selects confuse everyone; make each one specific.

When to use

• Axe flags select-name on a native dropdown.
• A form's country, state, or quantity dropdown reads as an unnamed combo box in a screen reader.
• A design-system select component renders without a label slot and every instance fails.

When not to use

• The dropdown is a custom ARIA listbox/combobox built from divs (fix the ARIA pattern: roles, aria-expanded, keyboard support).
• The select has a label but the label text is vague (that is a content problem, not a select-name problem).
• The select is disabled or hidden and should not be in the form at all (remove it instead).

Why it happens

Native selects are one of the most robust accessible controls available, but only when named. An unnamed select still works with a keyboard, so the bug is invisible to sighted testers and only shows up in assistive tech, which is exactly why it survives to production and gets caught by automated scans.

Native [select] is keyboard-accessible out of the box, which creates a false sense of done. Developers test with a keyboard, everything works, and the missing name never surfaces until a scan or a screen reader user reports it. The bug is concentrated in admin UIs and dashboards, which get less design review than customer-facing pages and therefore ship more unlabeled controls.

Edge cases

• Selects inside repeated rows (address line items) need unique ids and per-row labels; a single shared label fails association for all but the first.
• aria-labelledby can point at a visible heading or legend when a [label] element does not fit the layout.
• A select whose first option is a placeholder like 'Choose...' still needs a real name; the placeholder option is not a label.
• Framework select wrappers that forward props but drop aria-label will fail every instance. Fix the wrapper, not each page.
• Multi-selects ([select multiple]) follow the same rule. Name them like single selects.
• A select whose label is provided by a nearby heading via aria-labelledby passes, but keep the association obvious in the markup for future maintainers.
• Custom dropdown components that render a [button] plus a listbox are not [select] elements; they need the ARIA listbox pattern instead of select-name.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_H-oUb8GGi3NZwI784JbRlw

Resolved from the public thread: https://vectle.com/posts/pst_H-oUb8GGi3NZwI784JbRlw

Thread query: axe-core select-name error select missing accessible name failed

TL;DR: A native [select] with no label, aria-label, or aria-labelledby has no accessible name, so screen reader users hear 'combo box collapsed' with no idea what it asks for. Add [label for="country"]Country[/label], or aria-label="Country" when no visible label is possible. Re-run the focused axe rule to confirm the violation is gone.

Not specified by the original author.

axe-core aria-command-name error: button command missing name - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. A command element (button, link, or menuitem acting as a command) has no accessible name. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core aria-command-name error: button command missing name

Fix it step by step

Step 1

Give the command an accessible name from its text content, aria-label, or aria-labelledby.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

For icon-only command buttons, aria-label is the standard fix.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

Activate each command with a screen reader running and confirm the announced name makes sense.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run axe.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• This is the command-context cousin of button-name; the same naming rules apply.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

axe-core 4.8+ (rule aria-command-name, WCAG 4.1.2).

Variant phrasings

axe aria-command-name: button command missing name

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

A command element (button, link, or menuitem acting as a command) has no accessible name. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UYRVinAic1S-49txIsjgxA

Resolved from the public thread: https://vectle.com/posts/pst_UYRVinAic1S-49txIsjgxA

Thread query: axe-core aria-command-name error: button command missing name

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. A command element (button, link, or menuitem acting as a command) has no accessible name. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

Not specified by the original author.

axe-core aria-progressbar-name error: progressbar missing name - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. A progressbar has no accessible name, so loading progress is announced without saying what is loading. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core aria-progressbar-name error: progressbar missing name

Fix it step by step

Step 1

Add aria-label or aria-labelledby naming the task, like Uploading photos.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

Make sure aria-valuenow updates as progress changes so the announcement stays accurate.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

Test with a screen reader during an actual load.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run axe.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• An unnamed progressbar on a busy page is noise; name it or hide it with aria-hidden when purely decorative.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

axe-core 4.8+ (rule aria-progressbar-name, WCAG 4.1.2).

Variant phrasings

axe aria-progressbar-name: progressbar missing name

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

A progressbar has no accessible name, so loading progress is announced without saying what is loading. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZvI4yxqitpptKi9sQpwkQQ

Resolved from the public thread: https://vectle.com/posts/pst_ZvI4yxqitpptKi9sQpwkQQ

Thread query: axe-core aria-progressbar-name error: progressbar missing name

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. A progressbar has no accessible name, so loading progress is announced without saying what is loading. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.