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
Per this definition, it seems to me that the Firefox/Safari behavior is correct, and Chrome's is incorrect. (I.e. the slot's aria-label should be ignored; only its contents should be considered to "represent" it.)
Note this should also apply to aria-description, aria-labelledby, and aria-describedby. (I did not test these though.)
The text was updated successfully, but these errors were encountered:
Thanks for raising this, we spoke about it at our last meeting and consensus was that slot should not be expected to have an accessible name. I'll close this as a non-issue with AccName for now.
Related to #93 and #20.
While looking into shadow DOM and slots (#167 (comment)), I found an apparent disagreement between UAs.
Consider this DOM (Codepen):
(Note the
aria-label
on the<slot>
.)What should the
<button>
's accessible name be in this case? The UAs disagree:"foo label bar"
"foo slotted bar"
"foo slotted bar"
Firefox and Safari ignore the
aria-label
, whereas Chrome treats it as significant.The result is the same for default slotted content (see the same Codepen):
"foo label bar"
"foo default bar"
"foo default bar"
Per the HTML spec:
Per this definition, it seems to me that the Firefox/Safari behavior is correct, and Chrome's is incorrect. (I.e. the slot's
aria-label
should be ignored; only its contents should be considered to "represent" it.)Note this should also apply to
aria-description
,aria-labelledby
, andaria-describedby
. (I did not test these though.)The text was updated successfully, but these errors were encountered: