[Bug][a11y]: Screen reader users perceive no distinction between horizontal and vertical orientation

[dineshy87]

Code of conduct

• I agree to follow this project's code of conduct.

Impacted component(s)

Tabs

Expected behavior

Since we can't rely on screen readers announcing the tablist orientation to determine whether to use ArrowUp/ArrowDown instead of ArrowLeft/ArrowRight. Both ArrowUp and ArrowLeft should work to navigate to the previous tab, and both ArrowDown and ArrowRight should work to navigate to the next tab.

Actual behavior

With focus on a Tab, a screen reader user would have to guess the orientation to figure out which arrow keys will work to navigate to the next or previous Tab.

Screenshots

No response

What browsers are you seeing the problem in?

No response

How can we reproduce this issue?

No response

Sample code that illustrates the problem

No response

Logs taken while reproducing problem

No response

[najikahalsema]

To address this issue, one should follow these steps:

1. Write or amend the tests in tabs.test.ts which test for keyboard-based selection for both horizontal and vertical orientations. For both tests, make sure to test that both arrowUpEvent()/arrowLeftEvent() and arrowDownEvent()/arrowRightEvent() work as valid selection processes.
2. The changes need to be made to FocusGroup.ts which RovingTabIndex.ts exends and which the Tabs depend on. In FocusGroup.ts, it makes a distinction between the direction set by the components and approves the keyboard events that way.
   ** Note that the RovingTabIndexController is used in multiple components, so it would be wise to make sure that no other components are impacted/the way they are impacted is in line with expected a11y behaviours.

[Rajdeepc]

@TarunAdobe Please link your PR here before moving this to Peer review. Thanks

[TarunAdobe]

PR: #3410

[Westbrook]

@dineshy87 can you help me to understand your suggestions here:

1. Does aria-orientation not apply here?
2. If so, could we add it, or correct it’s application, rather than opening both axis of arrow keys to visitors?
3. If not, is that because it is faulty in conjunction with tab lists or it is faulty more generally?
4. If more generally, should we not use it, or prepare for those short comings, in other patterns?

This info will empower a choose your own adventure path to correcting this issue:

If we can use aria-orientation, it may make sense to move the application of that attribute into the Focus Group controller.

In the case that we need to change the Tabs interaction, we can likely leverage the both option in the Roving Tab Index controller, rather than changing how the controller works a large.

In the case that aria-orientation should be less broadly leveraged, we may want to put additional restrictions on the Focus Group API.

[dineshy87]

aria-orientation is very much applicable as per spec, but not consistently dependable across different screen readers. Which is why having both ways of navigating will be helpful. We are giving the same recommendation for react-spectrum as well.

[Westbrook]

Good to know. Does that means in all contexts where we move to group navigation via arrow keys we'd need to surface support for left/right AND up/down, or is this lack of dependability specific to tab list?

Related, is there any central documentation to this point that we could point to in some code comments so that if we can save our future selves some time when the code changes needed here are revisited in the future.

[dineshy87]

I am making the recommendation from some testing across screen readers. For other contexts, the question is again whether the spec itself supports aria-orientation or not, and if screen readers and browsers actually convey the orientation or not when it is vertical. I see no problems with supporting both ways. @majornista what do you think?

[majornista]

Good to know. Does that means in all contexts where we move to group navigation via arrow keys we'd need to surface support for left/right AND up/down, or is this lack of dependability specific to tab list?

Related, is there any central documentation to this point that we could point to in some code comments so that if we can save our future selves some time when the code changes needed here are revisited in the future.

I'd say it depends on the role. The WAI-ARIA spec has a note about this that states:

NOTE
In ARIA 1.1, the default value for aria-orientation changed from horizontal to undefined. Implicit defaults are defined on some roles (e.g., slider defaults to horizontal; scrollbar defaults to vertical) but remain undefined on roles where an expected default orientation is ambiguous (e.g., radiogroup).

The WAI-ARIA Authoring Practices Guide provides guidance for keyboard behavior based on aria-orientation depending on the design pattern for a role:

For example for tablist, https://www.w3.org/WAI/ARIA/apg/patterns/tabs/#keyboardinteraction, the keyboard interaction guidance states:

When focus is on a tab element in a horizontal tab list:

• Left Arrow: moves focus to the previous tab. If focus is on the first tab, moves focus to the last tab. Optionally, activates the newly focused tab (See note below).
• Right Arrow: Moves focus to the next tab. If focus is on the last tab element, moves focus to the first tab. Optionally, activates the newly focused tab (See note below).

And in the note it says:

2. When a tab list has its aria-orientation set to vertical:

   1. Down Arrow performs as Right Arrow is described above.
   2. Up Arrow performs as Left Arrow is described above.

3. 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.

[Westbrook]

@majornista the APG notes seem to align to what we have currently, but do not align with the x-context issues that @dineshy87 has outlined.

The current suggestion in this issue seems to be that Tabs should include aria-orientation, but allow for up/down AND left/right interactions, regardless of the actual orientation, to support screen reader issues.

Do we only change Tabs and leave other patterns to be reviewed/changed later, or does the lack of full screen reader support point to ALL orientation based keyboard interactions allowing both up/down AND left/right at all times?

[majornista]

@Westbrook I think both Down/RightArrow and Up/LeftArrow would be preferable for a tablist with aria-orientation="vertical". For something like menubar, the orientation is more meaningful because a menubar and its submenus are navigable in 2 dimensions and they would need to behave differently depending on the orientation.