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.
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:
_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:

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?
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.
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?
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:
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
Most helpful comment
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