A11y discussion: Combobox / MultiSelect Gray onHover contrast #7929
-
BackgroundIt was brought to our attention by an Accessibility expert that our current design when a user hovers over one of the options but it is not selected is too similar to an option that is selected. Testing / ReplicateTo see this, type 2 and then Enter (Option 2 is selected). Now type down arrow. Option 3 currently has focus, but it looks almost the same as Option 2 except for the checkmark.
Ask / Discussion:
Potential Solutions
|
Beta Was this translation helpful? Give feedback.
Replies: 10 comments 20 replies
-
|
Beta Was this translation helpful? Give feedback.
-
Other thoughts:
|
Beta Was this translation helpful? Give feedback.
-
|
Now I'm wondering if you @andreancardona mistyped. Did you mean "Get rid of the on That is what I'm seeing in the browser selects. Chrome Safari Firefox |
Beta Was this translation helpful? Give feedback.
-
|
@andreancardona is this actually violating an accessibility rule? Why isn't the checkmark a sufficient indicator for selection? |
Beta Was this translation helpful? Give feedback.
-
|
I had the same question in the accessibility combobox PR. As far as I know, revising this design could help low vision users, but I don't think it is actually violating an accessibility rule. Going to tag @dakahn to weigh in more on this when you have some time. |
Beta Was this translation helpful? Give feedback.
-
|
Ok I read through that issue a little better. Seems like some people are saying its better to have a stronger emphasis on the hovered/focus item than the selected item. So I guess they are implying that the checkbox is sufficient and doesn't need a background to help differentiate it. |
Beta Was this translation helpful? Give feedback.
-
|
@andreancardona Is the bigger problem actually that the keyboard hover needs a visual indicator that passes 3:1 ? |
Beta Was this translation helpful? Give feedback.
-
|
so it sounds like it's more of a keyboard user issue, right? so when a user uses the arrow keys to switch an item, the hover is close to the selected. so maybe it's more of a problem when using a keyboard and trying to select something that's right next to the thing that is selected. the other issue it seems mike gower has is the contrast with the background. i see that our dropdown does have enough contrast because the menu is a select state but combobox does not because of what is selected: essentially mike gower is looking for something like this really quick mock up (the active state gets a little weird with combobox since the field is actually selected but included a version like dropdown even though it's not technically correct — just to look at): |
Beta Was this translation helpful? Give feedback.
-
|
These are all the other components I could think of that use a selected darker background. So right now dropdown is following the system. If we change dropdown to not include a background change would we want change it everywhere?
|
Beta Was this translation helpful? Give feedback.
-
|
Honestly, if is nots breaking an actual accessibility rule I think we should keep it to match the system. If we think there needs to be a better distinction between the hover and selected then I think we need to look at that across these components. |
Beta Was this translation helpful? Give feedback.
-
|
What other components would need this:
|
Beta Was this translation helpful? Give feedback.
-
|
Maybe auditing selected/hover states in all our components and seeing if there are better options is an effort we should focus on in our next major release. In my opinion, the hover/selected color difference has always felt weird to me bc it's so subtle, esp when navigating via keyboard, it looks so similar. Also, when an item is selected and it's being hovered on, there is not background change, which also doesn't seem right. On selectable data table, we still have the selected row change bg color when it's hovered on. I think, it is also important to note that some a11y testing needs to be done manually, which means that even if the Accessibility Checker doesn't throw and error, it doesn't mean that the component is 100% accessible inherently. I was trying to test this against different color blindness, but also wanna do more research as to how this affects keyboard users. My first thought, is that something that might help is to have the focus on the menu item when navigating via keyboard instead of the input like we do for OverflowMenu. I thought we did this, but maybe I was wrong or it changed. If it did change, I'd love to know more about why (if it was related to an a11y thing or a design change). I'd expect, that when I'm arrowing up or down through the items, they would have a focus border, but they don't. I think this would be more effective for keyboard users than just the bg hover change. As far as for mouse users, I'm not sure what would be a good fix since I wouldn't want a focus border when actually hovering. |
Beta Was this translation helpful? Give feedback.
-
There should be a background hover change, we have a token |
Beta Was this translation helpful? Give feedback.
-
This was the original design intent but it was changed for a11y reasons. I would like to know more about this as well. Why does the focus stay on the list-box and not move to each item? I honestly get a little confused when focus get trapped in an area and you use arrow keys instead of tabs to navigate. What is that called if not focus? Active? |
Beta Was this translation helpful? Give feedback.
-
The background change is a second indicator. All selected items (except ghost button) have a check mark or selected bar to indicate so I don't see why its an accessibility problem. I don't see anywhere where its a rule that hover and selected backgrounds have to have 3:1 contrast difference. In fact that would be pretty strong if it did. We'd have to go up to Gray60 to get that level of contrast. So it seems like an aesthetic choices. That's why I wonder if its just the style of the keyboard navigation state that is the true problem not hover and selected colors. |
Beta Was this translation helpful? Give feedback.
-
|
Just catching up on this conversation now. I'll try and provide some guidance if I can. I guess the first thing worth noting is that multiple selection in a listbox from an accessibility standpoint is generally inadvisable and a group of check boxes is always preferable if possible. With that said what we have here is both a UX problem and an accessibility violation with our keyboard users getting the short shrift. As a quick aside -- something that may help is to stop considering MultiSelect as one singular component and think of it more as a compound component. With two distinct sub-components: a button and a listbox. The user's focus moves fluidly between these two components and selections are made in one that are represented in another. So with the button (input) focused via tab the user then can use either space or enter to open the listbox. When the listbox is opened focus moves from the button to the listbox. At which point the user can use up or down arrow keys to navigate within the listbox and make their selection(s).
So now with the listbox opened and selections made we see this In fact if the keyboard user has closed and then reopened the listbox they'll have to hit down arrow 4 times before an active list item can be discerned as seen here Aside from a poor experience for our keyboard users we have a contrast violation. The selected state and the active state need a 3:1 contrast as per the guidelines for UI Distinguishability in the IBM Accessibility Requirements which state, "any visual enhancement that indicates a state change needs to maintain a 3:1 contrast ratio against the meaningful adjacent colors". |
Beta Was this translation helpful? Give feedback.
-
Exactly, it not necessary a "we need to change the background color" problem its a we need to give the active state a 3:1 indicator. We can definitely look into this. In V9 we had the active state identifiable by appling an underline to the active text. We can look into some other possible visual indicators that's not a background change.
If we only did it with a background color change this is what it would have to look like to get 3:1 which is not optimal.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for explaining all of that @dakahn ! |
Beta Was this translation helpful? Give feedback.
-
|
I can't react with emojis for some reason but 😸 I'm so psyched I could help out |
Beta Was this translation helpful? Give feedback.
-
|
Great explanation @dakahn ! Thank you 💯 |
Beta Was this translation helpful? Give feedback.
-
|
Here are some possible visual indicator options for the new
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for making these explorations! ⭐️ 🙌🏻 Thoughts on some of these:
I do like the outline versions 👍🏻. All blue or all black outlines looks clean to me. The all blue might resonate more with people since its keyboard navigation. |
Beta Was this translation helpful? Give feedback.
-
|
Question: Can I was just nothing in firefox search bar it has a more subtle
|
Beta Was this translation helpful? Give feedback.
-
|
They absolutely can! As long as they're separately distinguishable 👍🏽 |
Beta Was this translation helpful? Give feedback.
-
|
Oh nice! That actually makes things a lot easy there. And I think then we can have a bolder active state to help with keyboard nav. |
Beta Was this translation helpful? Give feedback.
-
Proposed solution for active state in list box@laurenmrice and I discussed in slack, we like this option. It keeps with our focus style, even though it's not technically focused. I will show it in Thursday's design crit to confirm with the rest of the team.
|
Beta Was this translation helpful? Give feedback.
-
|
@dakahn @andreancardona @jnm2377 do you think this would satisfy the accessibility requirement? |
Beta Was this translation helpful? Give feedback.
-
|
For keyboard users, yes. That's a lot more accessible than what we currently have. @dakahn is the focus on the whole menu still needed? I feel like it would make more sense to just have the focus on the active item rather than the whole menu. @aagonzales Would this border be applied on hover, as well, for mouse users? Otherwise, the low contrast would still be an issue if we keep the current hover color. |
Beta Was this translation helpful? Give feedback.
-
|
No, the hover would stay as is without the blue border. I think its less of an issue with mouse hover because the user will be pointing at each item themselves so I don't think it gets lost anywhere. Also I don't think hover has to pass 3:1 otherwise basically the entire internet would do it wrong. |
Beta Was this translation helpful? Give feedback.
-
|
That would be a really great improvement! Would be way more usable and accessible for non mouse users. 👍🏽 |
Beta Was this translation helpful? Give feedback.
Proposed solution for active state in list box
@laurenmrice and I discussed in slack, we like this option. It keeps with our focus style, even though it's not technically focused. I will show it in Thursday's design crit to confirm with the rest of the team.