-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Add basic styling to TabPanel
component
#13587
Comments
It looks like we might also want to actually use this component in our codebase. It seems like Document and Block tabs in the Settings Sidebar would be a good fit. This is how it looks as of today: |
👋 The TabPanel docs suggest the following behavior:
Currently, the component allows you to navigate between tabs using the arrow keys. A small modification would allow for navigation with the tab key, but right now it's prevented. I added styles (per #14956) and tested this in the playground: The behavior is different in Settings sidebar panel. Tabbing alters the focus, but hitting return is required to change the active state and panel: Should we change the component behavior to match the sidebar behavior? I.e. should this extra keystroke be implemented in the component to switch the active panel? |
* Add styles to the component itself * Add aria-label prop to the TabButton * Replace markup with TabPanel component in edit settings sidebar header
WAI-ARIA recommends the keyboard navigation behavior that the
Opened a PR that introduces styles (mostly written by @youknowriad) and replaces the sidebar settings header with this component. |
Adding a11y feedback label to answer the question:
|
Reakit's Tabs manage focus with the arrow keys, so I think perhaps that is the preferred method. https://reakit.io/docs/accessibility/ |
In today's Design Team slack triage, we noticed that this issue has some design solutions but is going to be heavily influenced by a11y. So I'm removing the design feedback label for now and I've encouraged @enriquesanchez to bring this up in the next a11y meeting. |
Adding this issue to tomorrow's accessibility meeting agenda. Will report back once we have feedback. |
This was discussed during today's Accessibility team meeting. I encourage everyone interested to review the discussion in Slack, given that there does not seem to be a straight answer for our particular case. That being said, I'll attempt to summarize what the team discussed. If this TabPanel component will only be used in the editor sidebar, then the general consensus is don't change it. The main reasoning is that it's only two tabs. However, if this component will be used elsewhere and include more than two tabs, then adhering to the WAI-ARIA best practices is recommended. We also encourage consistency across WordPress. From the Slack conversation:
Here's a WAI-ARIA example that uses manual activation: https://www.w3.org/TR/wai-aria-practices-1.1/examples/tabs/tabs-2/tabs.html |
In #11944 @TimothyBJacobs fixed the issue with behavior of
TabPanel
component by usingButton
component. Howeve, it introduces another issue described by @jasmussen :The text was updated successfully, but these errors were encountered: