[A11y] [VPAT] 1.3.1 Info and Relationships - Search > Dev Tools - Tab groups should be a single Tab stop, traversed via arrow keys

[dave-gus]

Steps to Reproduce:

Pre-requisite:
User has created a Search project and gone to the homepage for that Search project.
Screen reader is activated.

Using keyboard navigation:

1. In left nav, select 'Dev Tools'
2. Navigate to tabs in main content (Console/Search Profiler/Grok Debugger)
3. Tab through the displayed tabs and observe keyboard navigation behavior

Expected Result:

• User uses tab key to navigate to the group of tabs and then navigates the tabs via arrow keys and selects via Enter/Space Bar. Screen reader informs user that it is a group of tabs and the state (selected, not selected) of each tab.

Actual Result:

• User uses tab key to navigate the tabs. The state of each tab is not conveyed.

This issue impacts:
1.3.1 Info and Relationships
2.4.3 Focus Order
4.1.2 Name, Role, Value (State is also an aspect of this SC)

WCAG or Vendor Guidance (optional)

• Understanding SC 1.3.1 Info and Relationships (Level A)
• Understanding SC 2.4.3 Focus Order (Level A)
• Understanding SC 4.1.2 Name, Role, Value (Level A)

[cee-chen]

This is interesting because it essentially gives the tabs the same UX as role="radio", and we recently moved away from that UX for EuiButtonGroup: #7101

EuiTabs feels fairly similar to an EuiButtonGroup in this regard, and I worry a little that since it looks like buttons, it would feel odd that it navigates via arrow keys and not tabs. See also:

• https://tink.uk/perceived-affordances-and-the-functionality-mismatch/
• https://lea.verou.me/blog/2022/07/button-group/

That beings said, both MDN and WCAG spec clearly use arrow key navigation:

• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/tab_role
• https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

So we should likely follow the spec 🤷