Matthew: need more time - but a couple of thoughts... the problem is definitely one that needs solving. Broken up into different phases. First phase solves a simpler part of the problem which looks good. They want feedback on phase 1. looks promising. Phase 2 looks well thought out but is complex. They reference other proposals and I don't know if those proposals are ongoing or were shelved... I also noticed that it's moved... it was in AOM and now it's in Web Components... So I'm figuring out what that means... also it would be good to ask people who develop ATs what they think... It looks well thought out...

Matthew: will leave some feedback

bumped

Jeffrey: meant as an accessibility thing...

Lea: had some concerns about the design.. but also saw excitement from webcomponents people

Jeffrey: it's incredibly needed, my worry is it's across more things than just accessibility... problems with shadow dom and links to #foo not scrolling.. CSS has some similar problems.. deal with in a different way, might not be IDs

Lea: the whole syntax of using id refs of linking elements to other elements is broken and we want a better way to link to other elements, it's not just about aria, it's also about developer ergonomics. Web components authors don't have a good precedent to follow. Assigning ids to everything produces very poor experiences for authors. One one hand this is solving a very prominent pain point, on the other hand my sense is that it's solving it with a bandaid. Also something that needs to be solved asap. Waiting to solve the bigger problem is also suboptimal

Jeffrey: yes. Should generally support this, but describe the overall problem and ask people to keep thinking about how to solve the general problem. Gaps repo!

