Open oliviaflory opened 2 years ago
@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 (https://github.com/carbon-design-system/carbon-for-ibm-dotcom/issues/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.
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.
Also worth noting that Deque has a list of ideal screen reader/browser pairings
@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.
@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
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
orEnter
: 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:
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 asRight Arrow
is described above.Up Arrow
performs asLeft Arrow
is described above.
CC: @oliviaflory @kennylam @proeung
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.
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
, thencontrol
+option
+space
, thentab
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