How should `<slot aria-label="foo">` be treated?

[nolanlawson]

Related to #93 and #20.

While looking into shadow DOM and slots (https://github.com/w3c/accname/pull/167#issuecomment-1262688553), I found an apparent disagreement between UAs.

Consider this DOM (Codepen):

<label id="the-label">
  <div>
    #shadow-root
      foo <slot aria-label="label"></slot> bar
    slotted
  </div>
</label>
<button aria-labelledby="the-label"> 

(Note the aria-label on the <slot>.)

What should the <button>'s accessible name be in this case? The UAs disagree:

Browser	ATs tested	Result
Chrome 105	VoiceOver, NVDA	"foo label bar"
Firefox 104	VoiceOver, NVDA	"foo slotted bar"
Safari 16	VoiceOver	"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):

Browser	ATs tested	Result
Chrome 105	VoiceOver, NVDA	"foo label bar"
Firefox 104	VoiceOver, NVDA	"foo default bar"
Safari 16	VoiceOver	"foo default bar"

Per the HTML spec:

A slot element represents its assigned nodes, if any, and its contents otherwise.

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.)

[scottaohara]

this comment from an HTML validator issue i had filed is relevant.

I would not expect any ARIA attributes to be respected on a slot. I think safari and firefox are correct here

[nolanlawson]

Thanks for the feedback! I've filed a bug on Chromium.

[accdc]

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.