> From: Maciej Stachowiak [mailto:m...@apple.com] > Sent: 12 May 2015 03:34 > > > 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 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. >
Duplicating the platform specific behaviour makes sense - at least from a UX perspective. If it looks like a button, people will expect it to behave like a button - in the way they're used to dealing with buttons on their particular platform/browser/AT/whatever. > 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). It seems there is some agreement that #1 would be a good thing to do. One possible solution would be to revisit the appearance:; property [1], although here opinions differ. It's a conversation for CSS, but fragmenting this discussion right now seems like it might derail some useful thinking. Léonie. [1] https://wiki.csswg.org/spec/css4-ui?s[]=appearance -- Léonie Watson Senior accessibility engineer, TPG @LeonieWatson @PacielloGroup PacielloGroup.com