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

[oliviaflory]

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?

Tabs.extended.media-keyboard-.2022-01-25.at.9.03.56.AM.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]

@andy-blum Can you take a look at this issue and see if it's related to the one you just opened a PR for (#8357)? Feels like the VO issues that @oliviaflory mentioned here are the same as what you're working on for the WC version, but let me know if that's not the case.

[andy-blum]

The main thing I'd recommend to @oliviaflory (and anyone else testing VoiceOver) is to do it in safari.

If you don’t use Safari, the temptation might be to use your preferred browser; I urge you not to do this.

While Chrome shares a common root with Safari, and it’s usable with VoiceOver, I’ve found some quirky behaviour that isn’t there in Safari. Opera, Edge, Brave, Vivaldi and all the rest piggy back on the Chromium project, so they suffer from the same downsides as Chrome.

Firefox used to be impossible to use with VoiceOver, but Mozilla began to change that. Problem is, it’s not perfect and is unlikely to improve any time soon, since Mozilla now have fewer people working on Firefox.

So if you’re looking to experience the same thing as almost all actual VoiceOver users, Safari is what you should test with.

[andy-blum]

Also worth noting that Deque has a list of ideal screen reader/browser pairings

https://dequeuniversity.com/screenreaders/survival-guide

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

[kennylam]

@oliviaflory I just took a look at this and the behavior comes from Carbon's tab component. Tabbing in this element toggles between the tab and tab content. In order to choose other tabs, only the left/right cursor keys work, for both Chrome and Safari.

One notable difference is that Carbon's version does not cause the screen reader to announce any key combo to select a tab. The tabs are selected the moment they are in focus and active. Seems like something in in the dotcom component is making the screen reader add the additional instructions with the key combo, which is not needed.

No text prompting key combos

It looks like we only have one issue here. That is the additional VoiceOver instructions with key combos that do nothing (which we should fix). The Carbon tab component appears to be correct. From the component accessibility tab: https://www.w3.org/TR/wai-aria-practices-1.1/#keyboard-interaction-19

[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

[stale]

We've marked this issue as stale because there hasn't been any activity for 60 days. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.