You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently <slot> has no corresponding role (that's fine) but it also doesn't map the WAI-ARIA role, meaning role= simply does nothing on a slot. Is there a good reason to do this? It's a little perculiar to me, considering the other elements that don't map are generally non structural elements, e.g. <title>, <meta>, <script> and so on.
I've run into scenarios where a shadowdom has an existing <div role=something>, and a request has come in to be able to customise the children of this element. Easy enough! Let the <div> become a <slot>, but oh, no! No more role. Instead we need to introduce additional elements to the shadowdom markup to work around this limitation, which can sometimes be a little tricky trying to balance the constraints of customisability vs creating a structure that maps nicely to the accessibility tree.
I haven't found any existing discussion, nor does anything jump out to me as to why this limitation exist. I'm wondering if it's a limitation we can lift?
The text was updated successfully, but these errors were encountered:
Currently
<slot>
has no corresponding role (that's fine) but it also doesn't map the WAI-ARIA role, meaningrole=
simply does nothing on aslot
. Is there a good reason to do this? It's a little perculiar to me, considering the other elements that don't map are generally non structural elements, e.g.<title>
,<meta>
,<script>
and so on.I've run into scenarios where a shadowdom has an existing
<div role=something>
, and a request has come in to be able to customise the children of this element. Easy enough! Let the<div>
become a<slot>
, but oh, no! No morerole
. Instead we need to introduce additional elements to the shadowdom markup to work around this limitation, which can sometimes be a little tricky trying to balance the constraints of customisability vs creating a structure that maps nicely to the accessibility tree.I haven't found any existing discussion, nor does anything jump out to me as to why this limitation exist. I'm wondering if it's a limitation we can lift?
The text was updated successfully, but these errors were encountered: