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

Add basic styling to TabPanel component #13587

Closed
gziolo opened this issue Jan 30, 2019 · 8 comments · Fixed by #20872
Closed

Add basic styling to TabPanel component #13587

gziolo opened this issue Jan 30, 2019 · 8 comments · Fixed by #20872
Assignees
Labels
[Feature] UI Components Impacts or related to the UI component system [Status] In Progress Tracking issues with work in progress

Comments

@gziolo
Copy link
Member

gziolo commented Jan 30, 2019

In #11944 @TimothyBJacobs fixed the issue with behavior of TabPanel component by using Button component. Howeve, it introduces another issue described by @jasmussen :

It doesn't seem like we're using this component anywhere in Gutenberg itself. It really seems like it should come with some basic styles, and I'm essentially echoing @aduth here. This is because the Button component unsets the appearance and border of the button, so it's really quite bare.

But maybe that shouldn't hold up this PR if it fixes an issue? Not sure, and not sure how I can review this from a design perspective as there doesn't seem to be a design.

To put it more simply, if the above was the design we intended for the TabPanel component, it would not be shippable. But this could be a separate task, to improve that, as mentioned.

@gziolo gziolo added the [Feature] UI Components Impacts or related to the UI component system label Jan 30, 2019
@gziolo gziolo added the Needs Design Needs design efforts. label Jan 30, 2019
@gziolo
Copy link
Member Author

gziolo commented Jan 30, 2019

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:

https://github.com/WordPress/gutenberg/blob/master/packages/edit-post/src/components/sidebar/settings-header/index.js#L32-L53

@jffng
Copy link
Contributor

jffng commented Jul 15, 2019

👋 The TabPanel docs suggest the following behavior:

Users can navigate between tabs by tapping the tab key on the keyboard.

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:

Screen Recording 2019-07-15 at 11 20 AM

The behavior is different in Settings sidebar panel. Tabbing alters the focus, but hitting return is required to change the active state and panel:

Screen Recording 2019-07-15 at 11 21 AM

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?

jffng added a commit to jffng/gutenberg that referenced this issue Jul 18, 2019
* Add styles to the component itself

* Add aria-label prop to the TabButton

* Replace markup with TabPanel component in edit settings sidebar header
@jffng
Copy link
Contributor

jffng commented Jul 18, 2019

WAI-ARIA recommends the keyboard navigation behavior that the TabPanel component implements:

Tab: When focus moves into the tab list, places focus on the active tab element . When the tab list contains the focus, moves focus to the next element in the page tab sequence outside the tablist, which is typically either the first focusable element inside the tab panel or the tab panel itself.

Opened a PR that introduces styles (mostly written by @youknowriad) and replaces the sidebar settings header with this component.

@davewhitley davewhitley added the Needs Accessibility Feedback Need input from accessibility label Jul 23, 2019
@davewhitley
Copy link
Contributor

Adding a11y feedback label to answer the question:

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?

@davewhitley
Copy link
Contributor

Reakit's Tabs manage focus with the arrow keys, so I think perhaps that is the preferred method. https://reakit.io/docs/accessibility/

@gziolo gziolo added the [Status] In Progress Tracking issues with work in progress label Aug 12, 2019
@karmatosed karmatosed added Needs Design Feedback Needs general design feedback. and removed Needs Design Needs design efforts. labels Aug 24, 2019
@mapk
Copy link
Contributor

mapk commented Feb 4, 2020

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.

@mapk mapk removed the Needs Design Feedback Needs general design feedback. label Feb 4, 2020
@enriquesanchez
Copy link
Contributor

Adding this issue to tomorrow's accessibility meeting agenda. Will report back once we have feedback.

@enriquesanchez
Copy link
Contributor

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:

For the record: in 5.3 we introduced ARIA tabs in the media modal, with manual activation

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] UI Components Impacts or related to the UI component system [Status] In Progress Tracking issues with work in progress
Projects
None yet
7 participants