Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Tabs, Content switcher] Manual activation for accessible users #4870

Closed
JordanWSmith15 opened this issue Dec 12, 2019 · 15 comments · Fixed by #5659
Closed

[Tabs, Content switcher] Manual activation for accessible users #4870

JordanWSmith15 opened this issue Dec 12, 2019 · 15 comments · Fixed by #5659
Labels
component: content-switcher component: tabs proposal: open This request has gone through triaging. We're determining whether we take this on or not. type: discussion 💬

Comments

@JordanWSmith15
Copy link

JordanWSmith15 commented Dec 12, 2019

Manual activation missing on Tab and Content Switcher

What package(s) are you using?

Current version of React

Detailed description

It seems as though Tabs and Content Switcher do not provide a way to support Manual Activation. This causes UX issues for accessible users. The system loads the contents of each section as the user navigates between them, even if they are not interested in that content.

Is this issue related to a specific component?
Tabs, Content Switcher

What did you expect to happen? What happened instead? What would you like to
see changed?
Implement Manual Activation

What browser are you working in?
Chrome, Firefox, Safari

What version of the Carbon Design System are you using?
Current

What offering/product do you work on? Any pressing ship or release dates we
should be aware of?
IoT Maximo Suite, release Q2 2020

@asudoh
Copy link
Contributor

asudoh commented Dec 12, 2019

Hi 👋 thank you for reporting - I think it makes sense if this requests for arrow key changing focus only and having space/enter key to change the selection, CC @carbon-design-system/design for our UX thoughts.

@joshblack
Copy link
Contributor

joshblack commented Dec 12, 2019

Hi @JordanWSmith15! 👋 Do you have a reference for any accessibility violations that this causes? We specifically use the roving tabindex pattern for these widgets following this example from WAI ARIA: https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html

Definitely understand if this is more of a usability question, but if it's a violation definitely let us know the rule so we can make sure it gets addressed!

@joshblack
Copy link
Contributor

fyi @dakahn

@asudoh
Copy link
Contributor

asudoh commented Dec 12, 2019

Putting a11y pattern discussion a bit aside, another thing of my interest for @JordanWSmith15 is if you have an intent of using the content switcher or tab for lazy-loaded routing purpose.

@bragusa
Copy link

bragusa commented Dec 13, 2019

This is a performance problem for A11y users and any user that may use the keyboard to navigate. If the content is loaded when focus is placed on the tab then it adds unnecessary burden when someone uses arrow keys to navigate from tab 1 to tab 3. Manual activation of tab-like controls is a standard pattern.

@joshblack
Copy link
Contributor

@bragusa do you have an example we could look at to help show the performance problems that folks are running into? Would be great to ground this in-context 👍

As noted by the WAI-ARIA link earlier, there are multiple standard patterns for tabs (including automatic and manual activation) and we're happy to offer multiple models if we have solid use-cases for both 😄

@bragusa
Copy link

bragusa commented Dec 13, 2019

@joshblack We don't have a running example you can see at this time, but we will have larger lazy loaded data structures (tables, data lists) under the tabs.

@joshblack
Copy link
Contributor

@bragusa is there any data or research that you can share around the performance issues noted above or an example we could look at? Are there any alternative ways of representing the view that might not run into this issue, or workarounds that help improve the perceived performance?

@JordanWSmith15
Copy link
Author

JordanWSmith15 commented Dec 13, 2019

Plenty of design examples where a user wouldn't want to load the data inside a tab or content swither while keyboard navigating. It would essentially load an entire list, map, page, etc:

  1. Tabs in top left: https://ibm.invisionapp.com/share/UGNZJWHQ8SK#/319359912_Home-001
  2. Content switcher in top-right: https://ibm.invisionapp.com/share/APNZ6UW9Z5B#/319220026_Asset_Grid_View_-_Default_Data
  3. Tabs and content switcher: https://ibm.invisionapp.com/share/3TNYFBBC4B6#/319068674_Index

@JordanWSmith15
Copy link
Author

@joshblack The fact that loading occurs, in and of itself, is the performance issue. Content should not load until the user is done navigating. Not sure where the confusion is here.

@joshblack
Copy link
Contributor

@JordanWSmith15 I don't know if there is confusion, we're just asking for something to help us justify this change and explain it in the future 👍 Research, performance numbers, or running examples are all ways to help us out which is why they are being requested. I hope you can understand that it is hard to justify changing how a component fundamentally operates without this data or evidence, especially if it's been approved by IBMa.

@JordanWSmith15
Copy link
Author

@joshblack Are the design examples enough at this juncture? Goal is to fix this before there is a running example, as the designs forecast problems down the line.

@joshblack
Copy link
Contributor

@JordanWSmith15 the hope would be that we could observe this issue either in a running example or have metrics from something that is deployed, the hope obviously is that this pattern actually won't cause any perceived UX issues. If it does, and we can observe or measure them, then we can address these issues and make sure we don't have a regression in the future for this interaction model.

One thing we may also find is that we alternatively need to offer both of these interaction models (automatic and manual activation) and need to provide guidance on when to use one or the other 👍

@dakahn
Copy link
Contributor

dakahn commented Dec 13, 2019

In this hypothetical situation the content inside the tab is not made inaccessible to a keyboard user because there is a load on each tab. Both manual and automatic tab activation are valid patterns demonstrated by WAI-Aria authoring practices guidelines and the "undo burden" placed on the user is wholly dependent on what we stick inside those tabs -- so I'm removing the a11y tag.

@JordanWSmith15
Copy link
Author

@joshblack Perfectly fine with making it an alternative model. I'm not sure what the benefit of using Automatic is besides to save a keystroke, but I'd assume the guidance would be that if hidden content is not pre-loaded, then Manual is recommended.

@mattrosno mattrosno added squad: system proposal: open This request has gone through triaging. We're determining whether we take this on or not. labels Dec 17, 2019
asudoh added a commit that referenced this issue Mar 27, 2020
This change introduces `selectionMode="manual"` prop to
`<ContentSwitcher>` and `<Tabs>` that makes left/right arrow keys in
those components change only the focused item, not the selection. User
can use space/enter keys to update the selection.

Fixes #4870.
Fixes #5657.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: content-switcher component: tabs proposal: open This request has gone through triaging. We're determining whether we take this on or not. type: discussion 💬
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants