DOM APIs to expose (accessible) role,states, properties

There has been recent discussion/proposals on various lists; Expanded ARIA APIs for custom elements and more from @domenic

• 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 yet discovered.
• 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.

Element.getComputedRole() thread October and Element.getComputedRole() continued in November

We have an issue to add a getComputedRole() function on Element. This would help application developers as well as accessibility test tools.

This has implementer interest (chrome):

Sure, I think it’s a good idea. How about getComputedAccessibleText next?

also interest from Mozilla and Apple (see threads).

Bugs filed on HTML spec:

• [Bug 27294] New: DOM needs a way to get element’s computed ARIA role and computed label string
• [Bug 27295] New: role and aria-* content attributes should be reflected DOM attributes

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.

Regarding the proposals themselves:

• 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).

Domenic sketched out some proposals here: https://github.com/domenic/html-as-custom-elements/blob/master/docs/accessibility.md - although I’m not sure whether discussing those is on topic for this thread, so I’ll leave my slight tangent there for now.

Hi @aboxhall note the core acc name and description calculation definition has been split out from ARIA and reworked (in progress): Accessible Name and Description: Computation and API Mappings 1.1. Work is needed on the HTML accessible name stuff to reflect this.

@SteveF That link is a 400 for me…

@aboxhall sorry, link now fixed

Right, so the issue is with step 2D:

Otherwise, if the current node’s native markup provides an attribute or element that defines a text alternative, return that alternative as a flat string

just to close the loop a bit for anybody stumbling across this. was further also discussed on list here https://lists.w3.org/Archives/Public/public-html/2014Dec/0027.html

and most of this has morphed into AOM http://wicg.github.io/aom/