W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2009

Fwd: Keyboard support and ARIA

From: Henny Swan <hennys@opera.com>
Date: Fri, 31 Jul 2009 12:19:02 +0100
Message-Id: <86EBA57B-465F-46D8-A5BB-B26B200B045E@opera.com>
To: WAI-UA list <w3c-wai-ua@w3.org>
Folks,

Here's a copy of Chaal's mail to WAI-xtech concerning keyboard support  
and ARIA.

Cheers, Henny

Begin forwarded message:

> Resent-From: wai-xtech@w3.org
> From: "Charles McCathieNevile" <chaals@opera.com>
> Date: 16 July 2009 16:37:01 BST
> To: "wai-xtech@w3.org" <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




-- 
Henny Swan
Web Evangelist
Member of W3C Web Accessibility Initiative Education and Outreach Group
www.opera.com/developer

Personal blog: www.iheni.com

Stay up to date with the Web Standards Curriculum www.opera.com/wsc
Received on Friday, 31 July 2009 11:20:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:52:15 GMT