Improve accessibility of <selectedoption> example

[josepharhar]

This came from a discussion here: #1077 (comment)

[josepharhar]

@scottaohara what do you think of the HTML I have here?

[scottaohara]

only problem with this is being a generic element, spans are name prohibited. that's not to say it shouldn't work - because this is unfortunately something authors do so browsers have tried to mitigate for that in the accName computation. but it's still not really what authors should be doing, and validators should be noting this as an error/warning.

if that was span role=img aria-label=heart that'd work without issue. or if the aria-label was on the option, that'd generally be the way to do this.

or, the opposite approach is taken and the examples are made as:

<option>
  ❤️ <span aria-hidden=true>(heart)</span>
</option>

if we only want to use the name from the emoji and disregard the visible text repeating part of the name.

or or,

<option aria-describedby=ID>
  ❤️ <span id=ID aria-hidden=true>(heart)</span>
</option>

or or or (because developers hate IDs),

<option aria-description=(heart)>
  ❤️ <span aria-hidden=true>(heart)</span>
</option>

the above two examples use the emoji to get the name, and then use the visible text as the additional description - which is effectively what i'd hope the <description> element would eventually allow for.

<option>
  ❤️ <description>(heart)</description>
</option>

this being a lot easier for the dev than having to know anything about the ARIA bits i mentioned above.

[scottaohara]

FWIW, another way we could approach this without getting into any of the weeds above, is to just simply state that "using both the emoji and the text together can make for some awkward/redundant names for these options. In the future we hope to improve the UX by making a new feature for developers that doesn't require in depth understanding of ARIA"

my main goal with this and the other comments about the split button markup is not to put a screeching halt to any of this work, but to acknowledge there could be better ways / more things needed to markup the ideal experience for these features - and if the code examples can't be updated to accommodate, then we should at least acknowledge there's more work for the implantation or web authors to do that may be beyond the scope of this initial work.

(sorry, it's my default to be in the weeds and try to figure this stuff out)

[josepharhar]

Thanks for the feedback and ideas!

I think that a more typical case will definitely be <img>s rather than emojis, so maybe we should change this example to use <img>s and/or show an example which works for both images and emojis.

Now that I'm thinking about it more, maybe we should have custom behavior for the way that <selectedoption> is announced. What if we made it pull the accessible name/label/text from the selected <option> and announce that? And authors won't have to use any aria for this kind of thing.

[scottaohara]

showing an img example instead would definitely be easier.

i'm not sure i entirely follow your custom behavior idea. it'd still require some use of aria, or using the value attribute in a way it hasn't been used before?

so like, instead of using aria-hidden in the above, if someone waned their option to just be named 'heart', they'd have to do

<option aria-label=heart>
  ❤️ <span>heart</span>
</option>

or potentially?

<option value=heart>
  ❤️ <span>heart</span>
</option>

i wanna make sure i'm understanding this right before i comment further

[gregwhitworth]

@josepharhar friendly ping on this one