Re: Making ARIA and native HTML play better together

I agree we badly need the primitives, but it seems to me like there is
potentially an easier and maybe even bigger win in making it more
straightforward for developers to reuse existing patterns (like the one you
described for "button" earlier) than in explaining the existing patterns
and allowing developers to create new ones.

As Patrick pointed out, we can approximately explain these things today -
not perfectly, as you demonstrate, but we can achieve much the same
functionality with effort - but we've seen time and time again that
developers aren't going to that effort. If it were more straightforward to
do so, we would probably see some increase in compliance, but it would
still require understanding the existing patterns and knowing that the
effort needs to be made.

However, I'm on the fence about whether this proposal is the way forward
for that problem. On the one hand, many developers (including me) have an
expectation when they first encounter ARIA that it will magically affect
behaviour, so it seems like a good "path of desire" to go ahead and fulfill
that expectation.

On the other hand, as Dominic (with an i) pointed out, this has the
potential to break existing sites. We would need to experiment carefully to
figure out the interactions between existing code and the new behaviour.

Additionally, as it stands today ARIA is a useful tool for explaining the
the semantics side of HTML - we would need to solve a couple of problems
(semantics missing from ARIA and currently only available to native
elements, which should be straightforward to fix, and the issue of
"sprouting" ARIA described below), but overall it's a good starting point.
If we were to modify ARIA to be more than just purely semantic, we would
need to come up with a new mechanism to explain the semantic piece when
developing new patterns.

On Fri, May 8, 2015 at 5:53 AM, Domenic Denicola <d@domenic.me> wrote:

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

We should clarify that adding a role/state/value attributes in lifecycle
callbacks approximates the original intention - yes, it sprouts some ugly
attributes, but it doesn't require the web page author to type <my-button
role="button">.

One potential solution to the "sprouting attributes" problem which has been
discussed elsewhere is to use some variant of the Cascading Attribute
Sheets idea (http://www.xanthir.com/blog/b4K_0) - although that proposal
seems to just apply attributes directly on to the element; I'd prefer to
see it more like CSS where instead of sprouting "style" attributes
everywhere, matched rules affect only the *computed style* of the element,
which is overridden by explicit attributes.