Improve tab keyboard interactions

[maggiewachs]

This is really a usability improvement or enhancement, less so a bug :)

Describe the bug The tab component's implementation of keyboard support is somewhat non-standard:

• after you select a tab, you have to Tab key/arrow through all tabs before accessing the selected tab's content (expected: after selecting a tab, the next Tab press moves focus to that tab's content)
• you can use both arrows and the Tab key to navigate among tabs (expected: one or the other, preferably arrows so that Tab can be reserved for accessing content re: previous point)
• Space bar does not select a tab, but should

To Reproduce Steps to reproduce the behavior:

1. Go to https://data.cms.gov/provider-data/dataset/0ba7-2cb0
2. Use the Tab key to access the tabs component (Data Table, Overview, API...)
3. Tab/arrow to traverse the tabs -- notice that arrows automatically select a tab, while the Tab key requires that you make a selection with Enter
4. Select the Overview tab
5. Use the Tab key again -- focus should move to "Download full dataset" button, but instead moves to the API tab

Expected behavior Use a managed focus pattern for the tabs component, where the user can Tab key to the tab list and then use arrows to make a selection. The method for selection should probably be either auto-selection (as it does now with arrow keys) or manual selection (Enter or Space bar to choose a tab). Once a tab is selected, the next Tab key moves focus to the selected content; shift+Tab then moves focus back up to the tab list. Example: https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-manual/

Desktop (please complete the following information):

• OS: Mac OS 14.5
• Browser: Chrome
• Version: 125.0.6422.142 (Official Build) (arm64)

Additional context It would probably help to include interactive elements in the tab examples, too, to show how focus moves.

[zarahzachz]

A ticket in Jira was created.

Part of the hold off on implementing these changes revolves around the potential for a Tab refactor.

Outstanding issues with the current Tab implementation:

• Disabled tabs don't make sense and present accessibility concerns. Look into why this was implemented, but thoughts lean towards this being deprecated.
• Tabs rely on "fake" links - they make use of the hash syntax (<a href="#foo">Tab 1</a>) that doesn't actually use the History API. For instance, navigating to www.thisisalink.com/#tab2 should take a user to a view of www.thisisalink.com where the 2nd tab is active. This does not work.