RE: Making ARIA and native HTML play better together

2015-05-12 Thread Léonie Watson
 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

2015-05-11 Thread Steve Faulkner
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

2015-05-11 Thread Maciej Stachowiak

 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

2015-05-09 Thread Alice Boxhall
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

2015-05-07 Thread Bruce Lawson
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

2015-05-07 Thread Anne van Kesteren
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

2015-05-07 Thread Domenic Denicola
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

2015-05-07 Thread Steve Faulkner
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

2015-05-07 Thread Patrick H. Lauke

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

2015-05-07 Thread Patrick H. Lauke

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