[APP-527] feat: add keyboard nav to advanced filter drag and drop#3213
[APP-527] feat: add keyboard nav to advanced filter drag and drop#3213mcmcgrath13 wants to merge 9 commits into
Conversation
mcmcgrath13
requested review from
emyl3 and
krista-skylight
and removed request for
a team
|
(❓, maybe b) It feels like we should override the default of scrolling when we hit the spacebar when we're focused on that element to toggle it. What do you think, Mary? screen_recording.mov |
Nice find! pushed up a fix |
| }; | ||
|
|
||
| return ( | ||
| <span |
There was a problem hiding this comment.
Thank you for addressing the other issue! 🤩
(❓) Another thing that came up... If a user tabs away from the drag and drop toggle with the toggle being on and then they return to it, the toggle is still on which could be confusing.
Question 1: Should we auto turn off the toggle when they navigate away? Or leave it on?
There's nothing that seems to indicate it is on/off visually and with like an aria-label or something like that. I also tried navigating this using Mac's VoiceOver utility and nothing was obvious.
Question 2: Should we add something here to address this visually and not visually? (Or would that be a separate ticket?)
There was a problem hiding this comment.
Excellent question! I'm going to work on making this match the experience for keyboard nav drag and drop on the patient search column preferences
|
| import styles from './VisuallyHidden.module.scss'; | ||
|
|
||
| // From https://www.joshwcomeau.com/snippets/react-components/visually-hidden/ | ||
| // Display text for screen readers only, but in dev mode can hold `Alt` to display the value |
| const [isActive, setIsActive] = useState<boolean>(activeId === id); | ||
| const { getQuery, dispatchQuery } = props.schema; | ||
|
|
||
| // When a rule group changes level, the component re-mounts and we need to move focus |
There was a problem hiding this comment.
I see why we need to re-focus... From my testing around, it looks like doing that is causing this message to be read again in VoiceOver which means that the message of moving the element can get missed...
There was a problem hiding this comment.
We could leave that as hidden description text in the front matter of the section, but not make it describe each drag handle? That relies on the user going through that content on the way to the widget - not sure if that's a better or worse UX as I can argue it either way @kenieh any thoughts here?
2 participants
Description
Add keyboard-nav drag and drop to the advanced filter builder
Notes:
Tickets
Checklist before requesting a review