- From: Simon Harper <simon.harper@manchester.ac.uk>
- Date: Wed, 5 Aug 2009 15:28:40 +0100
- To: Charles McCathieNevile <chaals@opera.com>, wai-xtech@w3.org
- Cc: "Henny Swan" <hennys@opera.com>, "WAI-UA list" <w3c-wai-ua@w3.org>
Hi there and thanks for the responses. So as requested here's a post to xtech as well as the original uawg list and a quick list of previous posts for continuity. http://lists.w3.org/Archives/Public/w3c-wai-ua/2009JulSep/0033.html http://lists.w3.org/Archives/Public/w3c-wai-ua/2009JulSep/0032.html http://lists.w3.org/Archives/Public/w3c-wai-ua/2009JulSep/0031.html http://lists.w3.org/Archives/Public/w3c-wai-ua/2009JulSep/0030.html http://lists.w3.org/Archives/Public/w3c-wai-ua/2009JulSep/0028.html http://lists.w3.org/Archives/Public/w3c-wai-ua/2009JulSep/0026.html http://lists.w3.org/Archives/Public/w3c-wai-ua/2009JulSep/0025.html So looking at this further, I see that in 7.6 list-item 2 of the HTML5 spec on accesskeys, that only a single key is allowed as opposed to multiple sequential keys, however, when you add this to the concept of the context menu in 4.11.5.3 it seems that the general model of interaction, and importantly exploration of the interface, becomes broken as a single keystroke without a modifier key cannot be allocated. While this follows on the mac OS, the intuitive sequential keystrokes of Windows and Linux will break. In this case what about a caveat that if the context menu is in focus then a single keystroke without a modifier key is sufficient? I don't want to keep going back to the opcodes but why cannot a browser key sequence (toggle) switch focus between directing keypresses to the desktop/app or the Web? In this way all current key combinations (that would normally be enacted by the application event handlers) could be over-ridden in the Web context of the Web toggle were enabled? Cheers Si. ======================= Simon Harper University of Manchester (UK) Human Centred Web Lab: http://hcw.cs.manchester.ac.uk My Site: http://hcw.cs.manchester.ac.uk/people/harper/ My Diary (Web): http://hcw.cs.manchester.ac.uk/people/harper/ phpicalendar/week.php My Diary (Subscribe): http://hcw.cs.manchester.ac.uk/diaries/harper/ SimonHarper.ics On 1 Aug 2009, at 17:40, Charles McCathieNevile wrote: > On Fri, 31 Jul 2009 15:48:16 +0200, Simon Harper > <simon.harper@manchester.ac.uk> wrote: > >> Hi there, > > First, I would like to continue the discussion in one place if > possible - itis very hard for me to track multiple mailing lists > and see any consistency, so we end up going around the same circles > 10 times instead of making progress. > > If you are subscribed to wai-xtech, please reply to the original > post there... > >> thanks for the clarification - one thing I had in mind was the >> definition of a 'web' modifier key - say function lock, which >> modifies the OS keyboard scan codes, in this way I would expect >> the OS/Browser to understand which keystokes are intended for >> which platform. I don't think this will be solved my just web tech >> - but I do think that the likes of Google will be expecting to >> create a clean and holistic experience for their chrome os and the >> web apps that sit with it; likewise (maybe) for Apple Web Apps. >> Once we think of a webapp as just software we can see that the >> keyboard, and assignments of key combinations, are really >> internationalisation issues and we can allow local assignments >> based on language setting and semantics of the key_action assigned >> - however encouraging web designers to have free range with ad-hoc >> key combination (accesskeys+js) assignments is a mistake in my >> opinion. Having a well defined way of doing this would be better. > > Opera has been using the web as a software platform for a long time > now - this proposal comes in large part from that experience. > > Accesskey, unlike pure javascript, doesn't leave things in the > hands of the page author. The accesskey attribute does two things. > > First, it identifies a particular control (link, form control, > something activated by javascript) as important enough to have a > direct access method. > > Second, it provides a *suggestion* for how that direct access > method might be memorable to the user. > > (Contrast this to tabindex, which only identifies something as > active and therefore something the user must be able to get to and > activate, even if it's a list item or other not normally active > element). > > In any intelligent implementation, the user agent and the user both > have the ability to change the activation method. An important > consequence of this is that the author shouldn't try to explain the > activation method - that's the user agent's job, and acceskey > implementation should be consistent across a given user agent for > all pages, rather than being dependent on the particular web-page. > This is critical to allow it to work on a variety of devices. > > The use of plain javascript instead is common today in order to > make things look like nice applications. This is a problem in > trying to port stuff written for a single system, rather than the > web, to different browsers and platforms. The challenge is to work > out how to make it easy to have a nice interface, while not > interfering with what the user expects the browser to do (the big > problem with most old-fashioned accesskey implementations). > >> Heck can HTML5 just not include an 'action' attribute with a >> defined set of opcodes to facilitate localisable control. I agree >> about the number you could have but touch gestures, haptic >> gestures, and key modifier codes could be included - it will take >> time for HTML5's uptake. > > There is a "command" concept in HTML that does something like this > already. But no, it is not going to be feasible to include a > sufficient number of opcodes as activation handles (those that can > be listed sensibly should be aria-roles or rel values, actually). > > So the accesskey attribute, which allows the author to suggest a > key, is what you are asking for. In HTML 5 it has a few benefits > over the HTML 4 version - first, the terribly bad advice about > implementation has been removed, second, it defines a DOM attribute > so script can find out what actually does activate the control in > question. > >> Cheers >> Si >> >> On 31 Jul 2009, at 16:13, Charles McCathieNevile wrote: >> >>> On Fri, 31 Jul 2009 14:54:59 +0200, Simon Harper >>> <simon.harper@manchester.ac.uk> 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: http://hcw.cs.manchester.ac.uk >>>> >>>> My Site: http://hcw.cs.manchester.ac.uk/people/harper/ >>>> >>>> My Diary (Web): http://hcw.cs.manchester.ac.uk/people/harper/ >>>> phpicalendar/week.php >>>> My Diary (Subscribe): http://hcw.cs.manchester.ac.uk/diaries/ >>>> harper/SimonHarper.ics >>>> >>>> >>>> >>>> >>>> >>>> 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: 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> --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 >>> >> > > > -- > 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, 5 August 2009 16:12:12 UTC