Reference Target: Which attributes are in scope?

[alice]

I think we might want to be a bit more explicit about which attributes should be in scope for this feature.

l think I understand the reasoning behind wanting all attributes [1] to be in scope: I imagine it would be easier to explain that this is simply how ID/reference attributes work, in general. Also, adding an existing attribute into the scope of attributes which support referenceTarget after the feature ships would be a breaking change.

However, there are at least two attributes which seem to me to be potentially out of scope, and I don't see any WPT tests for them:

• headers on <td>/<tr> (listed in the explainer as being in-scope)
• itemref - a global attribute used in Microdata (not listed in the explainer)

If we did exclude those attributes, we would need to consider how to:

1. explain to developers why some attributes don't follow referenceTarget forwarding
2. consider how any future attributes should opt in or out of referenceTarget behaviour.

--

[1] The explainer states:

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)
  • commandfor (proposed in Invokers Explainer)
  • interesttarget (proposed in Invokers Explainer)
• Tables
  • headers

[annevk]

I think it should work for all of them, but maybe itemref is a bit academic as there's no browser implementation that I know of?

[dandclark]

<td>/<tr> headers does seem like it should work, I guess we just missed that in the WPT coverage. Filed crbug.com/383999373.

itemref should work in theory.

The one potential exception I was aware of was aria-owns. My understanding was that the intention of w3c/aria#2266 was to specifically resolve against aria-owns working with reference target. I believe @aleventhal was concerned that the complexity of implementing cross-root aria-owns would outweigh any potential use case. Although based on your more recent conversation in that thread, it sounds like maybe there's a hope that this can eventually work after all? If ariaOwnsElements can be shipped successfully and allows cross-root aria-owns associations, then it seems like aria-owns with referenceTarget would not add significant complexity beyond that.

[alice]

aria-owns is tricky because there are so many ways to get into loops and other pathological situations which need to be guarded against and tested for, since they can cause crashes. There are a bunch of WPT tests for crash scenarios just with vanilla aria-owns, plus several more chrome-internal tests (and probably others not picked up by that search).

I think to add aria-owns support we would probably at the very least need to write tests for cases similar to the cases already tested for vanilla aria-owns, for various combinations of

• ariaOwnsElements
• ariaOwnsElements on ElementInternals
• referenceTarget

It seems that the Firefox team are confident in their implementation of ariaOwnsElements, so they're happy to ship it, but I think the Chromium team feel that more work needs to be done before they would be comfortable doing the same. I'm not sure where WebKit stands, actually. But yeah, until Chromium is comfortable with shipping it, it won't be available in all major engines.

[aleventhal]

+1 to what Alice said. I think we'd want to create most of the same stability tests we have for aria-owns=IDREF but using ariaOwnsElements. Also, we put a request out there for use cases for aria-owns to cross shadow boundaries but heard nothing. I wanted to avoid a situation where a high implementation cost did not pay back in terms of supported use case. Note that regular aria-owns was really, really hard to get right. It's always been one of the leading culprits when the engine hits an assertion indicating that the current tree and processing were in an inconsistent state. It has funny ways of combining with other markup,

[sorvell]

+1 to supporting everything if possible, including aria-owns.

@aleventhal

I think we'd want to create most of the same stability tests we have for aria-owns=IDREF but using ariaOwnsElements.

The web components community group likely can help fill in WPT for this, if that helps.

Also, we put a request out there for use cases for aria-owns to cross shadow boundaries but heard nothing.

Sorry, I missed this. I don't have practical experience with aria-owns, but if it's still needed for cases like combo-box, it would not be uncommon for, say, the input to be in a custom element's shadowRoot and the list of items to be its children, thus crossing shadow scopes. In general, it seems like aria-owns is necessary for exotic, tricky rendering which is potentially a good candidate to encapsulate in a custom element. This is contrived, but imagine an element that sorts children into groups based on some given grouping attributes and renders them visually in a grid (e.g. into even and odd: odd: 1, 3, 5 even: 2, 4, 6).

[dandclark]

I looked deeper into headers and I don't think there's a way to write a WPT that would be universally applicable.

The spec only users headers in the algorithm for assigning header cells, which in https://html.spec.whatwg.org/multipage/tables.html#the-td-element is only optionally required: "User agents, especially in non-visual environments or where displaying the table as a 2D grid is impractical, may give the user context for the cell when rendering the contents of a cell; for instance, giving its position in the table model, or listing the cell's header cells (as determined by the algorithm for assigning header cells)."

In Chromium headers only used as part of the heuristic that determines whether a table should be treated as a table as a data table or layout table for a11y announcements. But the heuristic only checks whether the attribute is empty or not, and doesn't actually follow the reference, so it won't be affected by reference target.

[alice]

I see headers is mapped to AT APIs: https://www.w3.org/TR/html-aam-1.0/#att-headers

However, @dandclark is still correct that we can't write WPT tests for that yet, since it doesn't contribute to role or name computation.

We'll need to wait until WPTs for AAMs are realised before we can write those tests, I think.

In the meantime, I guess we'll just have to write browser-specific tests for that behaviour?