ARIA element reflection across non-descendant/ancestor shadow roots

[nolanlawson]

In the current proposed implementation of ARIA element reflection in WebKit, as well as the relevant PR on the spec (whatwg/html#3917) and this WPT test, element reflection only works for elements whose shadow roots are either the same, or in a descendant/ancestor relationship:

If element's explicitly set attr-element is a descendant of any of element's shadow-including ancestors, then return element's explicitly set attr-element. Otherwise, return null.

As discussed previously, though (whatwg/html#4925 (comment)), there are use cases where the elements' shadow roots may have sibling (or cousin, aunt/niece, etc.) relationships.

For instance, following the ARIA 1.1 Combobox with Listbox Popup example, an implementation with web components might look like:

<fancy-input>
  #shadow-root
    <input type="text">
</fancy-input>
<fancy-listbox>
  #shadow-root
    <ul role="listbox">
      <fancy-option>
        #shadow-root
          <li role="option">List item</li>
      </fancy-option>
    </ul>
</fancy-listbox>

In this case, the web author may want to set the <li> to be the ariaActiveDescendant of the <input>. However, their shadow roots are not in a descendant-ancestor relationship, so attempting to set the ariaActiveDescendant would be a no-op.

With some tinkering of the DOM hierarchy, it's possible to work around this restriction:

<fancy-input>
  #shadow-root
    <input type="text">
    <fancy-listbox>
      #shadow-root
        <ul role="listbox">
          <fancy-option>
            #shadow-root
              <li role="option">List item</li> <!-- shadow descendant of the <input> -->
          </fancy-option>
        </ul>
    </fancy-listbox>
</fancy-input>

However, this requires the <fancy-listbox> to be inside the <fancy-input>'s shadow root, which increases the scope of <fancy-input> beyond just enhancing the <input>.

Another potential alternative is to use cross-root ARIA delegation to have the <input> delegate its aria-activedescendant to the <fancy-input> host, but AFAICT the current version of that spec doesn't handle element ID ref attributes like aria-activedescendant.

If I understand the previous summary (whatwg/html#5401 (comment)), this restriction was put in place to avoid leaking internal component details. If we assume all of the shadow roots are open, though, then I'm not sure that that argument is still as strong. It feels like the restriction makes wiring up relationships across shadow boundaries very tricky, whereas in the light DOM world we don't have any similar restrictions.

Would this group be open to relaxing the restriction on cross-shadow ARIA relationships?

/cc @leobalter @mrego

[jcsteh]

If I understand the previous summary (whatwg/html#5401 (comment)), this restriction was put in place to avoid leaking internal component details. If we assume all of the shadow roots are open, though, then I'm not sure that that argument is still as strong.

First, I don't think we can make that assumption. But more importantly, this is less about security and more about encapsulation. As I understand it, one of the major benefits of shadow DOM is that it encapsulates internal details and prevents any leaking or impact of those details (in either direction) except via specifically defined mechanisms. The whole point of shadow DOM is to isolate implementation details. Element references exposed from shadow DOM via the platform would violate that principle.

It feels like the restriction makes wiring up relationships across shadow boundaries very tricky,

I totally understand that this is tricky and tedious. However:

whereas in the light DOM world we don't have any similar restrictions.

That's fair, but in the light DOM, you also don't have other restrictions (and the benefits that come with those) provided by shadow DOM. If isolating internal details is not a requirement, that suggests you don't need to use shadow DOM.

[nolanlawson]

Hi @jcsteh, thanks for the response. A few thoughts:

Element references exposed from shadow DOM via the platform would violate that principle.

In open shadow DOM, it is already possible today to traverse the entire DOM tree. (E.g. kagekiri implements a querySelectorAll() implementation that ignores shadow boundaries.) It's also possible to bubble events past shadow boundaries with composed: true. Inherited styles also leak into shadow roots. In principle, shadow DOM provides encapsulation, but in practice, the boundaries are porous.

So to me, it seems uncontroversial to allow two open shadow roots to link elements with aria relationships – it doesn't expose any new API surface that wasn't already exposed elsewhere. (Closed shadow DOM is another story, but let's set that aside for a moment.)

I guess for me the question is: "Why is it acceptable for elements in separate shadow roots to be linked with aria relationships, but only if those shadow roots are in a descendant-ancestor relationship (and only in one direction)?" To me, it's not clear what benefit this particular restriction provides.

As for closed shadow roots, it does seem tricky to provide a safe way for elements in separate shadow roots to be linked with aria relationships. But unless I'm missing something, it seems that the important distinction is open vs closed, not ancestor vs descendant (or any other relationship between shadow roots). A closed shadow root containing another closed shadow root should still not have access to internal implementation details (in principle).

If isolating internal details is not a requirement, that suggests you don't need to use shadow DOM.

At Salesforce, we use shadow DOM on our platform to provide encapsulation guarantees. However, we would still like a well-defined path to relax these guarantees to enable certain use cases, such as accessibility.

Drawing on the previous example, the <fancy-input> and <fancy-listbox> are encapsulated from one another (and may have been built by two different teams). However, we would still like a way to build to build a <fancy-combobox> on top of these two primitives (which may be built by a third team). The descendant-ancestor restriction would (AIUI) require <fancy-listbox> to be inside of <fancy-input>'s shadow root, breaking that encapsulation.

[jcsteh]

In principle, shadow DOM provides encapsulation, but in practice, the boundaries are porous.

Porous, yes, but clearly defined with regard to leaking element references. That is, you need to explicitly choose to dive into the shadowRoot to access elements inside it; it doesn't just happen as a side effect of some other API. The problem with ARIA element reflection is that this boundary crossing would not at all be explicit.

I guess for me the question is: "Why is it acceptable for elements in separate shadow roots to be linked with aria relationships, but only if those shadow roots are in a descendant-ancestor relationship (and only in one direction)?" To me, it's not clear what benefit this particular restriction provides.

Initially, the objection raised by Mozilla was that there should never be any shadow boundary crossing at all. I guess this was relaxed as a compromise.

At Salesforce, we use shadow DOM on our platform to provide encapsulation guarantees. However, we would still like a well-defined path to relax these guarantees to enable certain use cases, such as accessibility.

The issue here is "well-defined path to relax these guarantees". If the change you suggest is implemented, there would be no explicit choice to relax them with ARIA element reflection. They would just always be relaxed.

CC @annevk.

[nolanlawson]

@jcsteh Thanks again for the feedback and context.

That is, you need to explicitly choose to dive into the shadowRoot to access elements inside it; it doesn't just happen as a side effect of some other API. The problem with ARIA element reflection is that this boundary crossing would not at all be explicit.

In open shadow DOM, with my proposal, you would still need to explicitly traverse into a shadow root (e.g. using element.shadowRoot.querySelector(...)) in order to link two cross-shadow elements via ARIA reflection. IDs are scoped to shadow roots, so ID refs wouldn't suffice.

For closed shadow DOM, the component would need to offer an explicit API to provide access to the element that it wants to be linked. E.g.:

customElements.define('fancy-option', class extends HTMLElement {
  #shadow = null
  
  constructor() {
    super()
    this.#shadow = this.attachShadow({ mode: 'closed' })
    this.#shadow.innerHTML = '<li role="option"></li>'
  }
  
  get option() {
    return this.#shadow.querySelector('li')
  }
})

otherElement.ariaActiveDescendantElement = $('fancy-option').option

Otherwise it's impossible for anyone else to access its shadowRoot, and thus to set that element as the aria* property of another element.

[jcsteh]

Once it's linked, though, you can fetch the element from that property. For example, if you set foo.ariaActiveDescendantElement to something inside a shadow DOM, anyone with access to foo can then get that shadow element via foo.ariaActiveDescendantElement, potentially without even knowing they've crossed the shadow boundary. There was a proposal a while ago to avoid exposing the value in this instance, but this isn't ideal for authors because they don't have a good model of what an AT actually sees if the properties sometimes report null when in reality they refer to some shadow element.

[mrego]

There are a bunch of previous discussions quite similar to this one.

See for example whatwg/html#6063 which points to #169.
Also this delegation proposal: WICG/webcomponents#917

Or other things not directly related to ARIA properties: whatwg/html#3219 & WICG/webcomponents#179

[nolanlawson]

Once it's linked, though, you can fetch the element from that property. For example, if you set foo.ariaActiveDescendantElement to something inside a shadow DOM, anyone with access to foo can then get that shadow element via foo.ariaActiveDescendantElement, potentially without even knowing they've crossed the shadow boundary.

Thanks, I think I understand the concern now. I'm still not clear on why descendant/ancestor relationships are a special case, but the problem we're trying to solve is clear to me.

[annevk]

As I understand it you can go upwards currently, but not downwards. That preserves encapsulation. As in, if you have a single shadow tree it's fine to link from there to outside of it, but you shouldn't have a link from the outside to inside the shadow tree.

[nolanlawson]

@annevk Thank you! After re-reading the language in Alice's PR to whatwg/html, I think I understand now. The spec says that in this case:

element1.ariaActiveDescendantElement = element2

... element2 must be contained within a shadow ancestor of element1. I had it backwards – I thought it had to be a descendant!

That does preserve the encapsulation you mention (i.e. exposing the same information you could get from walking up the tree, which works even for closed shadow roots). But I think unfortunately it makes the combobox situation worse. I don't see how a web developer could reasonably structure it so that the active listbox option is in a shadow ancestor of the <input>:

<fancy-listbox>
  #shadow-root
    <ul role="listbox">
      <fancy-option>
        #shadow-root
          <li role="option">List item 1</li> <!-- shadow ancestor of the <input> -->
            #shadow-root
              <fancy-input>
                #shadow-root
                  <input type="text">
              </fancy-input>
      </fancy-option>
      <fancy-option>
        #shadow-root
          <li role="option">List item 2</li>
      </fancy-option>
    </ul>
</fancy-listbox>

// This works because listOption1 is in a shadow ancestor of the input
input.ariaActiveDescendantElement = listOption1

As you can see, the <input> would have to be moved around every time the active descendant changes (i.e. the user presses ArrowUp/ArrowDown on the combobox to change the active list option). Unless I'm missing something, a standard combobox could not be implemented in a way that aligns with the ARIA element reflection requirements.

[nolanlawson]

I'm not sure if this has been discussed elsewhere, but just to propose a solution, could we enforce the descendant/ancestor restriction only on closed shadow roots? This would preserve the original intention of the restriction, which is to avoid exposing an element that isn't already exposed.

In other words:

element1.ariaActiveDescendantElement = element2

Relationship between elements	Shadow mode	Allowed?
element1 and element2 are in the same shadow root	Any	✅
Any (sibling, cousin, ancestor, descendant, etc.)	All shadow roots separating element1 from element2 are open	✅
element2 is in a shadow-ancestor of element1	Any shadow root separating element1 from element2 is closed	✅
Any other relationship	Any shadow root separating element1 from element2 is closed	❌

In the case of open shadow roots, both elements are already exposed. Whereas in the case of closed shadow roots, only ancestors are exposed (by walking up the tree). So this restriction would exactly match the status quo in terms of exposure.

[annevk]

Yeah that has been discussed and dismissed. We want a solution that works for open/closed. I recommend studying the links in @mrego's comment above: #192 (comment). In particular #169 and WICG/webcomponents#917.

[nolanlawson]

Thanks, I read through the comment threads. In particular I see this comment:

The fact open mode allows a deliberate access isn't an excuse for adding new APIs that break encapsulation.

This is a fair point, but open shadow roots are the default for most web component frameworks that I'm aware of, and it seems odd to force open shadow roots to match closed shadow root semantics moving forward.

WICG/webcomponents#917 talks about cross-root ARIA delegation, which doesn't address my scenario because it's not enough to merely delegate the <input>'s aria-activedescendant to its host – it still wouldn't have access to the list option (<li>), as each list option is inside its own shadow root.

Looking back through previous discussion, Alice sketched out a combobox in this comment. But this example assumes that the list option and listbox share the same shadow root, and that furthermore this shadow root is an ancestor of the <input>. This does not match our own usage pattern at Salesforce. (E.g. the search combobox in our CRM app has separate shadow roots for each list option, and the <input> is a distant cousin of the listbox. This works today only because we are using a shadow DOM polyfill.)

With the current limitation, putting the list options and listbox into the same shadow root, and ensuring that that shadow root is at least an ancestor of the <input> (or its host, with delegation), is certainly the only way to get ARIA reflection for ariaActiveDescendantElement to work properly. However, I think this kind of amounts to a mandate of "use light DOM, not shadow DOM" (i.e. use light DOM as much as possible to avoid crossing shadow boundaries).

[annevk]

I see, sorry you had to explain that again. I think in this case input has access to fancy-listbox so it could set that as ARIA descendant. And that could further delegate that to fancy-option. In principle that would be acceptable and hopefully a future version of that draft can address that.

[nolanlawson]

We discussed this a bit in the AOM meeting today. A high-level summary:

• I presented my statement of the problem.
• Per the spec, if you set element1.ariaActiveDescendantElement = element2 and element2 is not a descendant of a shadow-containing ancestor of element1, then the element1.ariaActiveDescendantElement getter will return null. But the spec is unclear about whether the setter still updates the underlying accessibility tree.
• Per @mrego, the current implementations in WebKit and Chromium may do this, or they may just make the setter a no-op – needs some investigation.
• There seemed to be some agreement that it's a bit "yucky" to be able to call a setter, have the getter return null, and yet the accessibility tree is still updated. But it is potential solution per the current spec.
• @Westbrook presented an alternative proposal that has the advantage of not leaking private internal component details at all.

[mrego]

• Per @mrego, the current implementations in WebKit and Chromium may do this, or they may just make the setter a no-op – needs some investigation.

During my tests on the meeting yesterday I was focusing on the wrong thing, sorry about my misleading comments.

So this is the proposed spec text:

On setting, the IDL attribute must perform the following steps:

1. Let id be the empty string.

2. If the given value:

   • has the same root as this element, and
   • has an id attribute, and
   • is the first element in this element's node tree whose ID is the value of that id attribute,

   then set id to the given value's ID.

3. Set the content attribute's value for this element to id.

4. Set this element's explicitly set attr-element to the given value.

I was focusing in the 2nd step there, but that's the one that updates the attribute to reflect the relationship. That one is not set in Chromium and WebKit when you do element1.ariaActiveDescendant = element2 (and element2 is not a descendant of a shadow-including ancestor), the ariaActiveDescendant attribute on element1 is set to the empty string.

But still 4th step above happens, and internally the explicitly set attr-element is set, and it points to element2.
That's not exposed to the web author, and when you do element1.ariaActiveDescendant as @nolanlawson says you get null. But the question is if that could be exposed to the a11y tree, and if that could be enough.