The Value of Selecting Selects by Value

This is meant to use voice control to test select menus (and other fields, but the title would be less weird) by their value because their accessible names are hidden. I’m sharing results of that testing.

This was partially driven by:

WCAG issue #3808 SC 3.3.2: Labels or Instructions and a <select> element lacks a visible label and rely on default option.
That issue spawned #4630 SC 3.3.2: Labels or Instructions needs another example for failure when a <select> element lacks a visible label.
Both of those issues are pre-dated by #2484 2.5.3 is visible select option considered part of the accessible name here? (which is closed) and
#2509 3.3.2: provide failure examples/techniques for placeholderand <select> relying on default <option> only.

It’s not unusual ~~to be loved by anyone~~ for there to be multiple related WCAG issues.

Demo

A made a demo that looks somewhat like a flight booking form.

See the Pen Flights by Adrian Roselli (@aardrian) on CodePen.

Visit the pen directly (for forking or reviewing). Also available in debug mode (which gets rid of the wrapper cruft).

Notes

The accessible names come from visually-hidden <label>s, which you can make visible with the “Visible labels” button.
This demo is to test how voice control works when selecting controls by their value.
- The first select menu and the first text input of each fieldset (and the one between the selects) have a defined value.
- The second select menu has a default value (which is the first option), and the latter two text fields of each fieldset have no value.
- The accessible names are correctly exposed according to browser dev tools.
Feel free to validate the HTML.

Testing Results

Again, I only tested voice control. I didn’t test Dragon because I’m not paying. If you have it, feel free to leave your testing results in the comments.

Windows Voice Access with Chrome, Firefox

Speaking “Round trip” selected it.
Speaking “First class” selected it.
Any other non-hidden words on the page that included any of the spoken commands would cause voice access to offer me a choice instead of selecting the control.
Speaking the value of any other control did not select it (but sometimes offered a number to select it from others), and in the case of “BUF” focused a browser tab that had an article about tourism in Buffalo.
I could select a select menu by speaking one of its not visible options, unlessthe option had a hyphen.
I could select any control by speaking its accessible name, provided by the <label>.

macOS 26 Voice Control with Safari

Speaking “Round trip” selected it.
Speaking “First class” did not.
Any other non-hidden words on the page that included any of the spoken commands would cause voice control to offer me a choice instead of selecting the control.
Speaking the value of any other control did not select it.
I could select any control by speaking its accessible name, provided by the <label>.

Android Voice Access with Chrome, Firefox

Speaking “Round trip” selected it in Chrome, not Firefox.
Speaking “First class” selected half the time.
Speaking the value of any other control did not select it.
I could select any control by speaking its accessible name, provided by the <label>.

iPadOS 26 Voice Control with Safari

Speaking “Round trip” did not select it.
Speaking “First class” also did not select it.
Any other non-hidden words on the page that included any of the spoken commands would cause voice control to offer me a choice instead of selecting the control.
Speaking the value of any other control did not select it.
I could select any control by speaking its accessible name, provided by the <label>.

Recommendation

Remove ambiguity by using visible labels that correspond to the accessible name (ideally by using <label>). Relying on field values is risky, prone to error, can conflict with unknown values, not per spec, and creates extra work for voice users. Avoid making extra work for voice users.

In no way is this meant to denigrate the ~~terrible~~ work of others.