W3C home > Mailing lists > Public > wai-xtech@w3.org > July 2009

RE: Keyboard support and ARIA

From: Schnabel, Stefan <stefan.schnabel@sap.com>
Date: Fri, 17 Jul 2009 09:59:32 +0200
Message-ID: <E34714E1E6587741AD32C8E445B6F4AB01996D92@dewdfe1o.wdf.sap.corp>
To: "Charles McCathieNevile" <chaals@opera.com>, <wai-xtech@w3.org>
Cc: "Keim, Oliver" <oliver.keim@sap.com>

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

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

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. 

(The command element may or may not help here, do you govern its implementation in UA's ? Do you already know what the actual outcome will be if 10 different browsers start to implement?)

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

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.

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.

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  

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.



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 Friday, 17 July 2009 08:00:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:41 UTC