2.5.3 is visible select option considered part of the accessible name here?

[detlevhfischer]

The situation is simple but the 2.5.3 understanding text is not explicit regarding the assessment of visible select default options.

Is this a FAIL of 2.5.3?
A select with:

• no visible (and programmatically linked) label
• a default visible option "Addresses used"
• a title with the value "previous destinations"

Screenreaders I tested render both the title AND (after a short gap) the default option. Still, the question is whether in a speech input scenario, the assistive technology would support something like "click Addresses used" (which is in a sense the visible label here).

And beyond current AT support, the general question is whether a strict interpretation of "accessible name" for a select would disregard altogether the default option (and only accept a programmatically linked label, an aria-label, text referenced by aria-labelledby, or title).

[bruce-usab]

Do you have some code we might explore? I want to check my understanding of the accessible name calculation against what ANDI reports.

Do we not already have a failure written up about only using only option [or title] as the field prompt? I think that is a 1.3.1 failure, but I could not quickly find that in Understanding. It seems to me that such a Failure would have prose that is applicable to this situation.

From just now reviewing F96 Failure due to the accessible name not containing the visible label text the examples seem analogous.

I think we need to know how voice recognition software works in practice with the code. From Understanding 2.5.3 it is not just about support for prompts via screen reading software, but being able to use voice recognition software to navigate to (and trigger) form elements.

From a 2.5.3 perspective I don't think "click addresses used" is any different than "addresses used" because the both contain "addresses" -- but I would guess neither helps someone using voice recognition software since the (invisible by default) accessible name is "previous destinations".

But this line of reasoning reduces to why (or if?) title (only) as form label is not accessible.

[scottaohara]

an option value does not name the select element. a very quick test of just <select><option>one</option></select> with iOS voice control and saying "click one" does not activate the element. if the listbox popup is open and i say "click one" then the "one" option is clicked - which makes sense because 'one' is the name of the option in this context - and again, not the name of the select element.

[detlevhfischer]

Thanks @scottaohara - that is helpful and confirms my suspicion.
@bruce-usab I believe that title can be used as accname of a select - the example mentioned just fails 2.5.3 (and may in addition fail 3.3.2)

[scottaohara]

i wouldn't have come to that conclusion. Rather, it fails 3.3.2 for lack of visible label and the purpose of the select becomes unclear when the initial 'placeholder' option is no longer the selected option.

Since there is no visible label, and only the value of the combobox is shown, i wouldn't expect a 2.5.3 failure.

[detlevhfischer]

@scottaohara If the default option "Addresses used" can be considered visually sufficient (since 3.3.2 does not mandate programmatic availability) and any other select option implicity shows it is an address (which in the context of supplying origin or destination information for a journey seems pretty clear to me) one could argue that there is always a marginally sufficient visual label: either the default, or the chosen address after interaction with the select, thus passing 3.3.2. So this is a bit different from the placeholder case where the visual "label" disappears with any input. (I note that most people(?) would pass 3.3.2 in a floating label scenario, so a default label on top of an interface element seems generally acceptable, even if not best practice.)
By the same logic, if an author ensures (via title or aria-label) that accname matches the default option, all states except this default would then fail 2.5.3 after any selection?

[scottaohara]

@detlevhfischer - i think you misunderstood my comment? I wasn't implying anything about 3.3.2 having anything to do with being programmatically available, nor did i mean 'placeholder' to correlate to the placeholder attribute or the floating label technique.

any other select option implicity shows it is an address

sure, but does the value represent an "address", or a billing address, shipping, delivery, destination, location? Depending on other information in the form, this could be unclear and require someone to have to re-open the listbox popup to see the initial 'placeholder' option (again, not a label and not a name).

If using the title attribute, someone on a touch device would never get to see the actual name/label of the element.

[detlevhfischer]

@scottaohara no, I think I got your comment, and sorry, I did not mean to suggest that you think 3.2.2 is related to programmatic determination - and only mentioned placeholder as a contrasting example where the visible label (if it is at all counted as that) is non-permanent. I just wanted to pad out my line of argument that if, in some context, you consider both the default option and any selected option sufficient to meet 3.3.2, there would still be an issue with 2.5.3. I have not rendered (could not render) the full example - in this case, the select is part of a form for setting travel origin / travel destination, and its options hold street, place, and post code.

If using the title attribute, someone on a touch device would never get to see the actual name/label of the element.

true, but title would (and should, to meet 2.5.3) match the visible default option here - but this would fall apart once a selection is made and the default option is replaced. I would assume 'label in name' would be required for all states and for this reason, using option as a visible label would never work across all situations. That is why I would still be inclined to fail this case under 2.5.3 rather than 3.3.2 - but I see that a different argument can be made.

[fstrr]

This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list.