Add WAI-ARIA 1.3

[autonome]

Ignore current PR content, see comment below.

[autonome]

After reading the conversation on the ARIA attribute reflection PR and reading through the various aspects of existing + ongoing efforts, here are some notes for context, followed by a few challenges, and options to move forward.

Context:

• Latest recommendation is 1.2, June 2023
• The latest draft spec is 1.3, its got new roles and new attributes, we've got a generated draft here in web features
• ARIA generally breaks down along roles and attributes (and attr reflections) - a grouping that is generally maintained both in the spec and in how developers and learning materials refer to it
• The reflected attributes on Element were added as a web feature in aria-attribute-reflection: add initial support feature #857
• ElementInternals is an addition to custom elements (part of the HTML spec), which exposes the ARIA reflected elements, and was added in Add form-associated-custom-elements (ElementInternals) #1003 under the 'Form-associated custom elements` feature
• The reflected attributes span both Element and ElementInternals however
• Caniuse uses key wai-aria to refer to WAI-ARIA Accessibility features, links to the 1.2 version of the spec and has everything at "partial" support, basically not much there aside from a few of the Element refelected attrs it pulls from MDN
• The AOM (a11y object model) is an initiative to get to cohesive/consistent a11y tree, and covering a variety of things from reflected attributes (already a WF, see above), an event model, notifications and more, and seems to be a primary future focus of a11y in browsers
• There are no web feature groups yet related to ARIA / a11y

Challenges:

• The role attribute and its values are ancient, but @role is under ARIA attribute reflection, which is more about the new reflected values part, and not anywhere else
• Various ARIA attributes and properties aren't anywhere except MDN, but have no BCD
• Form-associated custom elements feature rolls up ElementInternals which is not specific to forms really (though is the initial use-case) and has a bunch of ARIA reflected attributes
• ARIA reflected attributes might make sense as a distinct feature in the new AOM world, but doesn't provide a way to bring forward prior related ARIA work that it is ultimately dependent on (we have the reflections, but not the attributes themselves).
• AOM might supercede any work here, but likely we've got a couple of years (at least) to figure that out

What to do?

Handwavey proposal:

• Leave the existing features as-is for now, mostly (see below)
• Make a general ARIA feature w/ role, its values, and the attributes in it (and any missing properties too) - this might pull some bits out of the two features done so far, but does provide a "home base" for the older parts which might actually align w/ the older baseline for them, and BCD will pick up the missing keys this way once sync is done (and then maybe also CIU downstream later)
• Make a group to put all of the above in
• Have some a11y experts and devrels give feedback on this plan
• Revisit as more of AOM ships

That intentionally doesn't touch FACE, since that probably needs discussion separately. And if we want smaller feature components, could split out roles and attributes into feature groups too.