Re: Keyboard support and ARIA

On Fri, 17 Jul 2009 13:59:32 +0600, Schnabel, Stefan  
<stefan.schnabel@sap.com> wrote:

> I expect full HTML5 spec not before Christmas 2015 (well, maybe a bit  
> earlier).

I hope for one earlier, but it is hard to say :S

> JS has been always necessary for richness and for workarounds. You know  
> that.

Yes. But it has also been an invitation to do things that are not  
necessary, and get in the way of things that are.

> The current JS-based KB handlers are just the consequence of the fact  
> that rich client behavior is expected on the web when widgets come in
> place that *do* look like their rich client counterparts.
>
> For instance, take a menu popup. Everybody expects that arrowing down  
> will select a different item (you DO perform list navigation by  
> arrowing).
>
> Thinking "we can use "TAB" for that for we are in the web and one day  
> the browser will take care of that led to "menu" implementations that
> are BAD in terms of usability. Really.

Agreed.

> (The command element may or may not help here, do you govern its  
> implementation in UA's ?

No, except perhaps Opera's.

> Do you already know what the actual outcome will be if 10 different  
> browsers start to implement?)

Naturally, they will carefully follow the spec, discover it is perfect,  
and there will be world peace and harmony.

> The users expect good and consistent keyboard behavior within their UI's  
> NOW and not in a dreamy future.

Quite true, and this brings about the challenge. At the same time, we have  
built systems up until now that get in the way of designing a decent  
future... and don't work in the multi-device present (as was predicted in  
the pre-multi-device past).

> For me everything, really everything is related to the fact that HTML5  
> is not yet there having well defined widgets browsers can start to  
> support with built-in kb navigation, as they actually do for the humble  
> <select> statement.

Sure. But there are some widgets that are well-defined.

> Convince me Charles, go to the HTML5 guys and do care for a MASSIVE spec  
> speedup covering ALL of the contemporary widgets (not just a subset  
> because then the other widgets will still require JavaScript).
>
> Then, be a one man show and go to ALL other browser vendors and cause
> them doing   the needful. And yes, this IS a management job. Boring?
> I don't know.

Yeah, it is management and it is boring. I do know because I have done a  
lot of it.

How about I take a more reasonable approach, of working at this gradually,  
identifying the pieces of the puzzle and what applications really need and  
what they are using because they just found it the quickest easiest thing  
that worked for the first requirements?

Although doing it in a group where others were also thinking about how to  
identify and tackle the problems would be good.

cheers

Chaals

> I know that Opera did a great job regarding keyboard support and  
> navigation within documents, but you fight with hands tied unless the  
> situation has changed.
>
> - Stefan
>
>
> -----Original Message-----
> From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On  
> Behalf Of Charles McCathieNevile
> Sent: Donnerstag, 16. Juli 2009 17:37
> To: wai-xtech@w3.org
> Subject: Keyboard support and ARIA
>
> Hi folks,
>
> I have had a concern for a while (I recall raising it several times over
> the last few years, but have been focussed on other things and not
> followed so clearly) about the use of pure Javascript to deal with
> keyboard accessibility.
>
> The major issue is the nature of keyboard interaction in Javascript. Put
> briefly, it's a horrible mess with no concept of device independence. So
> on the face of it, the idea that it would be a good base for building
> accessibility seems like an odd notion.
>
> Digging into the details we find that several attempts to specify this in
> a way considered workable have ended with clever people throwing up their
> hands and saying "we could document some more of the current mess, but it
> isn't actually anything you would want people to use" (or things to that
> effect). Changing keyboard layouts, browsers, devices, alphabets,  
> language
> - almost anything causes this to go from a nasty mess to a plain old
> failure.
>
> By comparison, the use of tabindex and real links or buttons, as per
> old-fashioned HTML, seems to allow for a much more flexible interaction
> model. HTML 5's command element, it's improved specification of  
> accesskey,
> and the growing understanding that this stuff should be left to user
> agents and users rather than page authors, offers the promise of being
> able to make keyboard interaction actually work properly in more than one
> language or device without having to develop massive collections of
> alternatives with 5-variant testing to choose the right one.
>
> The migration path, as always, is actually messy. Currently accesskey
> implementations range from not very good (e.g. Opera on desktop which has
> some bugs and limitations, or really basic phone browsers that only allow
> numbers) to the awful (e.g. things that let pages override normal user
> agent interface), with a good dose of the non-existent. Meanwhile,
> interrupting everything with javascript means that the issue of where the
> priority should go is also raised.
>
> I don't think these are insoluble problems, but I do see a lot of work
> moving in a direction that looks like a very ugly ad very limiting
> dead-end, that could actually significantly reduce the practical value of
> ARIA far below its potential.
>
> Cheers
>
> Chaals
>


-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Wednesday, 2 September 2009 16:56:02 UTC