Back to all features
Open for signals Web components

Reference target

The referenceTarget property of a ShadowRoot object forwards attributes such as for and aria-labelledby to elements inside a shadow DOM. You can use this to, for example, link a <label> to its <input> even if the <input> is in the shadow DOM of a web component.

Community use cases (3)

Community signal summary

Developers strongly advocate for referencetarget to solve cross-root ARIA relationship limitations within web component design systems [1][3]. An engineer at Red Hat highlighted that complex component compositions—such as linking internal shadow DOM controls (combobox, listbox) inside <rh-select> to child elements—are currently impossible or require severe architectural compromises [3]. Similarly, an engineer at Adobe noted that delivering accessible custom element libraries requires bypassing native aria-* attributes in favor of custom APIs to pass accessible values across shadow boundaries [1]. Additionally, developers building server-side rendering (SSR) libraries emphasize that JS-based emulation layers cannot run on the server without a DOM, forcing applications to wait for client-side hydration [2].

To bridge this gap, teams currently rely on bulky JavaScript element-resolving scripts to manage DOM relationships manually [1][2]. These workarounds introduce fragile code paths, inflate bundle sizes, and increase CPU and bandwidth overhead for end users [1]. Sentiment across developers is overwhelmingly enthusiastic and urgent, with teams framing referencetarget as a critical, hard requirement to eliminate brittle JS layers, reduce client bundle overhead, and natively support accessible Web Components in SSR environments [1][2][3].

What I want to do with the feature

Reduce the amount of code required to deliver my company's custom element design library accessibly so that the applications and features built with it can be smaller and more performant; making them more accessible not just for the screen reader users this API supports directly but for all users who need less bandwidth, CPU, et al to run the code we deliver to them.

What I'm having to do in the meantime

  • use custom API (instead of native aria-*) to pass accessible values through shadow boundaries to ensure they are applied to the right element
  • leverage bulky element resolving JS to capture the accessible/functional DOM relationships that would otherwise be made via these attribute references and manage them in the JS space

Each of these, and other smaller work arounds, are all fragile and complicated in ways that will thankfully no longer be required once Reference Target lands.

justinfagnani
Stealth Mode Startup™

What I want to do with this feature

I want to support more accessible web components in our SSR library. The JS code that people use to emulate reference target like behavior isn't not something we can support on the server without a DOM.

What I'm having to do in the meantime

Some people may manage to make some of their code work in SSR, but in general this requires a client page to wait for JS and hydration.

What I want to do with this feature

At Red Hat, we maintain a web-components design system. We need to run cross root aria for cases like this:

<rh-select>
  <rh-option>...</rh-option>

In which case rh-select's shadow root has a combobox input, button, and listbox.

What I'm having to do in the meantime

We need to make complex compromises, and some cases are simply impossible for us. Reference targets is a hard requirement for us.