Editorial: Point to "element reference attribute" definitions in HTML for IDREF attributes

[dandclark]

whatwg/html#10995 adds definitions for "single element reference" and "set of element references" attributes, formalizing the concept of attributes that reference other elements via ID.

In this change, update the "Mapping WAI-ARIA Value types to languages" to use these new definitions for "ID Reference" and "ID Reference List" attributes.

This whole section is non-normative.

---

Preview | Diff

[netlify]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	72adb11
🔍 Latest deploy log	https://app.netlify.com/sites/wai-aria/deploys/67d0c05a0fbbb20008c88404
😎 Deploy Preview	https://deploy-preview-2474--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[rahimabdi]

Thank you @dandclark! In addition to the changes you proposed in alignment with HTML, I'm curious if there needs to be more extensive changes where the ARIA spec references "ID reference" (now "single element reference") and "ID reference list" (now "set of element references").

Other places where id reference and id reference list are mentioned include the "Values" table for ARIA attributes, the "Identifies" relationship definition in Important Terms, section 6.2.4 Value defining Characteristics of States and Properties and 8.6.1 ID Reference Error Processing in State and Property Attribute Processing.

Questions for the ARIA WG:

• Should the ARIA Values schema change the WAI-ARIA type for id reference/id reference list to align with HTML? This would also mean changing all instances of "id reference" to "single element reference", and "id reference list" would be changed to "set of element references" including attribute Values tables
• Are there any other changes that should be made to WAI-ARIA value types? For example, aria-relevant is the only attribute that is "token list". As an FYI, part of the IDL work in Migrate eligible ARIA content attributes to enumerated (add missing/invalid value defaults to attribute characteristics tables) #2281 entails removing the following WAI-ARIA types and making them "enumerated": true/false, tristate, true/false/undefined, token.

[spectranaut]

• Should the ARIA Values schema change the WAI-ARIA type for id reference/id reference list to align with HTML? This would also mean changing all instances of "id reference" to "single element reference", and "id reference list" would be changed to "set of element references" including attribute Values tables

I think this is unrelated to this particular PR, but I also think it's a good question. The AAMs use "IDREF" language (example) which is inconsistent with ARIA's use of "id reference"/"id reference list". Since ARIA is host language agnostic, we don't need to use the HTML terms... and possibly we shouldn't, and we should just stick to "id reference" and "single element reference", but I'd like to hear why if you think we should change, Rahim!

[alice]

• Should the ARIA Values schema change the WAI-ARIA type for id reference/id reference list to align with HTML?

I think it would make sense to at least name the WAI-ARIA type in a way that doesn't limit it to ID association, yeah. This was already an issue once the IDL attributes which take an Element or FrozenArray<Element> were added.

I think it might also make sense to add a section discussing (whatever name you decide) attributes under the ARIA Attributes with more information about how these attributes are interpreted, possibly defining a concept like refers to or attr-associated element(s), which could be referred to from the AAMs.

Currently, for example, the Core-AAM guidance for aria-controls says

Relation: IA2_RELATION_CONTROLLER_FOR points to accessible nodes matching IDREFs

I think we might want something like

Relation: IA2_RELATION_CONTROLLER_FOR points to accessible nodes matching elements referred to by aria-controls

OR

Relation: IA2_RELATION_CONTROLLER_FOR points to accessible nodes matching aria-controls-associated elements

but, again, not necessarily using the HTML terminology; either way, where the term is defined in the ARIA spec and mapped out to host languages much like the attribute types are.

[rahimabdi]

I think this is unrelated to this particular PR, but I also think it's a good question. The AAMs use "IDREF" language (example) which is inconsistent with ARIA's use of "id reference"/"id reference list". Since ARIA is host language agnostic, we don't need to use the HTML terms... and possibly we shouldn't, and we should just stick to "id reference" and "single element reference", but I'd like to hear why if you think we should change, Rahim!

@spectranaut Agreed, except in the case when references point to a Element or FrozenArray<> as @alice noted. Perhaps this could be "id or element reference" and "id reference or element list"?

I think it would make sense to at least name the WAI-ARIA type in a way that doesn't limit it to ID association, yeah. This was already an issue once the IDL attributes which take an Element or FrozenArray were added.

@alice I've raised a new issue to investigate this so as to unblock this PR. Thanks!

• Investigate changing ID-based WAI-ARIA value types due to referenceTarget #2487

I think it might also make sense to add a section discussing (whatever name you decide) attributes under the ARIA Attributes with more information about how these attributes are interpreted, possibly defining a concept like refers to or attr-associated element(s), which could be referred to from the AAMs.

Added to an upcoming ARIA WG agenda for discussion.

[rahimabdi]

Thank you @dandclark.