Carbon: [Tabs, Content switcher] Manual activation for accessible users

[JordanWSmith15]

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]

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]

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]

fyi @dakahn

[asudoh]

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]

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]

@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]

@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]

@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]

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]

@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]

@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]

@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]

@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]

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]

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