W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

RE: [Custom] Custom elements and ARIA

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Thu, 28 Aug 2014 14:57:00 +0000
To: Steve Faulkner <faulkner.steve@gmail.com>
CC: public-webapps <public-webapps@w3.org>
Message-ID: <1409237828298.48068@domenicdenicola.com>
Hi Steve, thanks greatly for your help. It's clear now that I should have reached out to you for your expertise directly before being very wrong on a public mailing list :)

From: Steve Faulkner <faulkner.steve@gmail.com>

> It appears (please correct me) you have made the assumption that 'strong native semantics' for roles is a UA requirement? This is not the case (in the W3C HTML spec [1] at least, can't speak for where the WHATWG spec has gone in defining ARIA in HTML), they  are author conformance requirements. 

Yes, I was misled about that pretty badly. That changes things, as it means there are no non-overridable roles or stoperties (as you show with <hr role="menuitem">). From my reading though, the default implicit ARIA semantics are still UA requirements, right?

To be clear, my concern is entirely about UA requirements, so anything authoring-related is irrelevant to me.

> The HTML spec (any brand) does not define how HTML features map to platform accessibility APIs. This is being normatively defined in the HTML Accessibility API Mappings specification [2].
>
> Would it be worth considering exposing the  platform accessibility APIs used in the browser, to JS so that custom elements can be implemented to fully reflect native element accessibility implementations?

zcorpan pointed out this strategy in IRC as well. I think it is worth exploring. Although, I was hoping to use ARIA as a platform-independent interface into native platform accessibility APIs; that is, I was assuming that everything a native or custom element would want to do could be expressed with ARIA. But, you state earlier in your message that:

> I don't think it is currently possible to define the browser accessibility API mappings in terms of ARIA as it defines and incomplete set of roles,states and properties used in acc APIs.

This seems unfortunate. Why is that? Could you give an example?

Would it be more fruitful to augment ARIA in some way, instead of trying to bypass it and go directly to platform accessibility APIs? The latter seems like it would require a platform-agnostic intermediate layer to be defined, which feels redundant with ARIA...

Received on Thursday, 28 August 2014 14:57:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC