Horizontal tabs: Down and Up Arrows usage not allowed

[vaiFaW]

Prerequisites

• [X] I have searched for duplicate or closed issues
• [X] I have validated any HTML to avoid common problems
• [X] I have read the contributing guidelines

Describe the issue

According to the W3C tabs pattern: When a tab list has its aria-orientation set to vertical: Down Arrow performs as Right Arrow (moves focus to the next tab). Up Arrow performs as Left Arrow (moves focus to the previous tab). If the tab list is horizontal, it does not listen for Down Arrow or Up Arrow so those keys can provide their normal browser scrolling functions even when focus is inside the tab list.

These rules aren't supported by Boostrap 5 actually

Reduced test cases

It's possible to check these keyboard interactions in the documentation page https://getbootstrap.com/docs/5.3/components/navs-tabs/

What operating system(s) are you seeing the problem on?

Windows

What browser(s) are you seeing the problem on?

Chrome, Firefox, Microsoft Edge

What version of Bootstrap are you using?

v5.3

[marwenbenhajhassine]

A potential fix could involve dynamically adjusting the keydown event handlers based on the aria-orientation attribute of the tab component

[julien-deramond]

Thank you for reporting this issue, @vaiFaW

The current behavior of Navs and tabs with JavaScript is as follows:

• Horizontal Tabs:
  • Left and right arrows are supported, allowing users to switch from one tab item to another.
  • Top and down arrows are supported, allowing users to switch from one tab item to another, but this prevents vertical scrolling of the page.
• Vertical:
  • Left and right arrows are supported, allowing users to switch from one tab item to another.
  • Top and down arrows are supported, allowing users to switch from one tab item to another.

Based on my understanding of the keyboard interaction rules in Tabs Patterns, the only modification we would need to implement is to remove the support for top and down arrows when the tab is horizontal. This would allow the top and down arrows to scroll the page vertically.

@patrickhlauke, would this change be acceptable or mandatory?

If so, we can proceed to review https://github.com/twbs/bootstrap/pull/40643.

[patrickhlauke]

From the last time I tested it, most screen readers didn't actually announce the orientation of a tablist. So a user lands on a tab inside a tablist, but they're not told whether it's horizontal or vertical. So having the doubled-up key events here was to make sure that regardless of orientation, SR users would be able to easily move between tabs, without having a 50/50 chance of their initial keystrokes just being ignored ("let me go right ... oh, that didn't do anything ... maybe the tab list is vertical, let me try going down").

in short: while it's correct to say that depending on aria-orientation you can just listen to either left/right or up/down, in reality aria-orientation is currently not well supported/announced by SRs so to avoid confusion general advice is to double-up listeners regardless.

[patrickhlauke]

These rules aren't supported by Boostrap 5 actually

note that ARIA APG patterns aren't rules, or a standard. they're suggestions, and a large chunk of the APG patterns are known to be broken, incomplete, or just plain bad.

[julien-deramond]

The rule for a non-SR keyboard user seemed acceptable and interesting. However, based on the feedback provided by Patrick in https://github.com/twbs/bootstrap/issues/39969#issuecomment-2241035192, if there's no way to ensure that all screen readers announce the orientation of a tablist, it seems better to maintain the current behavior. Therefore, I would support keeping the existing functionality.

[julien-deramond]

Thanks again for reporting this issue. Based on the elements shared by Patrick, unfortunately we won't be able to modify the current behavior to handle this use case, as it would be an issue for some SRs users. We think it's safer this way. So I'm closing this issue and the associated PR.

[ac-mmi]

From the last time I tested it, most screen readers didn't actually announce the orientation of a tablist. So a user lands on a tab inside a tablist, but they're not told whether it's horizontal or vertical. So having the doubled-up key events here was to make sure that regardless of orientation, SR users would be able to easily move between tabs, without having a 50/50 chance of their initial keystrokes just being ignored ("let me go right ... oh, that didn't do anything ... maybe the tab list is vertical, let me try going down").

in short: while it's correct to say that depending on aria-orientation you can just listen to either left/right or up/down, in reality aria-orientation is currently not well supported/announced by SRs so to avoid confusion general advice is to double-up listeners regardless.

I appreciate your feedback on my pull request regarding the differentiated keydown responses based on the aria-orientation attribute. I would like to provide additional context and clarification on the practices involved and the benefits of this approach.

Users generally expect different keyboard interactions based on the orientation of navigation components. For horizontal tablists, the left and right arrow keys are used to navigate between tabs, while the up and down arrow keys scroll the page. For vertical tablists, the up and down arrow keys navigate between tabs. This differentiation improves the intuitiveness and usability of our navigation system. Also my implementation respects the default behaviors for horizontal tablists (left/right for navigation, up/down for scrolling). This ensures that users who rely on conventional navigation methods are not confused if aria-orientation is not specified.

[patrickhlauke]

sure, but as i said: even if you do add aria-orientation="vertical", blind screen reader users won't be told that they're in a vertical tab list...so they'll try to use left/right cursor keys, and nothing will happen for them. unless they then guess "oh, maybe it's vertical?" and use up/down cursor keys. doubling up the key presses, while not ideal, at least ensures that there's no surprises either way for SR users.

[ac-mmi]

@patrickhlauke Proposed Balanced Solution To address both the standard practices and the current limitations of screen readers, I propose the following enhancements to my pull request:

1. Dual Key Event Handling:

• Implement event listeners for both left/right and up/down keys, ensuring that regardless of the aria-orientation, users can navigate tabs without confusion.

2. Conditional Default Prevention:

• Prevent the default scrolling behavior of up/down keys only when they are used for tab navigation in a vertical tablist. This ensures that up/down keys still scroll the page in a horizontal tablist but navigate tabs in a vertical tablist.