[Tabs] Keyboard navigation does not work with disabled tabs

[diogofscmariano]

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current behavior

Tabs keyboard navigation does not behave correctly when there are disabled tab items

Expected Behavior 🤔

Keyboard navigation should either allow the selected tabs to be focusable but not selectable or skip them. According to W3C accessibility standards, they should be focusable but not selectable.

Steps to Reproduce 🕹

https://codesandbox.io/s/material-demo-v5ddi?file=/demo.js

Steps:

1. Try to use the keyboard to navigate through the tabs after focusing it

Tech	Version
Material-UI	v4.10.0

[eps1lon]

According to W3C accessibility standards, they should be focusable but not selectable.

Generally this choice should be up to the author. I'm not aware of disabled elements appearing the the tab order by default. Do you have a link for this requirement?

[joshwooding]

Hmm, I’m in favour of allowing keyboard navigation to disabled items in group components.

When a custom control becomes disabled, remove it from the tab order by setting tabindex="-1". Note that disabled items within a grouped widget (such as menu items in a menu) should remain navigable using arrow keys.

Source: https://developer.mozilla.org/en-US/docs/Web/Accessibility/Keyboard-navigable_JavaScript_widgets

[diogofscmariano]

The main issue here is that you cant actually navigate through the tabs if you have disabled items.
@joshwooding thanks for pulling the link for the reference

[eps1lon]

@diogofscmariano Could you link the W3C recommendation?

All I'm aware of is https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_disabled_controls which basically says: "It depends but be consistent".

Which means we're technically good but we should offer customization and a better default. I'm always in favor of following the APG by default but it's clear that there should be an option to remove disabled items from the focus order.

[diogofscmariano]

That was the one I'm talking about: https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_disabled_controls
I'm fine not having them focusable. I just dont think we should not allow the user to navigate through the non-disabled ones. If you try to use the keyboard with disabled tabs you will see you cant circle over all navigable tabs.

[delesseps]

That was the one I'm talking about: https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_disabled_controls
I'm fine not having them focusable. I just dont think we should not allow the user to navigate through the non-disabled ones. If you try to use the keyboard with disabled tabs you will see you cant circle over all navigable tabs.

+1. Without some form of skipping you can never get to the active tabs between two disabled ones.

For what it's worth, antd's demo doesn't have arrow navigation but the disabled tab is skipped and accessible - https://codepen.io/delesseps/pen/mdPEqLj

[darkgrayknight]

This is exactly what we have found. We would like to be able to use the arrow keys and allow focus to aria-disabled="true". We have actually implemented our own disabled attribute that does not make buttons/tabs html disabled, but does make them aria-disabled and we style them via CSS to be disabled.

We would like: "Keyboard navigation should allow the selected tabs to be focusable but not selectable."

Basically line 55: https://github.com/mui/material-ui/blob/master/packages/mui-material/src/Tabs/Tabs.js#L55
should just not have the || nextFocus.getAttribute('aria-disabled') === 'true'
and it will work for our needs.