When working on T350424 and revisiting Tabs, I've identified a inconsistency with Arrow keys behaviour. In horizontal Tabs only Left and Right arrow keys should be captured for Tab navigation.
Up and Down arrow should remain same functionality.
Currently, while Up arrow scrolls the page, down arrow doesn't when a Tab is focused.
Let Down arrow untouched (not listened to) to remain its normal behaviour (scrolling the page)
It's fine to discuss changing the existing behavior of the Tabs component, but I want to be clear that the current behavior is not an accident – the component was deliberately implemented this way.
When I wrote the initial version of the Codex Tabs component, I followed the recommendations that Heydon Pickering outlined in his Inclusive Component's ebook. You can see the section on keyboard interaction here: https://inclusive-components.design/tabbed-interfaces/#keyboardbehavior.
I've included some of the relevant information here:
A problem reading panels
Now that pressing Tab bypasses the tabs, it's trivial for keyboard users to move focus to the first of any links or other interactive elements in the open panel.
The experience for screen reader users is not currently as optimal. Although they too can focus elements inside the panel directly from the selected tab, blind users cannot see any content that comes before or after that interactivity. If there is no interactive content in the panel at all, they will unwittingly focus the first interactive element outside and below the tab interface.
In the operation of screen readers like NVDA and JAWS, the down arrow moves the user to the next element (focusable or otherwise) and reads it out. Without intervention, this would be the next tab in the tablist. Instead, we can intercept the down arrow key press and move focus programmatically to the open panel itself, making sure it isn't missed.
In our implementation, the down arrow key will focus the <Tab> component that is currently active (all <Tab> components have tabindex="-1" set for this purpose).
My recommendation would be to actually leave the code as it is currently (and to close this task). Then whenever we end up doing the audit with AFB, we would be able to learn whether the measures taken here to help screen-reader users are actually helpful in practice, or if we are better off simply removing this additional behavior (presumably as part of a follow-up task or epic listing a bunch of fixes we'd want to do).
Will wait for @Volker_E to weigh in but I'd be ok with declining this task if the current behavior is intentional.
The keyboard navigation behavior was deemed correct by the AFB in the results captured in T359085.