W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Making ARIA and native HTML play better together

From: Domenic Denicola <d@domenic.me>
Date: Fri, 8 May 2015 12:53:31 +0000
To: "Patrick H. Lauke" <redux@splintered.co.uk>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <1431089609831.68946@domenic.me>
From: Patrick H. Lauke <redux@splintered.co.uk>

> Isn't that, in a way, what we currently have already?

No, not quite.

> - default focusable: add tabindex=0

This isn't default-focusable; this is just focusable. Default focusable means that, in the absence of a tabindex attribute, it is focusable---like <a href> and <button>, and unlike <span> or <a>.

> - activatable with certain key commands: define key command handlers yourself in JS

This has a few issues. Notably, it doesn't accomodate different platform conventions for activation, and it doesn't correctly hook up default actions: if you do myAnchor.addEventListener("click", function (e) { e.preventDefault(); }), navigation will not occur, whereas if you hook up key command handlers to <custom-a>, myCustomAnchor.addEventListener(...) will not have the same effect.

> - announced by AT as a button: role="button"

The problem here is similar to that with tabindex. The attributes (tabindex, role, aria-description, etc.) are meant to allow web app authors to override the default values that a given component might have. A component author, on the other hand, should be able to set the default way in which their component is announced to screenreaders, even when there is no role attribute present. In other words, <my-button> should be announced as a button; we shouldn't require <my-button role="button">.
Received on Friday, 8 May 2015 12:54:00 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC