mdc-tab loses keyboard accessibility when deactivated

[dfabulich]

What MDC Web Version are you using?

0.44.0

What browser(s) is this bug affecting?

All browsers.

But, if you insist.

Chrome 72/Windows
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36

Chrome 72/Mac
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36

Firefox 65/Windows
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:65.0) Gecko/20100101 Firefox/65.0

Firefox 65/Mac
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:65.0) Gecko/20100101 Firefox/65.0

Safari 12.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 Safari/605.1.15

What OS are you using?

macOS Mojave 10.14.3 and Windows 10.

What are the steps to reproduce the bug?

In this codepen: https://codepen.io/dfabulich/pen/XOOzjz

It's a basic tab bar with three tabs. Click in the white space under the tab bar and press the Tab key to focus tab One. Press Tab again and you'll focus tab Two. Press Tab again and you'll focus tab Three. Shift-Tab to focus on the second tab and press Enter to activate it, then Shift-Tab to focus tab One.

What is the actual behavior?

The tab One is no longer keyboard accessible; Shift-Tab leaves the document. Each time a tab is deactivated, its tabindex attribute is set to -1; the tab is no longer keyboard accessible.

What is the expected behavior?

The tabindex attribute should not change when activating or deactivating tabs; each tab should remain keyboard accessible as other tabs are selected and deselected.

[acdvorak]

Thanks for filing this issue, and taking the time to send us a PR! 😀🎉

It may surprise you to learn that there should only be one tab stop for the entire bar.

This is an intentional accessibility feature recommended by WAI-ARIA Best Practices (see ARIA's Example of Tabs page for a working demo).

The example in the mdc-tab-bar README doesn't really make this clear (and we should update it to do so), but only the --active tab should have tabindex="0"; all other tabs should have tabindex="-1" to prevent users from tabbing to them directly:

https://codepen.io/acdvorak/pen/gqJZjp?editors=1010

Navigating to a different tab is accomplished by pressing the ← and → keys. This is similar to how mdc-drawer and mdc-radio behave with ↑ and ↓ (as well as native <input type="radio" name="group"> elements).

We could potentially do what mdc-list does and programmatically set tabindex="-1" on all non-active tabs, but that's probably out of scope for us at the moment.

[dfabulich]

Thanks for the explanation. Closing.

[patbou02]

@acdvorak I am investigating an issue with mdc-list (which I am aware is not the same as this ticket's) but you seem to be pretty familiar with ARIA and mdc-list so I'm asking just in case.

The issue I am trying to fix is a list where pressing the ↑ and ↓ arrows will skip one list element per key press in either direction.

I suspect this may be related to data-mdc-auto-init but haven't found any threads on this yet.

Maybe you can point me in the right direction? Thank you in advance. 🙏

[abhiomkar]

@patbou02 This can happen if MDC List is initialized twice on same list root element, which causes it to duplicate execution of keyboard handlers.

[patbou02]

That makes sense and gives me a solid lead to follow. Thank you again! 😄