Reference Target

[dandclark]

こんにちは TAG-さん!

I'm requesting a TAG review of Reference Target.

Reference Target is a feature that enables using IDREF attributes such as for and aria-labelledby to refer to elements inside a component's shadow DOM, while maintaining encapsulation of the internal details of the shadow DOM. The main goal of this feature is to enable ARIA to work across shadow root boundaries.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/webcomponents/blob/gh-pages/proposals/reference-target-explainer.md
• User research: None
• Security and Privacy self-review²: N/A; as per the explainer this does not expose new data to sites and we do not anticipate any privacy or security concerns.
• GitHub repo: https://github.com/WICG/aom
• Primary contacts (and their relationship to the specification):
  • Ben Howell (@behowell), Microsoft, proposal author
  • Dan Clark (@dandclark), Microsoft
• Organization/project driving the design: Microsoft Edge
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5188237101891584

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): Unknown
• Existing major pieces of multi-implementer review or discussion of this design: Reference Target for Cross-Root ARIA mozilla/standards-positions#1035, Reference Target for Cross-Root ARIA mozilla/standards-positions#1035
• Major unresolved issues with or opposition to this design: None known at this time.
• This work is being funded by: Microsoft

You should also know that...

There have been a number of competing proposals in this area but little progress towards actually shipping solutions in browsers. See https://alice.pages.igalia.com/blog/how-shadow-dom-and-accessibility-are-in-conflict/.

For that reason this proposal is carefully scoped with the goal of identifying pieces of functionality with good prospects of reaching consensus such that they can be shipped and made available to developers, whose feedback will help inform additional work.

Hence, the proposal in the explainer is broken down into two phases. Phase 1 adds the ability to designate a single element as the target for all IDREF properties that refer to the host, while Phase 2 adds the ability to re-target specific properties individually. Breaking it down in this manner may allow us to reach consensus on Phase 1 while the more complex details of Phase 2 are still under discussion.

So if the TAG has feedback or concerns that apply to Phase 2 only, but is happy with Phase 1, it would be helpful for us if that is called out specifically so that Phase 1 can more easily move forward.

[jyasskin]

This isn't a TAG opinion, but I wanted to point out that there's a known gap across the whole platform in the ability of IDREF attributes to refer to what authors want: w3ctag/gaps#2. I know that this particular gap in ARIA references has lingered for a very long time, and I don't want to delay getting it fixed, but it's also important to keep looking for a unified strategy to deal with all of these relation types.

[jyasskin]

We discussed in the TAG meetings this week, and while we haven't reviewed Phase 2 yet, we're in favor of you moving ahead with solving the piece of this (Phase 1) that you have general agreement on. We'll continue reviewing Phase 2 in future weeks.