Tabs: Missing accessibility features
omaxel opened this issue · comments
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 thetablist
role, or have theirid
part of thearia-owns
property of atablist
. - They should contain the
aria-controls
property identifying an element with thetabpanel
role. - When working with elements with the
tab
role, when they are selected or active, they should have theiraria-selected
attribute set totrue
, otherwise it should be set tofalse
. - When a
tab
is selected or active, its controlledtabpanel
should have itsaria-expanded
attribute set totrue
and itshidden
attribute set tofalse
, otherwise the reverse. - It is recommended to use a
button
element with the roletab
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 roletab
, it is recommended to set all non-active elements totabindex=-1
, and to set the active element totabindex=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.
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.
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.
I created this PR to improve the accessibility without adding JS.
Resolved in 47b0e7b