Clarify the scope

[annevk]

As far as I can tell there's only 8 ARIA attributes that can point to elsewhere in the tree. It would be useful to call those out to make it clear exactly what problems are attempted at being solved.

[alice]

+1, I'd love to have a good set of working examples to reason about.

[leobalter]

pinging @nolanlawson @gonzalocordero @caridy for support here.

[nolanlawson]

Opened a PR: https://github.com/leobalter/cross-root-aria-delegation/pull/28

[alice]

The list helps, but I think we need more.

For each attribute, it would be good to have pointers to some usage examples, preferably in production code (e.g. a demo page for a component or whatever).

I think the critical issue @annevk is trying to understand is whether for each attribute there's a tendency to refer either in to shadow roots or out of them, with a view to understanding whether something like CSS parts could do the job for both the referring-into problem and the serialization problem (i.e. that you could set things up so references always go inwards, and use a CSS parts-like design which is inherently serializable).

I think I'm trying to generally understand the contours of the interlocking refer-into-shadow-root and serialization problems. For example, my assumption is that except in the "semantic delegate" type case (where the fact that you're referring into a shadow root is really an implementation detail), references into a shadow root involve some degree of knowledge of what's inside (e.g. if you're referring to an active descendant within a shadow root, you know that the thing you're referring to has an appropriate role). (This is why I find the CSS parts-style solution somewhat appealing, because it kind of makes that explicit by providing a "public API"; however, it wouldn't necessarily solve the serialization problem.)