What to do about ARIA?

[domenic]

A lot of the vanilla HTMLElement elements have implicit or overridable ARIA roles (I don't entirely understand the difference):

http://www.whatwg.org/specs/web-apps/current-work/#wai-aria

Presumably if we registered e.g. <custom-nav> as HTMLElement, or if we did class CustomHTMLElement extends HTMLElement {} and registered <custom-nav> as CustomHTMLElement, then <custom-nav>s would not get the appropriate navigation role.

How do we hook in to this tag-name to aria-role map? (It's actually more than just tag names; there are other things involved.)

We could emulate it via a switch statement in CustomHTMLElement, which upon creation sets the appropriate role attribute.

But then <custom-nav> wouldn't behave the same way as normal <nav>, e.g. customNav.getAttribute("role") would give "navigation" instead of null.

Seems like we may have found, even in our simplest of elements, a non-extensible part of the web?

[stevefaulkner]

the aria roles/states/properties are used as an abstraction of the various platform accessibility APIs see http://rawgit.com/w3c/html-api-map/master/index.html so there is no ARIA role/state/properties exposed via the DOM or in the browser acc layer unless authors declare them as attributes role=foo ,aria-foo. Even when explicitly declared there is generally no ARIA foo property exposed in acc layer.

[domenic]

Yes, it does seem like there's a missing primitive involved, that queries an element to ask what its implicit and/or overridable ARIA roles are, and then uses them appropriately and/or lets them be overridden by role attributes.

[domenic]

I wrote up a long-ish email on public-webapps outlining the problem. It comes with a few separate documents:

• Intro to the relevant aspects of ARIA
• Representative examples of the various types of built-in HTML <-> ARIA mappings
• A couple sketches at solutions, but I don't like them very much

[domenic]

I realized upon re-reading my May 6 comment that my current (icky) solution sketches are focused on maintaining the correct underlying ARIA state at all times. A better approach would probably be something like what I suggested then, e.g. to have a callback such that when the system queries for the element's aria role or stoperties, we can give them back. This seems promising, although possibly it might not play as well with implementations. Need to dig into Chrome's code tomorrow.