RE: Slides of my WAI-ARIA presentation at SpainJS event

From: Bryan Garaventa [mailto:bryan.garaventa@whatsock.com]
> Here's a question I'd be curious to know the answer of, when you put ARIA
tags on an element, is it expected to change the nature of the element even
when there is no Assistive Technology running?

The key thing about ARIA is that it doesn't actually change the nature or
behavior or functionality of an element in the first place. Instead, it
changes how that element appears when exposed through an accessibility API.
So all it is doing is changing a screenreader's *view* of the element -
which of course changes how the screenreader behaves - but that's it, it
should have no other side-effects within the browser. Think of it as the
screenreader looking at the underlying DOM but through ARIA-tinted glasses,
so it sees a 'corrected' accessibility tree, with ARIA specifying the fixes.
This benefits any client of an accessibility API - whether screenreader,
test tool such as inspect, or perhaps a speech command-and-control app. The
converse of this is that ARIA attributes are of no use to any user who's not
using such a tool; so they won't help you with keyboard accessibility.

So the answer here is that use of ARIA shouldn't change the nature of the
element either way. Contrast this with say using tabindex which does change
actual keyboard interaction behavior. Or, compare the disabled attribute on
an input element, which prevents a user - whether using keyboard and/or
screenreader or neither - from interacting with an element, versus the
aria-disabled attribute, which only causes a screenreader to *report* the
element as disabled, but has no actual effect on the behavior of that
element. 

And this is a good thing: it means a developer can use ARIA to 'fix up' the
accessibility tree that the screenreader sees, and be confident that they're
not going to have other side effects that break any other javascript or
input handling code that’s already on the page. ARIA functions more like a
scalpel than a sledgehammer here.

> I'm not sure this is a browser bug though, since non-actionable elements
like spans and divs aren't supposed to handle key press events in addition
to clicks.

Correct; the issue here is that A and BUTTON and similar are interactive
elements, and they have triggers - eg pressing space and/or enter, depending
on the element - that causes them to go and do something, and you get a
click event when that happens. But DIV, LI and so on don't have any
associated behavior or triggers, so only fire click when actually clicked
with a mouse. So if you want to build your own interactive element out of
these, you need to add both mouse and keyboard handlers appropriately. So
not a browser bug, just how HTML works.

Brendan
--
Brendan McKeon / brendan_mckeon@hotmail.com

-----Original Message-----
From: Bryan Garaventa [mailto:bryan.garaventa@whatsock.com] 
Sent: Monday, July 09, 2012 12:46 PM
To: Emmanuelle Gutiérrez y Restrepo; Chaals McCathieNevile
Cc: Steve Faulkner; WAI Interest Group; Ramón Corominas
Subject: Re: Slides of my WAI-ARIA presentation at SpainJS event

This was when I was building my footnotes demo at
http://whatsock.com/modules/aria_footnote_generator_module/demo.htm

It's been about 9 months or so since then, but I believe it happened in IE
and FF.

I'm not sure this is a browser bug though, since non-actionable elements
like spans and divs aren't supposed to handle key press events in addition
to clicks.

Here's a question I'd be curious to know the answer of, when you put ARIA
tags on an element, is it expected to change the nature of the element even
when there is no Assistive Technology running?

I wouldn't think so, since the DOM structure remains the same, just with
additional attributes. A span tag is still a span tag regardless.

----- Original Message -----
From: "Chaals McCathieNevile" <w3b@chaals.com>
To: "Bryan Garaventa" <bryan.garaventa@whatsock.com>; "Emmanuelle Gutiérrez
y Restrepo" <coordina@sidar.org>
Cc: "Steve Faulkner" <faulkner.steve@gmail.com>; "WAI Interest Group" 
<w3c-wai-ig@w3.org>; "Ramón Corominas" <listas@ramoncorominas.com>
Sent: Monday, July 09, 2012 10:20 AM
Subject: Re: Slides of my WAI-ARIA presentation at SpainJS event


On Mon, 09 Jul 2012 16:31:03 +0200, Emmanuelle Gutiérrez y Restrepo
<coordina@sidar.org> wrote:

