Re: Keyboard support and ARIA

On Fri, 31 Jul 2009 14:54:59 +0200, Simon Harper  
<> wrote:

> Thanks for that Henny,
> One think comes to mind, could we not mark up elements that can enact  
> programmatic events with explicit 'action' semantics. Such as:

Between the use of ARIA roles, and @rel values, we have a fair amount of  
information about common patterns already. It is not feasible to provide  
default keyboard shortcuts for a huge set of things - when you have a  
keyboard like Opera mini usually encounters, even using key combos you  
have 30 things you can assign, and most of those are given to the UI or  
common links already. (Actually iPhone's gestures, and mouse gestures in  
Opera, have a similar role in life and similar limitations in numbers).

But where there are common ways to describe common semantics, making  
things that are an explicitly keybaord-controllable function is better  
than just listening for various javascript events. And using things like  
tabindex and accesskey (which although they are still sub-optimal in  
implementation are no more broken than mysterious key-trapping in  
javascript) is a step forward too.

> <ul>
>  <li><a id="ks_file">File</a><li>
>  <ul>
>   <li><a id="ks_tab">New Tab</a><li>
>   <li><a id="ks_file">Open File</a><li>
>   <li><a id="ks_location">Open Location</a><li>
>  </ul>
>  <li><a id="ks_edit">Edit</a><li>
>  <li><a id="ks_help">Help</a><li>
> </ul>
> Then allow the browser (maybe even OS specific) to assign standard key  
> shortcuts. In this way you get mouse-less browsing but with constancy  
> across applications and operating systems, and you don't have to be  
> prescriptive wrt browser manufacturers.

There are a few things in basic HTML 4 that enable this. You won't get  
complete consistency - what I can do on a touch screen phone with 4  
buttons isn't the same as what I can do on a standard keyboard, and that  
is different from what i can do on a Russian keyboard. But a web  
application should be capable of adapting to all of these - and that means  
either a huge enomous and almost definitely hopelessly incomplete  
author-specified set of shortcuts, or a mechanism that allows the browser  
to assign the shortcut, with a default suggested by the author in the hope  
that it might be available.

> Not sure if this helps any but I think we really need to look into this.

Agreed. Cheers

> Cheers
> Si.
> =======================
> Simon Harper
> University of Manchester (UK)
> Human Centred Web Lab:
> My Site:
> My Diary (Web):  
> My Diary (Subscribe):  
> On 31 Jul 2009, at 12:19, Henny Swan wrote:
>> Folks,
>> Here's a copy of Chaal's mail to WAI-xtech concerning keyboard support  
>> and ARIA.
>> Cheers, Henny
>> Begin forwarded message:
>>> Resent-From:
>>> From: "Charles McCathieNevile" <>
>>> Date: 16 July 2009 16:37:01 BST
>>> To: "" <>
>>> 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
>>>       Try Opera:
>> --Henny Swan
>> Web Evangelist
>> Member of W3C Web Accessibility Initiative Education and Outreach Group
>> Personal blog:
>> Stay up to date with the Web Standards Curriculum

Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk       Try Opera:

Received on Friday, 31 July 2009 13:14:06 UTC