-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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.
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
[Unified Search] Improve accessibility of flex width comboboxes #171439
Conversation
- use `:has` rather than `:focus-within` for determining when the combobox should be embiggened, so that the dropdown arrow focus doesn't trigger the increase
- can be reverted once elastic#170716 merges
@@ -26,9 +26,13 @@ export const fieldAndParamCss = (euiTheme: EuiThemeComputed) => css` | |||
.euiFormRow { | |||
max-width: 800px; | |||
} | |||
&:focus-within { | |||
// Expand the combobox if the dropdown is open or the input has focus | |||
&:has(input[aria-expanded='true'], input:focus) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick note: I'm aware that latest production Firefox currently does not support :has
(caniuse link), however it will by release 120 (slated for mid December), and it also works when the experimental flag is enabled.
IMO, this is reason enough to move forward with :has()
especially as I see the flex width UX as a progressive enhancement (it's nice to have to show more text, but not a must have).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with moving forward on using the has()
selector. Showing more text is exactly the spirit of progressive enhancement, and leaves no one with a less-usable experience. Great call Cee!
💚 Build Succeeded
Metrics [docs]Async chunks
HistoryTo update your PR or re-run it, just comment with: |
Thanks for taking this on @cee-chen. I thought we were going to get rid of this workaround (expand input width on focus) with the release of |
Oh, I had no idea! That would be even better!! :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice improvement! Thank you 🥇
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 The focus landing on the Open combobox button is a marked improvement for UX. I was able to traverse backwards using they keyboard + screenreader, hear the selected item, and open the combobox in one move. This pattern has a small level of user discovery required, but I feel will be internalized quickly.
@@ -26,9 +26,13 @@ export const fieldAndParamCss = (euiTheme: EuiThemeComputed) => css` | |||
.euiFormRow { | |||
max-width: 800px; | |||
} | |||
&:focus-within { | |||
// Expand the combobox if the dropdown is open or the input has focus | |||
&:has(input[aria-expanded='true'], input:focus) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with moving forward on using the has()
selector. Showing more text is exactly the spirit of progressive enhancement, and leaves no one with a less-usable experience. Great call Cee!
We talked about whether to remove this or not and the answer was that the unified search can keep the flex-width solution as it has another small benefit of showing the currently selected value text |
This seems reasonable to me @cee-chen! |
To be honest, knowing now that removing this flex behavior is an option - I'm not sure I consider this benefit enough to keep it in 😅 Especially with recent EuiComboBox plain text changes (that will land in Kibana main with #170716), the selected text will always be visible to users the same way a text input is (via arrow keys): I'd love to instead move forward with Andrea's proposal of removing the behavior totally combined with |
@cee-chen @timductive I implemented the Nov-22-2023.14-20-48.mp4 |
I love it! You can also use |
@timductive @andreadelrio @mbondyra @nickofthyme Hey all. Cee is OOO for the next couple of weeks and I just wanted to close the loop on this one. It sounds to me like this combo box will be changing to use a combination of Changing to this new behavior will solve the core accessibility issue that this PR was meant to address, making this PR unnecessary. For that reason, I'm going to close this PR. If I've misstated anything in the above, please let me know and we will re-open this PR. |
Summary
.blur()
ing focus from the combobox was done for the custom flex/width behavior, but is an accessibility issue as it strands focus for keyboard and screen reader users (see elastic/eui#7279).I've worked around this by focusing the dropdown arrow toggle button instead of blurring focus, and modifying the CSS selectors from
:focus-within
to:has
to only expand the combobox width on input focus. This has the added bonus of removing an unnecessary extraonFocus
workaround (see elastic/eui#7170).While here, I also noticed a bug with a disabled cursor appearing that I fixed.
Checklist
[ ] Unit or functional tests were updated or added to match the most common scenariosNone found