From 1e064b8f2837aae78b8ca9ba72b7940d79994062 Mon Sep 17 00:00:00 2001
From: Ben Howell <48106640+behowell@users.noreply.github.com>
Date: Wed, 26 Jun 2024 16:21:01 -0700
Subject: [PATCH] Move the reference target explainer to the WICG/webcomponents
repo (#211)
---
exportid-explainer.md | 2 +-
reference-target-explainer.md | 610 +---------------------------------
2 files changed, 5 insertions(+), 607 deletions(-)
diff --git a/exportid-explainer.md b/exportid-explainer.md
index 6d8e194..2e01ea1 100644
--- a/exportid-explainer.md
+++ b/exportid-explainer.md
@@ -1,5 +1,5 @@
> [!CAUTION]
-> The Export ID proposal is no longer planned. It has been replaced by the [Reference Target](reference-target-explainer.md) proposal.
+> The Export ID proposal is no longer planned. It has been replaced by the [Reference Target](https://github.com/WICG/webcomponents/blob/gh-pages/proposals/reference-target-explainer.md) proposal.
# Exporting IDs from shadow roots for cross-root ARIA
diff --git a/reference-target-explainer.md b/reference-target-explainer.md
index 076e0dc..0733aba 100644
--- a/reference-target-explainer.md
+++ b/reference-target-explainer.md
@@ -1,608 +1,6 @@
# Reference Target for Cross-Root ARIA
-Author: [Ben Howell](https://github.com/behowell)
-
-## Introduction
-
-Reference Target is a feature to enable 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.
-
-This proposal is based on [@Westbrook](https://github.com/Westbrook)'s [Cross-root ARIA Reflection API](https://github.com/Westbrook/cross-root-aria-reflection/blob/main/cross-root-aria-reflection.md) proposal, as well as borrowing ideas from [@alice](https://github.com/alice)'s [Semantic Delegate](https://github.com/alice/aom/blob/gh-pages/semantic-delegate.md) proposal.
-
-## Background
-
-### Cross-Root ARIA
-
-For an in-depth description the cross-root ARIA problem, see [@alice](https://github.com/alice)'s article [How Shadow DOM and accessibility are in conflict](https://alice.pages.igalia.com/blog/how-shadow-dom-and-accessibility-are-in-conflict/). The article describes the two main problems that need to be solved:
-
-#### 1. Referring from Shadow DOM outwards
-
-The existing [ARIAMixin IDL attributes](https://w3c.github.io/aria/#ARIAMixin) (such as `ariaLabelledbyElements` and `ariaActiveDescendantElement`) unlock part of the solution to the cross-root ARIA problem. They allow for an element inside a shadow DOM to create an ARIA link to an element outside that shadow DOM. However, they are limited in that they can't reference an element inside another component's shadow DOM. The specifics of this limitation are described in more detail in _How Shadow DOM and accessibility are in conflict_.
-
-#### 2. Referring into Shadow DOM
-
-The "missing piece" to solving the cross-root ARIA problem is the ability to refer into Shadow DOM. The Reference Target feature described in this explainer intends to solve this problem in a way that is compatible with the ARIAMixin attributes.
-
-When Reference Target is used in conjunction with ARIAMixin, it is possible to create references between elements in sibling shadow DOMs, or between any two unrelated shadow DOMs on the page, as long as the components have provided the API to do so, through reference targets and custom attributes.
-
-### Web components as drop-in replacements for builtin elements
-
-Web components have an increasing number of features that allow them to work and act like builtin elements. For example:
-
-- [Form-Associated Custom Elements](https://html.spec.whatwg.org/dev/custom-elements.html#form-associated-custom-element) can participate in forms like a builtin input.
-- [delegatesFocus](https://developer.mozilla.org/en-US/docs/Web/API/ShadowRoot/delegatesFocus) allows a component to work better with keyboard navigation.
-
-However, there are still missing pieces that prevent a web component from truly being a drop-in replacement for a built-in, including:
-
-1. Can't create ID reference links to elements inside a [shadow tree](https://dom.spec.whatwg.org/#shadow-trees).
-2. Can't use built-in attributes like `aria-label` or `role` on the host and have them apply to an element inside the shadow root.
-3. Non-trivial amount of code required to hook up custom attributes on the host to ARIAMixin attributes on an element inside the shadow root.
-4. Can't get form-association for "free" by delegating to an input inside.
-
-This proposal solves only the first problem: referring into the shadow DOM. It leaves the other problems to be solved by other features. While all of the problems may seem related, they can be designed separately.
-
-## Proposal: Reference Target
-
-Reference Target is a new feature that enables creating ARIA links to elements inside a component's shadow DOM, while maintaining encapsulation of the internal details of the shadow DOM.
-
-#### Goals
-
-- Solve only the "missing piece" of cross-root ARIA: how to handle IDREF attributes referring into the shadow DOM. Avoid scope creep.
-- Create a mechanism for ID reference attributes like `aria-activedescendant` and `for` to refer to an element inside a component's shadow DOM.
-- Should work the same for both closed and open shadow roots.
-- Shadow DOM encapsulation should be preserved: No direct access to any elements inside the shadow tree, and no implementation details leaked into a web component's API.
-- Should allow creating references into multiple nested shadow roots, and across "sibling" shadow roots that don't have a direct parent/child relationship.
-- The solution should be serializable, i.e. support declarative syntax that is expressible in HTML without needing JavaScript.
-
-#### Non-Goals
-
-- This is scoped to only solve the problem of referring _into_ the shadow DOM. It relies on ARIAMixin to refer _out_ of the shadow DOM.
-- This feature does not solve the [bottleneck effect](https://alice.pages.igalia.com/blog/how-shadow-dom-and-accessibility-are-in-conflict/#limitations-of-these-apis). It is difficult to find a compelling real-world example where this is a problem.
-- This does not affect how attributes set on the host element work. For example, this does not tackle the problem of forwarding `role` or `aria-label`, etc. from the host element to an element inside.
-
-#### Phases
-
-This proposal is broken into two phases:
-
-- [Phase 1](#phase-1) adds the ability to designate a single element as the target for _all_ IDREF properties that refer to the host.
-- [Phase 2](#phase-2) adds a way to re-target specific properties (like `aria-activedescendant`) to refer a separate element.
-
-The goal of breaking it into phases is to get the simpler syntax and simpler use cases working first. The solutions to Phase 2 are more complex and may need more discussion before they are ready.
-
-### Phase 1: ShadowRoot `referenceTarget` attribute
-
-A component can specify an element in its shadow tree to act as its "reference target". When the host component is the target of a IDREF like a label's `for` attribute, the referenceTarget becomes the effective target of the label.
-
-The shadow root specifies the ID of the target element inside the shadow DOM. This is done either in JavaScript with the `referenceTarget` attribute on the `ShadowRoot` object, or in HTML markup using the `shadowrootreferencetarget` attribute on the `` element.
-
-JavaScript example:
-
-```html
-
-
-
-
-```
-
-Equivalent with declarative shadow DOM:
-
-```html
-
-
-
-
-
-
-```
-
-#### Supported attributes
-
-This feature is intended to work with **all** attributes that refer to another element by ID string. These are:
-
-- ARIA
- - `aria-activedescendant`
- - `aria-controls`
- - `aria-describedby`
- - `aria-details`
- - `aria-errormessage`
- - `aria-flowto`
- - `aria-labelledby`
- - `aria-owns`
-- Inputs
- - `for` (also supports the click behavior of labels)
- - `form`
- - `list`
- - `popovertarget`
- - `anchor` (proposed in the [Popover API Explainer](https://open-ui.org/components/popover.research.explainer/#anchoring))
- - `invoketarget` (proposed in [Invokers Explainer](https://open-ui.org/components/invokers.explainer/))
- - `interesttarget` (proposed in [Invokers Explainer](https://open-ui.org/components/invokers.explainer/))
-- Tables
- - `headers`
-
-> _Please comment if there are any attributes missing from this list._
-
-### Phase 2: ShadowRoot `referenceTargetMap` attribute
-
-There are situations where it is necessary to target different reference types to different elements. For example, a listbox may want to target `aria-controls` to its root, and `aria-activedescendant` to one of the items inside the listbox.
-
-The `ShadowRoot.referenceTargetMap` attribute allows for specifying target elements based on the attribute that is being used to reference the host.
-
-The equivalent declarative attribute is `shadowrootreferencetargetmap`, which is a comma-separated list of attribute to ID mappings.
-
-> Note: the syntax of `shadowrootreferencetargetmap` is based on the [`exportparts`](https://drafts.csswg.org/css-shadow-parts/#exportparts-attr) attribute that contains a comma-separated map of part names.
-
-```html
-
-
-
-
-
Option 1
-
Option 2
-
-
-
-```
-
-The JavaScript API reflects the mappings using camelCase names for the properties, and `htmlFor` for `for`:
-
-```js
-this.shadowRoot_.referenceTargetMap.ariaControls = "real-listbox";
-this.shadowRoot_.referenceTargetMap.ariaActiveDescendant = "option-1";
-this.shadowRoot_.referenceTargetMap.htmlFor = "real-input";
-```
-
-#### Live references
-
-Reference targets are a "live reference": if the host internally changes its reference target mapping, any element that references the host will use the updated mapping.
-
-In the example above, if the `aria-activedescendant` mapping is changed, then the `aria-activedescendant` of `` will be changed to refer to the newly-mapped element.
-
-- **Before**: `` initially maps to 'option-1'.
-- fancy-listbox internally updates its mapping:
- ```js
- this.shadowRoot_.referenceTargetMap.ariaActiveDescendant = "option-2";
- ```
-- **After**: `` now maps to 'option-2', without needing to update the input element itself.
-
-#### Combining `referenceTarget` and `referenceTargetMap`
-
-In the case where both attributes are specified, `referenceTargetMap` takes priority for individual attributes, and `referenceTarget` acts as the fallback for attributes that are not specified.
-
-In the example below, `"real-listbox"` is the target for all attributes _except_ `aria-activedescendant`, which is targeted to `"option-2"`.
-
-```html
-
-
-
-
-
Option 1
-
Option 2
-
-
-
-```
-
-#### Delegating to multiple elements
-
-Some attributes such as `aria-labelledby`, `aria-describedby`, etc. support multiple targets. Using `referenceTargetMap` with those attributes support a space-separated list of IDs.
-
-This example shows a `` component that contains a "More Info" button to show the tooltip but is not intended to be included in the description text. It targets `aria-describedby: message tooltip` to forward to only the content that should be included in the description text.
-
-```html
-
-
-
-
-
- Inline description text.
-
-
Tooltip with more information.
-
-
-
-```
-
-### Interaction with other features
-
-#### Interaction with CSS Selectors
-
-The referenceTarget does not affect CSS selectors in any way. An ID selector will target the host element that has the matching `id` attribute, and _not_ its referenceTarget.
-
-#### Form-associated custom elements
-
-A [form-associated custom element](https://html.spec.whatwg.org/dev/custom-elements.html#form-associated-custom-element) supports being the target of a label's `for` attribute. But if the element has a Reference Target for the `for` attribute, then the label applies to the target instead. There are no other changes to the behavior of a form-associated custom element.
-
-#### Nesting inside `