RE: Making ARIA and native HTML play better together

> From: Maciej Stachowiak [mailto:mjs@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 <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.
> 

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

Received on Tuesday, 12 May 2015 09:43:21 UTC