search

w3c / aria-practices

WAI-ARIA Authoring Practices Guide (APG)
https://www.w3.org/wai/aria/apg/
Other
1.21k stars 338 forks source link

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

Open patrickhlauke opened 2 years ago

patrickhlauke commented 2 years ago

As part of recent work to get tabs to behave correctly in Bootstrap (see https://github.com/twbs/bootstrap/pull/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:

https://user-images.githubusercontent.com/895831/162187567-8320181a-708e-4439-8f00-7fd644709cf8.mp4

Not shown in the video:

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 commented 2 years ago

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

JAWS bug: https://github.com/FreedomScientific/VFO-standards-support/issues/519#issuecomment-827550108

JAWS-test commented 2 years ago

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

JAWS bug: https://github.com/FreedomScientific/VFO-standards-support/issues/491

JAWS-test commented 2 years ago

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 commented 2 months ago

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.

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