- From: Jon Gunderson <jongund@illinois.edu>
- Date: Wed, 5 Aug 2009 08:53:15 -0500 (CDT)
- To: kim@redstartsystems.com, "WAI-UA list" <w3c-wai-ua@w3.org>
Being able to configure keyboard focus styling would be an important feature for browsers to provide. It should be considered a user stle sheet and override author settings. Jon ---- Original message ---- >Date: Tue, 04 Aug 2009 18:00:29 -0400 >From: Kim Patch <kim@redstartsystems.com> >Subject: Re: Keyboard support and ARIA >To: WAI-UA list <w3c-wai-ua@w3.org> > > Greetings. > > Some relatively simple thoughts. > > I think with Web apps (as with desktop apps) there are four things that are very important > -- if we can give the user these, everything else follows: > > 1. Predictable focus > 2. Predictable timing > 3. Input configurability (keyboard shortcuts) > 4. The ability to easily toggle and share input configurations > > The longer version: > > Users who don't use the mouse are much more aware of how often the computer seemingly > randomly rips the focus away from what you're doing. (When you're using a mouse you often > put the focus back without realizing it. When you're using speech you sometimes don't > notice the focus has changed, and then say a command and are surprised by the result. Even > if you do notice the focus has changed, it's annoying to have to interrupt what you're > doing to move the focus back.) > How can we give users an option to more closely control the focus? > > Speech input is most powerful when you can speak in command phrases (if there's no need to > think between commands there's no need to have separate commands other than to accommodate > the input process). Speech engines also use a lot of resources. From the user's point of > view, speech slows down sometimes, and occasionally a longer command hangs, or the focus > changes mid-command. This is a common enough experience that jargon has popped up around > it -- "Dragon's out to lunch". > How can we give users an option to more closely control application attention? > > It's obvious that key configurability is important, and that different users have > different needs. The ability to configure in patterns also makes things much easier. For > instance, single-letter shortcuts are great for some users, and in some situations for > speech users, but in other situations, it's a lot better if you have the ability to put > combination keys in front of all those shortcuts, because simply by speaking any words you > can say lots of letters at once. > > The ability that makes configurability an order of magnitude more powerful is sharing > configurations. Users with very different needs can spend a lot of time configuring but if > they can share their work with other users the average time configuring can go way down. > This brings along many more people, and also brings good configurations to light. > > Thinking about this, and also thinking that good defaults make configuring easier, and > looking at what Simon has written below, what I'd like is a good mechanism for people to > choose a default, user-supplied override or even Web designer override. As a user I'd like > to start with a good set of defaults, change a few things globally that are better for me > as a speech user, then be able to easily discover (or ignore) if a Web page has a special > way of doing something, and be able to easily toggle that and my defaults in those very > few cases where the special way makes sense given the way I use the computer. And then I'd > like to be able to share all of it in a way where my changes are easily discoverable. > > One other thought. If a keyboard shortcut can be a string of keys, not just keys pressed > at once, there are many more combinations. The key here, of course, is that the full > string can be passed without timing issues. > > Cheers, > Kim > > Simon Harper wrote: > > Hi 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. 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. > > 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 franc,ais -- hablo espanol -- jeg laerer 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 franc,ais -- hablo espanol -- jeg laerer norsk > http://my.opera.com/chaals Try Opera: http://www.opera.com > > --------------------------------------------------------------------------------- > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.392 / Virus Database: 270.13.42/2279 - Release Date: 08/03/09 05:57:00 > > > > -- > ___________________________________________________ > > Kimberly Patch > President > Redstart Systems, Inc., makers of Utter Command > (617) 325-3966 > kim@redstartsystems.com > > www.redstartsystems.com > - making speech fly > > Patch on Speech blog > Redstart Systems on Twitter > ___________________________________________________ Jon Gunderson, Ph.D. Coordinator Information Technology Accessibility Disability Resources and Educational Services Rehabilitation Education Center Room 86 1207 S. Oak Street Champaign, Illinois 61820 Voice: (217) 244-5870 WWW: http://www.cita.uiuc.edu/ WWW: https://netfiles.uiuc.edu/jongund/www/ --------------------------------------------------------------- Privacy Information --------------------------------------------------------------- This email (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. It is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this email is not the intended recipient, or agent responsible for delivering or copying of this communication, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please reply to the sender that you have received the message in error, then delete it. Thank you.
Received on Wednesday, 5 August 2009 13:53:52 UTC