Accessibility Guides for low vision

When a <select> element lacks an accessible name, screen readers announce it as something generic like "combobox" or "listbox" with no context about what it represents. A sighted user might see nearby text like "Country" and understand the purpose, but that visual proximity means nothing to assistive technology unless a programmatic relationship exists between the text and the form control.

This issue critically affects users who are blind, have low vision, or have mobility impairments and rely on assistive technologies to interact with forms. Without a proper label, these users cannot determine what data a dropdown expects, making form completion error-prone or impossible.

Related WCAG Success Criteria

This rule maps to WCAG 2.0, 2.1, and 2.2 Success Criterion 4.1.2: Name, Role, Value (Level A), which requires that all user interface components have a name that can be programmatically determined. It also falls under Section 508 §1194.22(n), which mandates that online forms allow people using assistive technology to access all field elements, directions, and cues needed for completion.

How to Fix It

There are several ways to give a <select> element an accessible name, listed here from most preferred to least preferred:

1. Explicit <label> with for/id — The most common and recommended approach. Use the for attribute on the <label> to match the id of the <select>. This also gives sighted users a larger click target.

2. Implicit <label> wrapping — Wrap the <select> inside a <label> element. No for/id pairing is needed.

3. aria-labelledby — Point to the id of an existing visible text element that serves as the label. Useful when a traditional <label> would break layout or when multiple elements combine to form the label.

4. aria-label — Provide an invisible text label directly on the <select>. Use this only when no visible label text exists or is appropriate.

Whichever method you choose, make sure:

• The label text clearly describes what the user should select.
• Each id attribute is unique on the page.
• Each <select> has only one labeling method to avoid conflicts or confusion.

Examples

Incorrect: No Label Association

This places text near the <select> but creates no programmatic link between them. Screen readers will not announce "State" when the user focuses the dropdown.

State:
<select>
  <option value="ny">New York</option>
  <option value="ca">California</option>
</select>

Correct: Explicit <label> with for and id

The for attribute on the <label> matches the id on the <select>, creating a clear programmatic association.

<label for="state">State:</label>
<select id="state">
  <option value="ny">New York</option>
  <option value="ca">California</option>
</select>

Correct: Implicit <label> Wrapping

Wrapping the <select> inside the <label> element implicitly associates them.

<label>
  State:
  <select>
    <option value="ny">New York</option>
    <option value="ca">California</option>
  </select>
</label>

Correct: Using aria-labelledby

When visible text already exists elsewhere (e.g., in a heading or table cell), use aria-labelledby to reference it by id.

<span id="state-label">State:</span>
<select aria-labelledby="state-label">
  <option value="ny">New York</option>
  <option value="ca">California</option>
</select>

Correct: Using aria-label

When no visible label is present or appropriate, aria-label provides an accessible name directly. Note that this label is invisible to sighted users, so only use it when context is already visually clear.

<select aria-label="State">
  <option value="ny">New York</option>
  <option value="ca">California</option>
</select>

When interactive elements on a page are too small or too close together, users frequently activate the wrong control. This is frustrating at best and can cause serious problems — like submitting a form prematurely, navigating to the wrong page, or triggering an unintended action that's difficult to undo.

This rule relates to WCAG 2.2 Success Criterion 2.5.8: Target Size (Minimum) at the AA level. The criterion requires that touch targets be at least 24 by 24 CSS pixels, measured by the largest unobscured area of the target. If a target is smaller than 24 by 24 pixels, it can still pass if there is enough space around it — specifically, you must be able to draw a virtual 24-pixel-diameter circle centered on the target that does not intersect any other target or the circle of any other undersized target.

Who is affected

A wide range of users benefit from properly sized touch targets:

• People using mobile devices where touch is the primary interaction method
• Users with motor impairments such as hand tremors, limited dexterity, or reduced fine motor control
• People using devices in unstable environments like public transportation or while walking
• Users operating devices one-handed or with limited grip
• People with large fingers or those who interact with the screen using a knuckle or part of a finger
• Mouse and stylus users who struggle with precise targeting

Even users without disabilities can be affected — anyone tapping a tiny button on a phone screen has experienced this problem.

How the rule works

The axe engine checks each interactive touch target on the page by:

1. Calculating the largest unobscured area of the target (the portion not visually covered by other elements).
2. Checking if that area is at least 24 by 24 CSS pixels.
3. If the target is undersized, checking whether a virtual 24-pixel-diameter circle centered on the target overlaps with any other target or with the circle of any other undersized target.

If the target fails both the size check and the spacing check, the rule reports a violation.

How to fix it

You have two options:

1. Make the target at least 24 × 24 CSS pixels. Increase the element's size through font-size, padding, min-width, min-height, or any combination that results in at least 24 × 24 pixels of tappable area.
2. Add sufficient spacing. If the target must remain small, ensure there is enough margin or space around it so that the 24-pixel circle centered on the target doesn't overlap with neighboring targets.

Keep in mind that padding increases the clickable area of an element, while margin adds spacing between elements. Both strategies can help you meet this requirement.

Examples

Incorrect: small target too close to another target

The + button renders very small, and the negative margin pulls the adjacent button into its space, making both targets nearly impossible to activate accurately.

<button id="target">+</button>
<button style="margin-left: -10px">Adjacent Target</button>

Correct: target with sufficient size

Using a larger font-size and padding ensures the button meets the 24 × 24 pixel minimum.

<button style="font-size: 24px; padding: 4px 8px;">Submit</button>

Correct: small target with sufficient spacing

If a small target is necessary, adding enough margin ensures the 24-pixel circle around it doesn't overlap with adjacent targets.

<button>+</button>
<button style="margin-left: 24px">Adjacent Target</button>

Correct: icon buttons with explicit sizing

For icon buttons that might otherwise render very small, set explicit dimensions and use padding to enlarge the touch area.

<button style="min-width: 24px; min-height: 24px; padding: 4px;" aria-label="Close">
  ✕
</button>

Correct: inline links with sufficient spacing

When links appear in close proximity, such as in a list, ensure each item has enough height or spacing.

<ul style="list-style: none; padding: 0;">
  <li style="padding: 4px 0;"><a href="/home">Home</a></li>
  <li style="padding: 4px 0;"><a href="/about">About</a></li>
  <li style="padding: 4px 0;"><a href="/contact">Contact</a></li>
</ul>

Note that WCAG 2.5.8 includes several exceptions, such as inline links within text, targets whose size is determined by the user agent and not modified by the author, and cases where a specific presentation is legally required. Refer to Understanding Success Criterion 2.5.8: Target Size (Minimum) for the full list of exceptions and additional guidance.