Skip to content
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

Closed
macandcheese opened this issue Apr 13, 2023 · 11 comments
Closed
Assignees
Labels
4 - verified Issues that have been released and confirmed resolved. a11y Issues related to Accessibility fixes or improvements. bug Bug reports for broken functionality. Issues should include a reproduction of the bug. c-combobox Issues that pertain to the calcite-combobox and related components Calcite (design) Issues logged by Calcite designers. impact - p3 - not time sensitive User set priority impact status of p3 - not time sensitive p - low Issue is non core or affecting less that 10% of people using the library

Comments

@macandcheese
Copy link
Contributor

macandcheese commented Apr 13, 2023

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

  • Use Tab to focus Combobox - first chip's close button will be focused first.
  • Try to use Right Arrow to attempt to advance through Chip Close Buttons
  • Notice that the focus doesn't change
  • Use left arrow key, or tab again, and the right arrow will work.

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)

@macandcheese macandcheese added bug Bug reports for broken functionality. Issues should include a reproduction of the bug. 0 - new New issues that need assignment. needs triage Planning workflow - pending design/dev review. labels Apr 13, 2023
@github-actions github-actions bot added Calcite (design) Issues logged by Calcite designers. impact - p3 - not time sensitive User set priority impact status of p3 - not time sensitive labels Apr 13, 2023
@macandcheese macandcheese added the c-combobox Issues that pertain to the calcite-combobox and related components label Apr 13, 2023
@geospatialem geospatialem added p - low Issue is non core or affecting less that 10% of people using the library and removed needs triage Planning workflow - pending design/dev review. labels Jul 19, 2023
@geospatialem geospatialem added this to the 2023 December Priorities milestone Jul 19, 2023
@geospatialem
Copy link
Member

Related and could be approached together, possibly with chip-group as a refactor #6750 + #6777

@driskull
Copy link
Member

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

  1. tab or use arrow keys into the combobox
  2. Keep tabbing or using arrow keys until you get to the input
  3. type something
  4. try to use arrow keys to edit what you typed. (failure)

Would this be a separate or related issue?

@driskull
Copy link
Member

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.

@paulcpederson
Copy link
Member

paulcpederson commented Jun 17, 2024

@paulcpederson could you confirm if this is expected or a bug?

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.

This is a component that could benefit from aria-activedescendant as well.

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.

@driskull
Copy link
Member

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.

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 setFocus on the combobox will always focus the text input. However, we may want to consider focusing the first focusable element which in some cases would be the first chip because it has a tabindex. So we should discuss removing these tabindexes so this isn't an issue because focusing the input by default makes the most sense. The inconsistency here is because tabbing into the combobox produces different results than calling setFocus.

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.

Yeah that still may be an issue with the shadowDOM.

@driskull driskull self-assigned this Jun 17, 2024
@driskull driskull added 2 - in development Issues that are actively being worked on. and removed 0 - new New issues that need assignment. labels Jun 17, 2024
@driskull
Copy link
Member

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.

@driskull
Copy link
Member

driskull commented Jun 17, 2024

There seems to be no way to keyboard to the clear button on the combobox either. :(

Nevermind, escape key can clear it.

driskull added a commit that referenced this issue Jun 17, 2024
…ted (#9613)

**Related Issue:** #6776

## Summary

- When a chip is focused, the activeChipIndex is updated
- Only allow tabindex on one chip or the input.
- Adds tests
@driskull driskull removed their assignment Jun 17, 2024
@driskull driskull added 3 - installed Issues that have been merged to master branch and are ready for final confirmation. and removed 2 - in development Issues that are actively being worked on. labels Jun 17, 2024
Copy link
Contributor

Installed and assigned for verification.

@DitwanP
Copy link
Contributor

DitwanP commented Jun 17, 2024

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.

@driskull
Copy link
Member

driskull commented Jun 17, 2024

@DitwanP that is how it currently is. This issue was created #9614

https://codepen.io/driskull/pen/zYQpgvq?editors=1000

@DitwanP
Copy link
Contributor

DitwanP commented Jun 17, 2024

🍭 Verified locally on dev I can now use arrow keys to navigate immediately after tabbing into combobox.

@DitwanP DitwanP closed this as completed Jun 17, 2024
@DitwanP DitwanP added 4 - verified Issues that have been released and confirmed resolved. and removed 3 - installed Issues that have been merged to master branch and are ready for final confirmation. labels Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4 - verified Issues that have been released and confirmed resolved. a11y Issues related to Accessibility fixes or improvements. bug Bug reports for broken functionality. Issues should include a reproduction of the bug. c-combobox Issues that pertain to the calcite-combobox and related components Calcite (design) Issues logged by Calcite designers. impact - p3 - not time sensitive User set priority impact status of p3 - not time sensitive p - low Issue is non core or affecting less that 10% of people using the library
Projects
None yet
Development

No branches or pull requests

6 participants