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

That sounds like this considered alternative: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/reference-target-explainer.md#designate-target-elements-using-attributes-instead-of-idref, which @westbrook proposed in more depth in https://github.com/Westbrook/cross-root-aria-reflection/blob/main/cross-root-aria-reflection.md.

IMO the developer ergonomics are similar in the use case you mentioned. They way I would handle the `aria-activedescendant` case with reference target is that I'd have the shadowRoot's referencetarget or referencetargetmap assign `aria-activedescendant` to a constant id, e.g. `#active`, which is also used to apply active styles to the node. And then when the activedescendant changes, I change which element has that ID.

```html
<fancy-listbox id="host" shadowrootmode="open" shadowrootreferencetarget="active">
  <style>
    #active { /* styles for the active element go here */ }
  </style>
  <option>One</option>
  <option id="active">Two</option>
  <option>Three</option>
</fancy-listbox>
```

If the user selects another option, the only thing the dev needs to change is to clear the ID from option Two and add it to the new option. This is the same amount of state that would need to be changed if reference target was set using a property on the targeted element.

Semantically, it also feels to me that the choice of whether or not to delegate a given attribute is something that should be set on the shadow root, akin to delegatesfocus, which maybe is why @westbrook's proposal used both a property on the shadow root and a property on the targeted element.

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

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