Open keithamus opened 2 months ago
@keithamus this is the rational i was given when trying to determine role allowances for slot for the ARIA in HTML spec - https://github.com/validator/validator/issues/1095#issuecomment-787589677
jist being that slot is not an element that is meant to be exposed to users at all. so putting a role on it is completely at odds with its purpose.
This was discussed briefly during triage in today's meeting: https://www.w3.org/2024/05/16-aria-minutes#t01
Discussed in today's meeting: https://www.w3.org/2024/05/23-aria-minutes.html#t07
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?