FEAT: Tabs tabOrder enhancement

[scomea]

📖 Description

This is a draft version of a proposed rework of the tabs component with a primary goal of making it easier to extend.

The current api currently works based on the order of child elements in the DOM ie. the first child tab component is associated with the first tab-panel child, the second with the second, etc... The component assigns children id's if they don't already have them and then populates aria "controls" and "labelledby" attributes accordingly. So, tab/tab-panel linkage and keyboarding is via arrow keys is based on DOM order. Not very flexible.

This change proposes:

• The component gets a new customTabOrder public property which is a string[] of tab id's which defines the order of active tabs.
• Authors can choose to provide a custom tabOrder property so the order of tabs can be easily managed without re-ordering the DOM (ie. should play well with frameworks).
• component assigns id's to all tab and tab-panel elements if they don't already have one as the current behavior.
• The component assigns "aria-controls" attributes to child tab elements when none is provided by the author and there is no customTabOrder. When authors provide a customTabOrder they must specify the "aria-controls" attribute on each tab to set the associated tab panel
• Authors could choose to have custom configurations like multiple tabs pointing at the same panel (addressing feat: add ability for multiple tabs to point to the same tab panel #6445).
• Tab-panels have their "aria-labelledby" attribute set when they are activated
• activeid is the "source of truth" for active tab

A simple example of a custom tab order looks like this in markup:

And renders the tabs in the specified order rather than dom order:

This is a major rewrite, but it should (hopefully) not break folks that haven't extended/overridden the component. There is a minor template change to add a ref.
 

🎫 Issues

#6445

👩‍💻 Reviewer Notes

Work in progress

📑 Test Plan

Need to add

✅ Checklist

General

• I have included a change request file using $ yarn change
• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

Component-specific

• I have added a new component
• I have modified an existing component
• I have updated the definition file
• I have updated the configuration file

⏭ Next Steps

[scomea]

This may not work, can't convince narrator of the new order...

[scomea]

Ok, narrator can be convinced, but might be too hacky...

[scomea]

Problem - how to have a web component container that manages accessible node child order without changing DOM order and interfering with frameworks and still work with accessibility tools that depend on DOM order.

Currently trying the "only the currently active child node has a role" approach.

aria-posinset doesn't work like I expected in that you can't use it to just arbitrarily override DOM order (it should), but rather it it expects the elements to be in the correct order and let's authors account elements may not be rendering in order to support virtualization scenarios. Using posinset to override DOM order doesn't work.

But what does appear to work is to simulate the virtualization scenario as far as assistive technologies are concerned by only ever having a single child of the container marked with an accessibility role at a time, and use "posinset" to cue assistive technologies as to the element's position in the collection.

While this approach is certainly "unconventional" I'd be curious as to would make it any less accessible than a full virtualization scenario where the other tabs were actually hidden rather than having no role?