> On May 7, 2015, at 12:59 AM, Domenic Denicola <d...@domenic.me> wrote:
> From: Anne van Kesteren <ann...@annevk.nl>
>> On Thu, May 7, 2015 at 9:02 AM, Steve Faulkner <faulkner.st...@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 

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


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

Reply via email to