-
Notifications
You must be signed in to change notification settings - Fork 539
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
Allow resetting the focus on SelectPanel #5261
Comments
Thanks @alondahari for the issue. Just additional notes for the triage session.
The flag inherently solves this just because it focuses on the first item not the previous one. I have to mention that though I am not sure if this is intentional. I'll confirm this behaviour with the accessibility team and provide an update here.
We need to first check this with accessibility to ensure this is an accessible pattern then we can triage this. |
Added to the SelectPanel feature improvements epic: https://github.com/github/primer/issues/3399, can you help me with the prioritisation. Does the epic have other features that you would like to see ship before this one? |
@siddharthkp thank you for looping us in!
This would be also order of priority for us atm. |
Thanks for that! I've moved this issue to Priority 1, the exact position is still TBD because some of the others are already work in progress |
Update: I checked this with accessibility and they recommend resetting the option to the first item. (Slack thread) Rather than making where to focus optional (first vs previous) we might need to fix the code and make sure it always resets to the first item. Should we mark this as "bug" @siddharthkp ? |
Just one comment, that we should make it so after more items have loaded the focus remains on the same "index" it was before. Unlike the workaround I just shipped, if you already used the keyboard to move down I'd expect the same position after we add more items. Here is how it currently behaves (behind a FF): te.mov |
@alondahari I am probably missing a great deal of context here so I appreciate any information 🙏🏻 - just wanted to ask if we have checked the original behaviour with accessibility before? Regardless where the focus is set, I am curious if loading the options dynamically and updating the list after is any chance considered distracting for both visual and screen reader users 🤔 |
👋 There are 2 scenarios to consider:
Need to verify if this is how it behaves with the feature flag on. If not, that's a bug @alondahari, looking at your video from #5261 (comment), it looks like the feature flag is not turned on, is that intentional? |
@siddharthkp sorry my comment above is pretty misleading. The video is with my hacky workaround, just to illustrate why it's not an ideal solution.
By "where it is" meaning the same index, not the same item, right? so if more items are added and before that the focus is on the 4th item down, after the items are added I would expect it to still be on the 4th item down, even if it's now a different item. |
@alondahari I'm curious to understand the reasoning behind your expectation that the focus remains on the same index as before. 🤔 I would personally think that it should be the same item (I'll double check with @siddharthkp to clarify his wording) after loading more items in the background. Mainly because after user navigates to a certain element, they might be about to make a selection and if we load new items and move focus to another item, even though the same index, this could be a distracting behaviour. Also, I wonder if loading new items above the current list is an accessible practise - as I mentioned in my previous comment. |
If we are loading more items above the focused item, we should not keep it focused since it's no longer the most relevant result and probably not close to any relevant result. I might see a possible approach of loading more and keeping only the focused item on top as the first result, but I have a feeling that would lead to some more jarring experience. @ohiosveryown wdyt should be the behaviour here? |
For the scenario i'm mentioning here of loading more items below the current items, it should not matter.
Sorry, this feels a bit off. Adding items that change the position of items seems a bit rough for user experience 😅 and probably not accessible?
This sounds like the 1st scenario of filtering items, and in my opinion, we should reset the focus to the first item. This also aligns with the screen reader announcements built into SelectPanel. (See #4968 for more info) Might be helpful to get some design and accessibility eyes on this as well |
We are updating the labels picker in issues to not have a loading state, but instead just add more items from the server as they are loaded. This is causing the previously focused item to still be highlighted even if there are newer, more relevant options:
cap.mov
I understand from @broccolinisoup that the
primer_react_select_panel_with_modern_action_list
would solve it, but it's still a bit of a ways out before it's rolled out. She suggested I opened an issue to add an API to update / reset the focus on the list.The text was updated successfully, but these errors were encountered: