Re: [Custom] Custom elements and ARIA

Hi Domenic,

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>


On 28 August 2014 15:57, Domenic Denicola <domenic@domenicdenicola.com>
wrote:

> 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 :)
>

don't worry same thing happens to me all the time.

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


For roles this is true, for states and properties native wins where
specified (as Simon pointed out)


> From my reading though, the default implicit ARIA semantics are still UA
> requirements, right?
>

yes, these are what i pulled out of the spec and tested for HTML CR:
http://stevefaulkner.github.io/html-mapping-tests/ This doc lists all the
(ARIA section) UA requirements from the HTML5 CR spec, testing results for
the 4 major browsers, and browser bugs filed where needed.




>
> 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?
>

I guess because ARIA is not trying to be provide a general abstraction of
all roles,states and properties. The only cases (generally) where native
features express role/state/property values in terms of ARIA in the acc
APIs are where no platform acc API role/state/property exists.

IA2 has a caption role that FF maps to the figcaption element, ARIA does
not.



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

Possibly, I would suggest pinging the PF mailing list with some ideas would
be a good place to start http://lists.w3.org/Archives/Public/public-pfwg/

HTH