Content switcher and tab selection should be based on explicit selection instead of on navigation

[asudoh]

From @aagonzales at #5580 (comment):

We'd want tabpanel content to be shown when the button is "pressed" so that the user can easily cycle through the tab options before reading/navigation the tabpanel content.

From @carmacleod in the same issue:

But there's a bit more to it than that... ;)
Here's the tabpanel pattern in the APG (also called Tabs).
Please read through all of section 3.23 Tabs (including the Examples, Keyboard Interaction, and ARIA Roles, States and Properties subsections) and decide if it's what you are creating.
If you go with this pattern, please carefully re-read that section about WAI-ARIA Roles, States, and Properties to make sure you get the aria markup just right, because screen readers are picky. ;)

The 2 example pages show slightly different keyboard handling, depending on whether or not the tabpanel content is shown when the button is "selected (focused)" or when it is "pressed" - you decide which one to use after reading the pattern information (fyi, your codepen example works like the "Manual Activation" one, which may or may not be what you want for your production content switcher). Remember to add arrow key handling for the buttons if you are going with this pattern (i.e. instead of using tab key; i.e. the buttons need tabindex="-1" when they're not selected). Screen reader users will expect arrows to work as soon as they hear they are in a tablist or tabpanel, and keyboard users will know to use arrow keys to change the content, and they will expect that using the tab key navigates to the content instead of tabbing through all of the tabs in the tablist before getting to the content.

After trying out the examples, please scroll further down the example page to see the actual Keyboard Support for each example, followed by the Role, Property, State, and Tabindex Attributes used in the example, followed by the Source Code.

[joshblack]

When talking to @aagonzales, it seems like we might want to offer both behaviors (automatic and manual activation) as variants as we might suggest one type of mode over another in different contexts. How does everyone feel about this??

cc @dakahn @carmacleod

[carmacleod]

@joshblack

it seems like we might want to offer both behaviors (automatic and manual activation) as variants

Makes sense to me. Leave it up to consumers of the component to choose based on their needs.
Which one would you choose as the default behavior?