Tab/tabpanel - aria-orientation/keyboard interactions and current browser/AT behavior

[patrickhlauke]

As part of recent work to get tabs to behave correctly in Bootstrap (see twbs/bootstrap#33079), a few observations.

aria-orientation and keyboard interactions

Support for aria-orientation is still not all that great: JAWS announces it, NVDA and VoiceOver/macOS don't. Not tested TalkBack or VoiceOver/iOS, but suspect they don't announce it either. For this reason, we decided for Bootstrap to double-up the keyboard behavior (contrary to https://www.w3.org/TR/wai-aria-practices-1.2/#keyboard-interaction-21) and use both Left Arrow/Up Arrow and Right Arrow/Down Arrow to move to the previous/next tab respectively. It may be an idea to change the keyboard interaction in the spec to suggest this as well? Otherwise, a screen reader user who lands on a vertical tab is likely to be initially confused if left/right arrow keys suddenly don't work, since they've not been informed that it's a vertical tab list.

focusable tab panels and browser/AT weirdness

There's currently some funky behavior in both NVDA and JAWS, using Chrome and Firefox, with having the tab panel itself focusable.

See this video and the recap of what's happening:

tab-pattern.mp4

• Firefox/NVDA and Chrome/NVDA: setting focus from the tab to the tab panel, the panel is announced as "Agnes Obel property page" (the first part due to the aria-labelledby referencing the tab, no idea where the "property page" bit comes from though), followed by the whole contents of the tab panel. Using reading keys to proceed, the second paragraph of content is read/announced.
• Firefox/JAWS: setting focus from the tab to the tab panel, nothing at all is announced. Using reading keys to proceed, the second paragraph of content is read/announced, completely skipping the first paragraph. User has to go backwards to read the first paragraph.
• Chrome/JAWS: setting focus from the tab to the tab panel, "Agnes Obel" is announced (coming from the aria-labelledby). Using reading keys to proceed, the second paragraph of content is read/announced, completely skipping the first paragraph. User has to go backwards to read the first paragraph.

Not shown in the video:

• Safari/VoiceOver on macOS works as expected/correctly: setting focus from the tab to the tab panel, "Agnes Obel, tab panel" is announced. Using reading keys, it starts reading correctly from the first paragraph of the tab content.
• Chrome/VoiceOver and Firefox/VoiceOver on macOS: setting focus from the tab to the tab panel, the whole content of the tab panel is announced. The aria-labelledby is not announced. Proceeding with reading keys goes directly to the separator after the tab panel.

Overall then, the picture/experience is a bit mixed. Particularly the peculiarities on Windows with NVDA/JAWS (not announcing anything, skipping paragraphs) is concerning. It may be worth documenting/clarifying this (and yes, filing bugs with browser/AT vendors)

[JAWS-test]

Firefox/JAWS: setting focus from the tab to the tab panel, nothing at all is announced.

JAWS bug: FreedomScientific/standards-support#519 (comment)

[JAWS-test]

Using reading keys to proceed, the second paragraph of content is read/announced, completely skipping the first paragraph

JAWS bug: FreedomScientific/standards-support#491

[JAWS-test]

no idea where the "property page" bit comes from

In NVDA "property page" seems to be the role description for the parent element (regardless of the specific role). I.e. with this it is distinguishable that the tabpanel as parent element has a separate label and that the tabpanel contains child elements (the text) which is also output. Whether this makes sense is another question.

[patrickhlauke]

from re-testing just now, the aria-orientation is still not announced in any common browser/SR combination (NVDA, JAWS, Narrator with Chrome, Edge, Firefox; VoiceOver on macOS with Safari and Chrome).

In light of this, I'd suggest changing notes 2 and 3 in https://www.w3.org/WAI/ARIA/apg/patterns/tabs/ which currently give the impression that it's actually supported/announced - as currently, the experience for a tab list with aria-orientation="vertical" is: the user lands on the first tab, they are not told it's vertical, so they'll try to use the regular left/right cursor keys...and nothing happens.

2. When a tab list has its aria-orientation set to vertical:
   Down Arrow performs as Right Arrow is described above.
3. Up Arrow performs as Left Arrow is described above.
   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.

My pragmatic advice would be to "double-up" key handlers - regardless of orientation (which is not announced at the moment), have left and up perform the same, and right and down perform the same.