RE: Making ARIA and native HTML play better together
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
Re: Making ARIA and native HTML play better together
On 9 May 2015 at 22:22, Alice Boxhall aboxh...@google.com wrote: 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. Hi Alice, I would not go so far as to call it a proposal ;-) it is just a few ideas , mostly not thought out at this stage and definitley not to be taken as a package. I think idea 1 has the potential to be implemented without being overly burdensome, so forgetting about the ideas for the moment: 1. When a role is used that matches the default implicit semantics of labelable HTML elements [1] use of the label element will result in the same behaviour as the native element and a label. Example: span role=checkbox id=customcheck/span label for=customchecki like this idea/label What this would entail (i think ) is the addition of a defined set of roles to the labelable elements list [1]. So when an element with one of the defined roles is associated with a lable using the for attribute or as a child of label, the behaviour matches that currently defined in HTML The label element's exact default presentation and behaviour, in particular what its activation behaviour might be, if anything, should match the platform's label behaviour. The activation behaviour of a label element for events targeted at interactive content descendants of a label element, and any descendants of those interactive content descendants, must be to do nothing. [2] labelable elements that have default implict ARIA semantics [3] input type=checkbox - role=checkbox input type=radio - role=radio input type=text - role=textbox input type=number - role=spinbox textarea - role=textbox progress - role=progressbar select - role=listbox or combobox So the suggested implementation would be that where a role is used that matches one in the list above, the association of a label element would result in the same behaviour as it does for the corresponding HTML element both interaction behaviour and accessble name association [4]. [1] http://www.w3.org/TR/html51/semantics.html#category-label [2] http://www.w3.org/TR/html51/semantics.html#labeled-control [3] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#html-element-role-mappings [4] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#accessible-name-and-description-calculation -- Regards SteveF
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 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. 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.
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 re...@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.
Re: Making ARIA and native HTML play better together
On 7 May 2015 at 06:43, Steve Faulkner faulkner.st...@gmail.com wrote: On another thread recent thread, leonie and chaals [3] talked about adding behaviours to ARIA. this makes sense, but (unless I'm inventing nonsense because I'm mad, which is definitely possible), doesn't this describe the current behaviour in many UAs anyway? (Or is the aim to record current practice and mandate it in a spec?) bruce
Re: Making ARIA and native HTML play better together
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... -- https://annevankesteren.nl/
Re: Making ARIA and native HTML play better together
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 - Activatable with certain key commands - Announced by AT as a button 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.
Re: Making ARIA and native HTML play better together
On 7 May 2015 at 07:53, Bruce Lawson bru...@opera.com wrote: this makes sense, but (unless I'm inventing nonsense because I'm mad, which is definitely possible), doesn't this describe the current behaviour in many UAs anyway? Currently ARIA does not do this stuff AFAIK. There is some limited keyboard behaviour mapping for role=button in a few AT's. -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: Making ARIA and native HTML play better together
On 07/05/2015 08:59, Domenic Denicola wrote: ... 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 - Activatable with certain key commands - Announced by AT as a button 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. Isn't that, in a way, what we currently have already? - default focusable: add tabindex=0 - activatable with certain key commands: define key command handlers yourself in JS - announced by AT as a button: role=button P -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Re: Making ARIA and native HTML play better together
On 07/05/2015 08:02, Steve Faulkner wrote: On 7 May 2015 at 07:53, Bruce Lawson bru...@opera.com mailto:bru...@opera.com wrote: this makes sense, but (unless I'm inventing nonsense because I'm mad, which is definitely possible), doesn't this describe the current behaviour in many UAs anyway? Currently ARIA does not do this stuff AFAIK. There is some limited keyboard behaviour mapping for role=button in a few AT's. And gesture mapping in certain touchscreen/mobile ATs too - particularly important, as any custom keyboard handling the dev may or may not have implemented wouldn't work there anyway, so AT attempt to understand widgets based on their roles a bit more and provide built-in swipe/tap gestures for certain constructs. P -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
