ElementInternals's ARIAMixin

[annevk]

The setup we have largely works if the values of the attributes are only strings-or-null, but that is no longer the case now we have element(s) references, and there's ambition to make that even less the case (e.g., by fixing w3c/aria#1110).

So we probably need integration with reflect of sorts on the ElementInternals side. It would also help to know what would be ideal for the mapping to AT, which is somewhat unclear at this point as I don't think that's defined at all. I filed w3c/core-aam#152 on that.

cc @mrego @domenic @whatwg/a11y

[annevk]

I think it's safe to assume that AT can handle string values (due to the existing content attributes) and element references (due to that being implemented, but not yet defined).

From that perspective it makes sense to me to try to generalize the reflect primitive to work for Element and ElementInternals.

How to generalize reflect:

• We require that objects that want to support reflect for their IDL attributes have a "get content attribute" and "set content attribute" operation.
• All the reflect algorithms are updated to use these operations.
• ElementInternals uses these operations to update its "native accessibility semantics map".
• Element uses these operations to get and set attributes as per the DOM standard.
• For Element? and FrozenArray<Element>? ElementInternals would need the associated concepts as well of course, both for bookkeeping and exposing to AT. For those attributes the "native accessibility semantics map" ends up being somewhat pointless. We could try to do more clever things here if we wanted to, but I think it make some sense to stay close to how Element solves this to keep the mental model simpler.

If that plan makes sense I'm happy to work on it, might have to wait a little bit due to other commitments. Thoughts?

[domenic]

I think it's safe to assume that AT can handle string values (due to the existing content attributes) and element references (due to that being implemented, but not yet defined).

This is an interesting way of slicing the problem. It definitely reduces some complexity by avoiding solving the longstanding issue of how ARIA-provided strings are actually processed. For example, there is no spec today to my knowledge for what happens if you do aria-checked="asdf" or aria-checked=" true " or even aria-checked="TRUE". It'd be nice if we didn't have to solve that at the same time.

With that in mind, here's how I think this might be defined if we were starting from scratch. We'd be targeting a getTheCurrent(X, element) where X is one of role, aria-checked, aria-labelledby, etc. This does:

1. If the element has an X-associated element, then return it. (Even if it's null.)

2. Otherwise, if the element's native accessibility semantics map[X] exists, then return it.

3. Otherwise, return the default value for X.

The problem is then about ensuring the native accessibility semantics map has the correct thing, when the ElementInternals property is a non-string and non-element. For this I don't think we need to generalize reflect. We just need an algorithm for converting non-string non-elements into either strings or elements. (In practice, we just need an algorithm for converting numbers into strings.)

This seems a good bit simpler than what you describe, and doesn't mean changing reflect which is somewhat foundational. What do you think?

[annevk]

We discussed this a bunch more on Matrix: https://matrixlogs.bakkot.com/WHATWG/2022-10-28.

TL;DR: there's quite a bit of redundancy in my approach as ElementInternals doesn't require an as complicated setup, so we'll want to explain that it's done that way to ensure API consistency as well as making it easier to define new attributes (no special care needed for ElementInternals).

[annevk]

There's now a draft for this work: #8496. (Early days still, but would appreciate feedback on the approach.)

[mrego]

Sorry I'm not finding the time to review this properly, let's add @alice in the loop to see if she can dig into this.

[alice]

I had a chat with Anne about this issue to try and clarify the goals of this work, since I was having trouble following them from the issue alone.

This work began as Anne noticed some potential issues with the way ARIAMixin is used on ElementInternals:

• Element/FrozenArray<Element> attributes are set directly with no checking of Shadow DOM, and in fact not even any checking whether the related element is even in the same document
• Also, ElementInternals has no equivalent to the cached attr-associated elements mechanism used on Element "to preserve the invariant that element.reflectedElements === element.reflectedElements"
• It's not clear what the getters on ElementInternals for the ARIAMixin attributes should return when the value is missing - there is no equivalent to the missing value default for content attributes
• There is a potential maintenance burden when new attributes (attribute types?) are added to ARIAMixin

So, the refactoring in #8496 aims to address these issues by making ElementInternals' ARIAMixin attributes use the same logic as content attribute reflection:

• since it will go through the same logic, shadow DOM and same document checking and will happen automatically; likewise, the implementation details around caching values will be carried across
• similarly, missing value defaults will be equivalent between content attributes and ElementInternals
• and any new attributes/attribute types will only need to define their validation rules in one place.

During our discussion I questioned whether it was necessary to hide elements in shadow DOM from ElementInternals the way we do for the "public" DOM API. Anne agreed that it might not be necessary given that ElementInternals is, like shadow DOM itself, intended to be a private API for custom elements to use for their own implementation details, so the risks of exposing implementation details are much less of a concern. There is now a separate issue for that.

I also wondered what the most useful thing might be in the case where no value has been set on ElementInternals for an ARIAMixin attribute, and an author calls the getter; this will depend on how Custom Element authors will want to interact with ElementInternals.

We also need to specify what the native accessibility semantics map exposes to accessibility API mapping logic when there is a missing value. Anne's proposed solution also handles this automatically.

I definitely agree that the process of adding new ARIA/ARIAMixin attributes should be as streamlined as possible, so I'm going to take some time to think through what is required in the current set-up to add new attributes, and how else we might make that easier. And similarly, that any critical validation that occurs as part of the reflection logic and needs to also happen on ElementInternals shouldn't need to be updated in two places.

Anne also noted as we were talking that it's not clear how the cached attr-associated elements mechanism for FrozenArray<Element> is garbage-collected. (Issue.)