-
Notifications
You must be signed in to change notification settings - Fork 76
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
[Combobox] Using keyboard, cannot navigate Chip with arrow keys initially #6776
Comments
Once you type something into the input, the arrow keys no longer function. You can't go back to edit a character without deleting one. Is this intentional? Seems like a usability/accessibility issue? cc @geospatialem
Would this be a separate or related issue? |
This is a component that could benefit from aria-activedescendant as well. If we expect combobox to behave like a single component, then tabindex should only be active on a single element within it at any time. Arrow keys should be the primary form of navigation. I think this component needs some refactoring to handle that. |
Sorry I missed this, I think the behavior you discussed is a bug. I would expect to land on the input first when tabbing to the combobox with active tabs. Then arrows should always change the active element. That's just my 2¢, not sure if that is per the aria spec. Certainly when you have text entered into the input the arrow keys should either work as normal in an input or change the focus, in the pen they don't do either.
Yeah the combobox already uses active descendant, so likely would just be about extending that to encompass the chips. Unless browsers have updated since this was built, the challenge will be associating the active descendant id signifier across the shadow dom. That was impossible when this was built, but I haven't followed up in a while. |
I think we need to discuss the expected behavior of the combobox. I think what Paul said here makes sense but that would mean taking away tabindex from the chips and using some sort of aria to let screen readers know which chip or dropdown element is selected. Currently, calling
Yeah that still may be an issue with the shadowDOM. |
I think a roving tabindex might just be the solution here. Needs to have the chips tabindex set to -1 by default and make sure only one tabindex is 0 when navigating via keyboard. |
Nevermind, escape key can clear it. |
Installed and assigned for verification. |
Screen.Recording.2024-06-17.at.2.12.45.PM.mov@driskull Once tabbed in I can immediately navigate with the arrow keys, but when I type I can't move between letters with arrow keys like you can elsewhere. If this is what we want then its good to go, just LMK. |
🍭 Verified locally on |
Actual Behavior
Similar to but slightly distinct from: #6750
After tabbing into the group of Chips - I cannot use the arrows to navigate the chip's close button. I need to advance to the end of the tab row using tab until I can begin to use the arrows.
Expected Behavior
I would immediately be able to use Arrow Right to navigate through group of Chips
Reproduction Sample
https://codepen.io/mac_and_cheese/pen/MWPKWXY?editors=1000
Screen.Recording.2023-04-12.at.5.23.16.PM.mov
Reproduction Steps
Open Codepen
Reproduction Version
1.2
Relevant Info
No response
Regression?
No response
Priority impact
p4 - not time sensitive
Impact
@paulcpederson could you confirm if this is expected or a bug?
Esri team
Calcite (design)
The text was updated successfully, but these errors were encountered: