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-labelas 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
tablistrole on the host (and thus in the light DOM) which would allowaria-labelledbyto just work without additional handling. As far as I can telltablistonly requires child (owned)tabelements but from the requirement I get the impression that doesn't include other possible roles and thetabpanelhas no restrictions of context. So it might be entirely possible to have the entire container be thetablistif 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.