Re: Making ARIA and native HTML play better together

> On May 7, 2015, at 12:59 AM, Domenic Denicola <d@domenic.me> wrote:
> 
> From: Anne van Kesteren <annevk@annevk.nl>
> 
>> On Thu, May 7, 2015 at 9:02 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote:
>>> Currently ARIA does not do this stuff AFAIK.
>> 
>> Correct. ARIA only exposes strings to AT. We could maybe make it do more, once we understand what more means, which is basically figuring out HTML as Custom Elements...
> 
> These are my thoughts as well. The proposal seems nice as a convenient way to get a given bundle of behaviors. But we *really* need to stop considering these "roles" as atomic, and instead break them down into what they really mean.
> 
> In other words, I want to explain the "button" behavior as something like:
> 
> - Default-focusable

This point isn’t correct for built-in buttons on all browsers and platforms. For example, <input type=button> is not keyboard-focusable on Safari for Mac but it is mouse-focusable. Likewise in Safari on iOS (both if you connect a physical keyboard, and if you use the onscreen focus-cycle arrows in navigation view).

This raises an interesting and subtle point. Built-in controls can add value by being consistent with the platform behavior when it varies between platforms. Giving very low-level primitives results in developers hardcoding the behavior of their biggest target platform - generally Windows, but for some mobile-targeted sites it can be iOS. It’s hard to make low-level primitives that can sensibly capture these details. Sure, I guess we could have a feature that’s "default-focusable but only on platforms where that is true for controls you don’t type into”. That is pretty specific to particular platform details though. Other platforms could make different choices. In fact, what controls fall in which focus bucket has changed over time in Safari.

Let’s say you really want to capture all the essences of buttonness in a custom control, but give it special appearance or behavior. I think two good ways the web platform could provide for that are:

(1) Provide standardized cross-browser support for styling of form controls.
(2) Allow custom elements to subclass <button> or <input type=button> (the latter is hard to define cleanly due to the way many form controls are all overloaded onto a single element).

> - Activatable with certain key commands
> - Announced by AT as a button

Buttons also have further aspects to their specialness, such as the way they participate in forms.

I think adding clean primitives for these has value. Adding an easy way to get a package deal of standard button behaviors with greater customizability is also valuable, potentially more so in some circumstances.

(I don’t think ARIA is the best way to invoke a package deal of behaviors though, since it’s already pretty established as a way to expose behavior through AT without having many of these effects. It would risk breaking author intent to change it now.)

Regards,
Maciej

> 
> and then I want to be able to apply any of these abilities (or others like them) to any given custom element. Once we have these lower-level primitives we'll be in a much better place.
>

Received on Tuesday, 12 May 2015 02:34:59 UTC