> Good point Bryan,
>
>> "Proper scripting is always necessary toensure functionality for 
>> users that cannot benefit from ARIA."

> It is important to note that, for all developers.

Indeed.

> 2012/7/9 Bryan Garaventa <bryan.garaventa@whatsock.com>
>> Actually I ran across this not too long ago, where I had a Span tag  
>> with
>> tabindex=0 and role=link, and tried using just a click event to  
>> handle the keypress.
>>
>> This worked fine for screen reader users, but failed completely for 
>> keyboard only users not using a screenreader.

On what browser(s)? Did you file bugs, or do you know of them for the
relevant browsers? Maybe you could add them to the a11ybugs list of things
to annoy browser makers about...

>>>  ----- Original Message -----
>>>  From: Steve Faulkner

>>>> I think pretty much all browsers allow  activating click events 
>>>> with the keyboard, and will add things if  you give them a 
>>>> tabindex. So adding specific keyboard >handling is probably 
>>>> redundant if you're just using click (mouseover, focus, and various 
>>>> other things are still not so good).
>>>
>>> I think you are right, but need to take into account keyboard  
>>> behaviour for things like buttons, which require activation on space  
>>> key press as well as enter key

Why? The specific mechanism for activation should be able to vary between
browsers*. Authors trying to guess which keys I have available on whatever
device is in front of me cause massive problems in general. It is true that
not all users know how to use their browser, but actively making it not work
isn't a very good solution and should only be done as a last resort.

*for usability the basics should be the same where possible - e.g. Opera
should fix the fact that they use the tab key for form-only navigation and
ctrl-arrows for "tabbing" through all active things, because although their
overall keyboard navigation implementation was light years more advanced
than anyone else, when there is a convention as strong as the tab key it is
unhelpful not to follow it)

cheers

Chaals

>>> see
>>> http://www.paciellogroup.com/blog/2011/04/html5-accessibility-chops-
>>> just-use-a-button/
>>> for more details.
>>>
>>> regards
>>> Steve
>>>
>>>
>>>  On 9 July 2012 11:47, Chaals McCathieNevile <w3b@chaals.com> wrote:
>>>
>>>
>>>>
>>>>   On Sun, 08 Jul 2012 22:29:30 +0200, Ramón Corominas 
>>>> <listas@ramoncorominas.com> wrote:
>>>>
>>>>
>>>>
>>>>> Hi all, and apologies for cross-posting.
>>>>>
>>>>> Last     Saturday I gave a presentation in the SpainJS event about 
>>>>> creating     accessible apps using WAI-ARIA. The idea was to show JS 
>>>>> developers that     accessibility is an essential component to 
>>>>> achieve quality coding, and the     potential of ARIA to create more 
>>>>> accessible apps.
>>>>>
>>>>> I've uploaded the     slides here:
>>>>> http://ramoncorominas.com/spainjs/
>>>>
>>>> Nice   :)
>>>>
>>>>> Comments, suggestions or corrections are welcome     (smile)
>>>>
>>>> I think pretty much all browsers allow   activating click events with 
>>>> the keyboard, and will add things if you give   them a tabindex. So 
>>>> adding specific keyboard handling is probably redundant   if you're 
>>>> just using click (mouseover, focus, and various other things are 
>>>> still not so good).
>>>>
>>>> I'd be interested in learning if that is not the   case...
>>>>
>>>> cheers
>>>>
>>>> Chaals
>>>>
>>>> --Chaals - standards   declaimer
>>>>
>>>
>>>
>>>
>>> -- with regards
>>>
>>> Steve Faulkner
>>> Technical Director - TPG
>>>
>>> www.paciellogroup.com | www.HTML5accessibility.com | 
>>> www.twitter.com/stevefaulkner
>>> HTML5: Techniques for providing useful text alternatives - 
>>> dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - 
>>> www.paciellogroup.com/resources/wat-ie-about.html
>>>
>>
>
>



--
Chaals - standards declaimer

Received on Monday, 9 July 2012 22:01:47 UTC