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

[EuiButtonGroup] Keyboard navigation through items #8033

Closed
smith opened this issue Sep 20, 2024 · 8 comments
Closed

[EuiButtonGroup] Keyboard navigation through items #8033

smith opened this issue Sep 20, 2024 · 8 comments

Comments

@smith
Copy link
Contributor

smith commented Sep 20, 2024

Describe the problem

When using keyboard navigation and tabbing in to an EuiButtonGroup, you should be able to use the arrow keys to navigate between the items

This component should behave according to the Toolbar pattern in the ARIA Authoring Practices Guide

To Reproduce

  • Go to a page with a button group
  • Press tab until the first item of the group has focus
  • Press left/right/home/end
    • Expected: The focus moves to the other items in the group
    • Actual: Nothing happens
  • Press tab
    • Expected: The focus moves to the next item past the button group
    • Actual: The focus moves to the next button in the button group

Proposed solution

Implement keyboard behavior that allows you to use the arrow keys within the list.

WCAG or Vendor Guidance (optional)

@cee-chen
Copy link
Member

I'm not convinced the component is a toolbar - that feels a touch too prescriptive for what's essentially a styled <header> element. Should all semantic headers have arrow key/tabstop behavior?

@smith
Copy link
Contributor Author

smith commented Sep 20, 2024

I'm not convinced the component is a toolbar - that feels a touch too prescriptive for what's essentially a styled

element. Should all semantic headers have arrow key/tabstop behavior?

I'm not saying the header is a toolbar, I'm saying the items in an EuiHeaderSection make up a toolbar.

So, in this Kibana header, these three buttons on the right, together, act as a toolbar:

Image

The idea of header sections makes sense, but I was a bit surprised that there were EuiHeaderSectionItems and EuiHeaderSectionItemButtons. I would have expected there to be a section that I put a button group in.

In most uses of the header there's a group of buttons on the right, and those are the ones that have a toolbar role.

@cee-chen
Copy link
Member

cee-chen commented Sep 24, 2024

I guess the thing I struggle with is that I don't see EuiHeaderSectionItem as having semantic meaning either - it's mostly presentational / handles aligning things horizontally and with the correct spacing, but that doesn't make it a toolbar necessarily (the same way that a <nav> element with multiple <a> links stacked horizontally would not have their own tab stop).

If we want to create a new semantic component called EuiToolbar or similar that would make a lot more sense to me at that point.

@cee-chen
Copy link
Member

@alexwizp Any chance you could weigh in on this as well? 🙏 I'd super appreciate your a11y expertise!

@smith
Copy link
Contributor Author

smith commented Sep 24, 2024

@cee-chen yes in this specific case it's arguable whether those are a "toobar" or just buttons next to each other. If you don't mind I'll update the issue to be specific to EuiButtonGroup.

In these cases it's clear that this is a composite component and all the buttons "belong" together in the group and you should be able to use left/right/home/end to move through them.

Image

@smith smith changed the title [EuiHeaderSection] Keyboard navigation through items [EuiButtonGroup] Keyboard navigation through items Sep 24, 2024
@cee-chen
Copy link
Member

cee-chen commented Sep 24, 2024

@smith We actually just went through this discussion fairly recently with EuiButtonGroup and moved away from this UX because it's misleading. Several of our accessibility engineers/contractors/the internet agreed:

@cee-chen
Copy link
Member

cee-chen commented Sep 24, 2024

My 2c: what constitutes a "toolbar" is content/context dependent and not something EUI can simply wholesale apply to presentational or functional components. We need consumers to make this determination themselves. My suggestion for toolbar/tab stop behavior would be an accessibility or utility helper, e.g.:

<EuiTabStop role="toolbar">
  <EuiButtonGroup options={...} />
</EuiTabStop>

@smith
Copy link
Contributor Author

smith commented Sep 24, 2024

I don't know if having behavior like radio buttons is the intention of the toolbar pattern. I don't feel all that satisfied about what, if any, conflict there is with the APG so I might ask around about some details.

I'll close this. Thanks for your input.

How about tabs? If I have one tab focused I would expect left/right would move the focus between tabs (radio button style, I guess.) That's not how EUI works. Should it?

@smith smith closed this as completed Sep 24, 2024
@smith smith closed this as not planned Won't fix, can't repro, duplicate, stale Sep 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants