Tabs: Missing accessibility features

[omaxel]

Comparing the current implementation of Tabs to the one described on this MDN page, there are a couple of issues related to accessibility.

Things we are missing are:

• Elements with the role tab must either be a child of an element with the tablist role, or have their id part of the aria-owns property of a tablist.
• They should contain the aria-controls property identifying an element with the tabpanel role.
• When working with elements with the tab role, when they are selected or active, they should have their aria-selected attribute set to true, otherwise it should be set to false.
• When a tab is selected or active, its controlled tabpanel should have its aria-expanded attribute set to true and its hidden attribute set to false, otherwise the reverse.
• It is recommended to use a button element with the role tab for their built-in functional and accessible features instead, as opposed to needing to add them yourself. For controlling tab key functionality for elements with the role tab, it is recommended to set all non-active elements to tabindex=-1, and to set the active element to tabindex=0.

Also, I would highlight this sentence on the same MDN page:

While there are ways to build tab-like functionality without JavaScript, there are no substitute combination of HTML and CSS only that will provide the same set of functionality that's required above for accessible tabs with content.

We should decide how to approach this.

I was thinking to provide a separate package containing JS file for each component which provides accessibility improvements.

[zetareticoli]

I was thinking to provide a separate package containing JS file for each component which provides accessibility improvements.

That could be an interesting solution. A sort of library's expanded version.

The point is: the scope of CSSUI is to provide CSS-only solutions. Introducing JS (even for accessibility) set the library as Bootstrap (or similar) competitor. Which is impossible.

I know, accessibility is a top priority for all. But we should make it different.

[omaxel]

That's ok. I was thinking to provide it as an optional package, only if the developer wants to guarantee maximum accessibility. However, I'm thinking again about that. Working on the tabs component I realized that a fully accessible component would be created totally different compared to how we create it with CSS limitations.

For example, in the tabs component, we are forced to use the radio component to store the currently active tab. Instead of that, we should use a button. Providing a separate JavaScript package wouldn't solve these kinds of issues.

[omaxel]

I created this PR to improve the accessibility without adding JS.

[zetareticoli]

Resolved in 47b0e7b