Lea: exactly! I wrote a post in whatwg about this, I need to edit and post there. [Narrator: It was already posted: https://github.com/w3ctag/gaps/issues/2]

Lea: we also don't have standardised api about how this corresponds to idl attributes. Value, or reference to element... or two idl attributes for value and element.

Jeffrey: accessibility folks using that setter as a way to cross shadow boundaries ... ?? is opposed to crossing the shadow boundary ... to be continued.

Lea: hes' going to have to revise his perspective because there's a ton of use cases

Jeffrey: I don't want tod elay anything with that comment. If they found a way forward for any part of it then they should take that path, to make progress.

Jeffrey: we should review phase ii but we should also approve phase i.

jeffrey to write comment

Matthew: ... interesting ... the central problem they are trying to solve is one that's been there for a long time - 2 phases - i didn't see anything concerning with the first part - i haven't given the 2nd part enough of a review. This particular thing they are trying to do is straightforward and good. But the point Jeffrey raises is interesting... we need to be somewhat careful. It sounded like Jeffrey's idea was to have more discussion...

defer to plenary where we can have Jeffrey

Matthew: still catching up with discussion from TPAC

Jeffrey: [summarizes the TPAC discussion from https://www.w3.org/2024/09/25-webcomponents-minutes.html#da4f] We should endorse the first phase, and maybe we can help with the design for the second phase where they have some open questions.

Matthew: +1. Thinking about prior art for phase 2.

Jeffrey: I was surprised that we don't want to follow the data-* pattern, but there seems to be consensus against using hyphens. I'll also find the minutes from TPAC.

Matthew: Think about how this affects the general gap on IDREF in shadow trees.

Peter: Is it right to put the property on the shadow root, or better to put it on the target element inside the shadow root? Seems like it might be better ergonomics if the right target inside the shadow tree needs to change, since you'll probably be updating that element's attributs anyway. Could expose the map at the root as readonly.

Matthew: This might be consistent with the rest of ARIA, where relations are sometimes backwards from HTML.

Peter: That's a mistake in ARIA.

Matthew: Doesn't make this comment invalid; it might just apply more generally. Although it has helped implementation for assistive technology.

Peter: If the browser is helping out, it can expose the right accessibility tree.

Matthew: Should we file a more general issue?

Peter: Start with posting the comment here.

Peter to draft the comment.

I'm thinking of the developer ergonomics, for instance if I'm building a select-type control, in the current model I have to set some attribute (probably a class) on the currently selected node to indicate its selected state and trigger style changes, and then I have to also add an id and set the aria-activedescendant in the reference map on the shadow root. In my proposal, the developer would only need to set the aria-activedescendant attribute on the active node (which can also be used as the style trigger) and the reference map can update automatically. This also eliminates the need for ids on everything.

Posted to https://github.com/w3ctag/design-reviews/issues/961#issuecomment-2411812056

Not enough information and not the right people.

Jeffrey: the comments gives some reason to give it the way they did - and that it aligns with ARIA... Is that convincing?

Lea: to some degree... We have a principle about consistency... and precedent... no right answer... that's what we have here. Being consistent with a precedent is reasonable. However this isn't just about ARIA .. but any id ref in HTNL... we want this to work down the line... e.g. through slectors or names... Should this just be ID focused? I won't push back if we think we're fine with it. It's an important issue to solve that is holding WC back.

Peter: generally agree - i do want to push back on "ARIA works this way" - ARIA could be improved.

Jefrey: let's invite them to come talk to us?

Dan: breakout A the next week?

jeffrey to reach out

Peter: People have a bunch of opinions.

Dan: Steve Orvell has summarized the tradeoffs: https://github.com/w3ctag/design-reviews/issues/961#issuecomment-2457667230. Somewhat aesthetic. Main concern is about re-ordering, for example for aria-labelledby. We lose that if we push the information down to elements. I don't have a good sense how much developers would miss this.

Alice: Comes down to ordering. Steve's table was useful, but ordering is the only place where it's not just convenience. TL;DR comment: https://github.com/w3ctag/design-reviews/issues/961#issuecomment-2456465629. When is this actually going to be used in practice? For what attributes? We're designing a general solution without understanding the specific problems it's trying to solve. Looking through the problems in my comment, if we can solve the naming problem, the ordering question doesn't seem to actually mention. There are lots of attributes that do take lists of id references. Do we need to support those use cases?

Lea: One of the considerations to keep in mind is that this is not just about ARIA or labels. It's about anything that takes element references. The list of things like that keeps increasing. popovers, invokerrs, input lists. Anchor attribute. These have very different characteristics w.r.t. which shadow dom element you need to refer to?

Alice: Specific examples?

Lea: Not off the top of my head. Do you ever need a datalist inside a component? Need to think more to find specific examples.

Dan: I've written tests where you have a popup inside a shadow dom, and want to trigger it from outside. Don't know if people actually want this?

Westbrook: The idea that it's growing, regardless of the use cases, is a reason not to use new attributes. Every time another group wants to add an ID reference, they'll need a reflected attribute. We'd be setting everyone up to fall into gaps. With popover, we know the context, but the next one won't have it. Want to solve the general problem.

Lea: I don't have a strong opinion. Slightly favor attribute approach. I think the id approach is reasonable, and it has many things going for it. Much easier than the general idref problem. In shadow roots, you assign a fair number of IDs anyway. There are arguments for both. If we have an attribute on the shadow root, want to iterate a bit more on the syntax. Also want to make it work with direct element references. Whatever solution should allow web components to extend the set of idref attributes.

Alice: I want to understand the specific problems we're trying to solve. Think if you scope the problem to just referenceTarget (after bikeshedding), a lot of the distinctions between the two syntaxes disappear, because you lose the ordering problem. Really depends on whether we can justify not doing any kind of mapping.

Dan: I have that feedback. "Please solve the basic referenceTarget problem; dont' get delayed by the mapping problem."

Alice: Would be really nice to know what the more problems are.

Dan: Want to do an origin trial of the basic referenceTarget case. Haven't implemented referenceTargetMap yet. One option is to move forward with that, and we can prod the partners to ask if they'd be happier with the attribute on the elements. You get better responses if people can ship this in production.

Alice: Element references: I think that's explicitly scoped out, having an element reference version of referenceTarget. Not sure if the explainer says anything about an element reference from shadow dom pointing [?] For activedescendant, you have to change things all the time, so an element reference might be nice to have. Solve the basic "there's an input inside the root that needs to substitute for the root". activedescendant is important, but it's niche. I liked Jeffrey's suggestion to let aria-labeledby work when it's on a shadow root. The problem with daisy-chaining might be that you want an input to have a value, but the value becomes part of the label. And the input has its own label, but you want its value to act as the label for something else.

Jeffrey: And that problem doesn't happen if you only allow labeledby to recurse only when it's set on the shadow root.

Peter: Main concern is the mechanics of using IDs to reference everything. When you're dynamically generating component content, assigning IDs is hard. ARIA requires IDs for almost everything. Want to see a path to fix that. Try to reverse the relationship and let the browser help out. Want to improve the DX.

Lea: +1 to Peter. IDs are painful, but this might not be the place to solve it. I wrote an essay about this. But wouldn't want to block referenceTarget on this. What if we don't do either. Specify stuff on shadow root. Instead of just specifying IDs, use selectors that are scoped to shadow root.

Westbrook: Interesting to avoid needing IDs, even if it's hard to manage or keep track of them. Web Components community wants to keep ARIA working. But I'm also excited to share thoughts on how we can expand on those relationships in the future. Wouldn't want to invent new selectors to let web components devs catch up to non-components development.

Peter: In general I'm sympathetic. We see proposals that are inconsistent with some othe rthings, but it matches years of precedent. "Chart a new path" makes people boil the ocean. Counterpoint is that we have an established path that we're trying to get away from, and we keep adding to that path, we create more inertia.

Jeffrey: We don't yet have a plan. The plan isn't just "selectors" since we also need to be able to go up the tree. We should make a plan and then we'll need to upgrade the existing aria-* attributes anyway. referenceTarget and referenceTargetMap (spelled however) will probably be able to upgrade the same way. So I'm leaning toward saying to go ahead with referenceTarget as it's currently designed, with IDs, and then we fix everything at once.

Dan: Use an id on the shadow

Alice: +100 to Jeffrey. When it comes to designing the new system, you need to be able to go up or sideways. Collect specific use cases. It's a different things to get aria-labeledby where maybe you want to reverse a name. You need to think about the cases you need. 1 thing vs multiple things. Collect the cases of the attributes we have currently. As opposed to thinking of them as a general problem.

Lea: I like the idea of "let's solve this problem now, and pave the way for solving the general problem later." What makes that easier? Microsyntax of referenceTargetMap -> separate attributes. Attribute for each mapping. Then the attributes have the same syntax as the bound attirubtes, and upgrading them works the same as upgradinng ARIA.

Jeffrey: Think that came up at TPAC.

Dan: People were wary of microsyntax at TPAC. (https://github.com/WICG/webcomponents/blob/gh-pages/proposals/reference-target-explainer.md#use-separate-attributes-for-each-forwarded-attribute) Still wanted to put it on the shadow root.

Lea: Pending TAG principle against inventing microsyntaxes. Maybe helps forwarding for certain attributes work before others. Huge disparity. Want to delegate for the most. Maybe that could advance independently.

Westbrook: I heard also the feedback on microsyntaxes. Anything specific about the microsyntax that would stop it from working like attributes. Link about crawling up and down DOM. It was frowned upon by lots of people.

Lea: Not about browser internals. More syntax implies that new syntax is hard to introduce w/o introducing parsing ambiguity. w.r.t. #204, maybe this particular naming scheme isn't the only possible one?

Alice: To clarify one thing about exportid: the syntax is noisy, but when you have a substitute element within the shadow root, the syntax was horrible. Every time you want to refer to the real input, you have to use hostid::realid. This wasn't meant to stand on its own. It was a stepping stone toward a better coordination thing; would let you prototype.

Jeffrey: I think we've converged on saying "go ahead with referenceTarget, and we'll work on fixing ARIA in parallel."

Peter: Let's just be careful not to paint ourselves into a corner. Don't want to fix all of ARIA before shipping this. But do think about what the future shoul dlook like and avoid preemptin ghtat. Maybe we delay parts of this, but get the most important parts out.

Lea: Re "delegatesReferences" looks good, not a good use of call time to bikeshed, but if we use multiple attributes, we need a short base name plus suffixes. So the base needs to be very short.

Tess: "delegates" might be an ok name since it copies delegatesFocus.

Peter: Not a fan of over-abbreviating things. Spell it out. But if it shows up 1000 times in a document, that's bad too. As we think about the future, I'd like to be able to take references to DOM nodes. And have that expressible as attributes, so it can be serialized. But as a developer I don't want to think about all the attributes. Think of DX first.

Matthew: To clarify, my understanding is that phase 1 seems good, but phase 2 we want to keep thinking?

Peter: And about it being dynamically generated by the browser.

Lea: Ergonomics is important, but since time is finite, let's make things possible now and easy later. e.g. imperative API later. As a data point, don't know if it reflects the broader set of use cases. My engineers said they were happy with just referenceTarget.

Alice: That is the most common case. The 2 other cases from my post are real cases. Maybe not having a map, but solutions to specific problems. e.g. computed name and some potential ideas for activedescendent. Maybe those cases can be solved in a better way than a map.

Jeffrey: Who's going to work on fixing ARIA?

Alice: That sounds like something to talk to ARIA about. They have a lot of work.

Lea: I would frame it as fixing IDREFs, rather than fixing ARIA.

Peter: Browser vendors care more now, so maybe we can get things that we couldn't have gotten 10 years ago. Would like someone to step up and go think about these things. We shouldn't say "someone should fix things" without following it up.

Jeffrey: Task force? We need to identify a person who will lead the taskforce, and they can recruit people from the right communities. But nothing happens without that leader, and we need to avoid blocking things if we can't volunteer someone to run the task force.

Peter: AI for the TAG.

Dan: We'll go ahead with the origin trial. I'll ask about better names, if they prefer putting it on an element, what other use cases this doesn't cover.

Lea: Westbrook's explainer document has some use cases.

Westbrook: It almost always goes back to the combobox pattern. We have to write web components the hard way, so we don't even run into this wall. Not sure an OT will be enough to get us to the use cases we want to see. As soon as production systems can use this, we'll find use cases.

Dan: Very interested in the ID problem. Reluctant to sign up to drive it today, but want to think about driving it.

Task force members but not leaders: Dan Clark + Alice + Matthew