Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve accessibility of <selectedoption> example #1079

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Improve accessibility of <selectedoption> example #1079

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions site/src/pages/components/customizableselect.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -161,7 +161,7 @@ This example replaces the button which opens the listbox with an author provided

### Rendering the `<option>` differently in the button

This example uses the customizable `<select>` element with custom CSS to target it which renders the option differently in the listbox vs in the button.
This example uses the customizable `<select>` element with custom CSS to target it which renders the option differently in the listbox vs in the button. The contents of each `<option>` have a `<span aria-label>` in order to make the option get announced the same whether its copied into the `<selectedoption>` or being rendered in the dropdown.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


<div className="code-image-container">
<div>
Expand All @@ -171,10 +171,14 @@ This example uses the customizable `<select>` element with custom CSS to target
<selectedoption></selectedoption>
</button>
<option>
❤️ <span class=description>heart</span>
<span aria-label=heart>
❤️ <span class=description>heart</span>
</span>
</option>
<option>
🙂 <span class=description>smile</span>
<span aria-label=smile>
🙂 <span class=description>smile</span>
</span>
</option>
</select>
<style>
Expand Down