[Tabs extended media]: React wrapper – not able to access other tabs with VO instructions

Description

I am not able to select the second, third or fourth tab in Tabs extended or Tabs extended – with media using the keyboard and voice over on Desktop

VO instructs the user to press control + option + space to select a tab and it doesn’t work, I see no changes in the selected state (all tabs content are the same).

VO is also reading out the tabs as first tab: “1 of 8”; second tab “3 of 8”, which seems a bit strange? Is that the expected behavior and it’s indicating a tab has two sections, the heading and the content?

https://user-images.githubusercontent.com/45692622/150992704-43131f18-e298-4f7a-8800-d9b976e8616a.mov

This seems to be present in Production

Workaround

I am able to select other tabs by using: control + option + shift + down arrow, then control + option + space, then tab to navigate into the tab content area.

Component(s) impacted

Tabs extended Tabs extended with media

Browser

Chrome

Carbon for IBM.com version

1.15.0 rc 1

Severity

Severity 2 = Aspects of design is broken, and impedes users in a significant way, but there is a way to complete their tasks. Affects major functionality, has a workaround.

Application/website

Carbon for IBM.com

Package

@carbon/ibmdotcom-react

CodeSandbox example

https://carbon-design-system.github.io/carbon-for-ibm-dotcom/next/web-components-react/?path=/story/components-tabs-extended--default

Steps to reproduce the issue (if applicable)

No response

Release date (if applicable)

No response

Code of Conduct

• I agree to follow this project’s Code of Conduct
• I checked the current issues for duplicate issues

[proeung]

@kennylam I’m going to move this issue out of our Innovation Team queue as this is related to the WC React Wrapper and one that we’re not prioritizing at the moment.

[andy-blum]

Popping back into this issue after getting the request to review, and I’m feeling pretty confident that the issue described isn’t really an issue.

When using VO, the control+option combo is the the VoiceOver key, and that combo plus space is the equivalent of clicking. While nothing happens, this is working as intended. See the W3 keyboard interaction design pattern for tabbed interfaces.

• Tab:
  • When focus moves into the tab list, places focus on the active tab element.
  • When the tab list contains the focus, moves focus to the next element in the page tab sequence outside the tablist, which is the tabpanel unless the first element containing meaningful content inside the tabpanel is focusable.
• 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).
• When focus is on a tab in a tablist with either horizontal or vertical orientation:
  • Space or Enter: Activates the tab if it was not activated automatically on focus.
  • Home (Optional): Moves focus to the first tab. Optionally, activates the newly focused tab (See note below).
  • End (Optional): Moves focus to the last tab. Optionally, activates the newly focused tab (See note below).

The space or enter interactions are the ones that should match clicks, as well as the VO+space combo. Additionally, note the “if it was not activated automatically on focus”, in conjunction with the following notice:

It is recommended that tabs activate automatically when they receive focus as long as their associated tab panels are displayed without noticeable latency.

Since all of our tab content is already in the DOM on page load, there should be effectively zero latency, so we should automatically activate tabs on focus. This means that space, enter, click, and VO+Space should be expected to do nothing.

Testing the canary version of this component, there are a few patterns that I’m seeing that should be changed:

1. The focus appears to be automatically moving from the tab (that is, the clickable link in the list of tabs), to the tab panel (the content that hides and shows). That is not a recommended design pattern, especially in keyboard navigation because it interrupts the user’s ability to navigate between the tabs quickly before selecting the panel they wish to see.
2. We’re currently allowing tab navigation with left, right, up, and down arrow keys at all times. We should probably limit the arrow keys to only work in the orientation the tabs are taking. Again, from the W3 page linked above:

• When a tab list has its aria-orientation set to vertical:
  • Down Arrow performs as Right Arrow is described above.
  • Up Arrow performs as Left Arrow is described above.

CC: @oliviaflory @kennylam @proeung