An expansion of ARIA’s vocabulary to cover all things currently exposed to the accessibility tree by native elements: e.g. adding a
caption and paragraph role, but presumably lots more that I have not
A way to customize an element’s “implicit role”.
A way to control an element’s “enforced states and properties”.
A way to customize an element’s accessible name and description.
Yes, this would be extremely helpful for extension development, for instance. Currently, if I want to create a simple extension that, say, gives an overview of landmark regions, my code has to iterate over anything with a role="…" attribute in the markup AND through a list of HTML elements that have built-in roles (nav, header, etc). It would be much slicker to be able to just iterate once over the DOM, based on the computed role.
This is only semi-related, but aria-labeledby could also use an api IMO as it can contain N labels it’s actually pretty salty and underlying it you should be able to ask the same conceptual question of anything referenced by label for="". Something like class/classList maybe because it’s somewhat similar might be helpful at one level.
I like the idea of exposing the computedRole and computedLabel (computedName?) attributes as read-only properties (similar to something like element.scrollHeight).
Would we consider bundling all of the ARIA attributes (including role?) into one property on the element, of some new type named something like ARIAProperties, which could contain all possible ARIA properties for an element (but still reflect anything which is non-empty). Something like myElement.aria.checked = 'true' --> <my-element aria-checked="true">. This would allow us to avoid ballooning out the set of possible attributes on Element.
The bugs filed don’t fully solve the problem Domenic raised, as far as I can tell (although I certainly believe they’re worthwhile anyway).
Reflecting ARIA attributes in the DOM Element API doesn’t solve the following problem:
Suppose I am trying to recreate <button> as a custom element. I’ll need some way of specifying that this thing is always a button, unless its role gets overridden. However, if I just set the role attribute, someone could come along to my element and set element.role = '', at which point it would lose all its semantics. If I set role = '' on a <button>, it’s still a button. So, we need some non-reflected mechanism which is only available to the custom element layer (scoped similarly to lifecycle callbacks, perhaps) in order to provide this.
Similarly, we need non-reflected mechanisms for specifying the default state, value, and computed text for an element (i.e. those which will be present even if a user removes all of the reflected ARIA attributes - note that these may vary over time). So, as well as having a mechanism for getting the computed text of an element, we need a mechanism for custom elements to specify what that should return. Consider trying to implement this logic http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#accessible-name-and-description-calculation using only custom elements (i.e. if we were re-implementing the native elements from scratch using the custom elements layer).