Re: [w3ctag/design-reviews] Reference Target (Issue #961)

@Westbrook's example I think illustrates why this problem gets very hard for me to reason about from a general perspective when there's not a 1:1 mapping between the shadow host and the reference target.

Even leaving aside the syntax, I would struggle to reason about what should happen in a case like this:

```html
<form>
  <label for="sum">Equation</label>
  <calc-el id="sum">
    <template shadowrootmode="open">
      <input type="range" referenceTargetForAttributes="for" value="50" /> +
      <input type="number" referenceTargetForAttributes="for" value="10" /> =
    </template>
  </calc-el>
  <output name="result" for="sum">60</output>
</form>
```

So, I've tried to think about specific cases instead. There are three types of non-contrived cases for this type of API I am reasonably confident I can get my head around (thanks to the folks who have patiently explained the latter two to me across multiple occasions):

1) Something like`<fancy-input>`, where there is an `<input>` inside `<fancy-input>`'s shadow root which could reasonably substitute for the host `<fancy-input>`. (I'm using `<input>` as an example partly because of the number of ways `<input>`s can relate to other elements, but obviously it's not the only element which is or could be wrapped this way.)
2) Needing `aria-activedescendant` _(specifically)_ to refer to a list item which needs to be inside a shadow root in order to encapsulate certain implementation details, such as a recycler view and/or list items being loaded dynamically, when implementing an [accessible combobox](https://sarahmhigley.com/writing/activedescendant/).
3) Needing a component to have a computed name, for `aria-labelledby`/`aria-describedby` purposes, which doesn't include all of its contents, without excluding from the accessibility tree the content which should be excluded from the name. One example might be a contact chip including a profile picture, a name and a "remove" button, where the contact chip can be used as a label for something else: the profile picture and the remove button should be accessible, but not a part of its computed name. (And, in a slightly contrived case, you might like to list the surname first in the component, but have the computed name list the given name first; why not.)

For (1), I think the current `referenceTarget` design matches the way I think about the problem: the shadow root encloses some element which could generally substitute for the shadow host other than some encapsulated fanciness. It makes intuitive sense to me that the shadow root should be responsible for redirecting references to allow that substitution to occur whenever another element refers to the host. 

That said, I don't necessarily have any objection to having an attribute on the substitute element instead; I can't see any major practical downside of either design for this case, particularly if you can retrieve the reference target from the shadow root for debugging.

For (2), we're arguably getting an upgrade on the status quo regardless of syntax, since the listbox no longer needs to coordinate with the `<input>` to tell it what its active descendant should be (although it's a bit unfortunate that the `<input>` still needs to _have_ both an `aria-activedescendant` attribute and an `aria-controls` attribute which just point to the same element).  

Since `aria-activedescendant` can only ever point to one element, there's not really a major downside to having an attribute on the element, since there's no ordering issue. So I think for this case, again, there's not a lot in between the two syntax options. 

For (3), I do wonder like @jyasskin whether this is the best approach at all. I understand that there is a general expectation around how `aria-labelledby` will behave, but that expectation is already broken if you're pointing to the shadow host and getting something other than all of its contents as its computed name. So I do wonder whether we could allow `aria-labelledby` on the shadow _root_ for this case.

And if we really can't come up with a case other than (2) for the reference _map_, I wonder likewise whether we could find a way to improve on this case in isolation.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/961#issuecomment-2456465629
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/961/2456465629@github.com>