igniteui-webcomponents
igniteui-webcomponents copied to clipboard
[Tab] Allow for an accessible name to be applied to the tab list container
In order to fully cover the guidance from https://www.w3.org/WAI/ARIA/apg/patterns/tabpanel/ and allow for implementation like shown in https://www.w3.org/WAI/ARIA/apg/example-index/tabs/tabs-automatic.html, if there's a visible label for the Tabs, the tablist
should be able to reference that as its accessible name. Normally that happens through aria-labelledby
but there's a bit of an issue with that.
Once in the Shadow DOM tree, id-s and therefore id references are separate from the main (light) DOM tree.
https://coryrylan.com/blog/accessibility-with-id-referencing-and-shadow-dom
https://www.tpgi.com/stuff-doesnt-work-dom-shadow-dom/
What that means for us, at least for the moment, is that we can't use aria-labelledby
exposed as public API in shadow DOM anywhere. To that end, there are a few components that already do and will log an issue about those separately.
There are suggestions for Accessibility Object Model (AOM) using ElementInternals
to establish the references (example given is with tabs actually) and some proposals for delegation of aria attributes https://github.com/WICG/webcomponents/issues/916 and https://github.com/WICG/webcomponents/issues/917, but we'll have to wait and see for both.
To that end, I think we have a few options:
- Expose
aria-label
as an option instead to allow to assign the accessible name. It's not perfect, as you can't reuse an existing visible element in the DOM which is a bit unfortunate. - We might be able to move the entire
tablist
role on the host (and thus in the light DOM) which would allowaria-labelledby
to just work without additional handling. As far as I can telltablist
only requires child (owned)tab
elements but from the requirement I get the impression that doesn't include other possible roles and thetabpanel
has no restrictions of context. So it might be entirely possible to have the entire container be thetablist
if the cross between light and shadow DOM doesn't break the ownership connection (pretty sure it won't). Worth exploring. - Wait for platform solutions, though I think those will take a while so not my preferred option.