- From: Evans, Donald <donald.evans@corp.aol.com>
- Date: Thu, 20 Nov 2008 09:01:41 -0500
- To: "Schnabel, Stefan" <stefan.schnabel@sap.com>, "Victor Tsaran" <vtsaran@yahoo-inc.com>, "James Craig" <jcraig@apple.com>, "Chris Blouch" <cblouch@aol.com>
- Cc: "David Bolter" <david.bolter@utoronto.ca>, "Joseph Scheuhammer" <clown@utoronto.ca>, <wai-xtech@w3.org>, "earl johnson" <earlj.biker@gmail.com>, "Wlodkowski, Thomas" <thomas.wlodkowski@corp.aol.com>
Well said! > -----Original Message----- > From: wai-xtech-request@w3.org > [mailto:wai-xtech-request@w3.org] On Behalf Of Schnabel, Stefan > Sent: Thursday, November 20, 2008 2:52 AM > To: Victor Tsaran; James Craig; Chris Blouch > Cc: David Bolter; Joseph Scheuhammer; wai-xtech@w3.org; earl johnson > Subject: RE: [DHTML Style Guide] Tablist: why alt+del? > > > Any attempts to "make-it-as-simple-as-possible" are justified > and welcome as long as the overall harmonization idea is not > forgotten. > Also, the individual platforms and OS (PC, Mac etc.) have > evolved differently and Mac users may simply expect different > keystrokes sometimes on a web page to use elements they know > from their OS .. > > As far as I have understood, ARIA is NOT about keyboard > navigation. Its anticipations are that support for it is > simply *there* built into the UA's for known roles. ARIA just > needs that like a ship the water. > > As ARIA is a Band Aid for HTML5 with respect to roles, the > AOL style guide is a glass bridge with respect to navigation > for us JavaScript coders until this support is available in > the UA's, and nobody knows when it will be the case. > > I believe when there is no consensus about common keyboard > navigation AT will (and have to) find ways to support KB > navigation for ARIA in the Rambo way and this is worse > because there will be diversification which is a good thing > for a nation but not for Web UI Elements. > > Keyboard Usage Standardization for Web UI Elements is > mandatory and I wonder why this attempt has to be done by > some committed people from industry. And yes. I know the > reasons why. But sometimes there is no comfort in the truth. > > - Stefan > > -----Original Message----- > From: wai-xtech-request@w3.org > [mailto:wai-xtech-request@w3.org] On Behalf Of Victor Tsaran > Sent: Mittwoch, 19. November 2008 21:34 > To: James Craig; Chris Blouch > Cc: David Bolter; Joseph Scheuhammer; wai-xtech@w3.org; earl johnson > Subject: RE: [DHTML Style Guide] Tablist: why alt+del? > > > Good points. ARIA will not go forward unless it is practical > and works. > Talk to anyone in the industry who has tried to incorporate > into a mainstream product and you'll know what I mean. > Victor > > -----Original Message----- > From: wai-xtech-request@w3.org > [mailto:wai-xtech-request@w3.org] On Behalf Of James Craig > Sent: Wednesday, November 19, 2008 12:23 PM > To: Chris Blouch > Cc: David Bolter; Joseph Scheuhammer; wai-xtech@w3.org; earl johnson > Subject: Re: [DHTML Style Guide] Tablist: why alt+del? > > > Chris Blouch wrote: > > > I spent quite a bit of time trying to implement keyboard shortcuts > > that didn't interfere with either the OS, browser or AT and after > > doing a lot of testing with XP, Jaws, IE and FF the > available list was > > > very very short. I believe one of the ideas going into the > DHTML style > > > guide was that ARIA would allow an AT to know that the user > had focus > > on a widget and get out of the way. Without that it would be nearly > > impossible to find a set that works cross-AT, cross- browser and > > cross-platform. Do Mac Voiceover users care that control- J jumps > > cells with Jaws on Windows? Do Windows users care that > voiceover users > > > jump between headers using control+alt+h? I suggest that the set of > > available key combinations that are as agnostic as the web sites we > > want to implement them on is nearly null. In light of that, a clean > > slate approach seems appropriate. Given no constraints on > keystrokes > > other than trying to give a nod to what is common (familiar) in > > existing implementations to lower cognitive load, what > would make the > > most sense for navigating and controlling widgets? > > For what it's worth, I completely agree with you. The > argument I've heard against that is that there needs to be a > consistent mechanism for keyboard navigation even if not > controlled by AT like a screen reader. > To that, I replied that the user agent should implement the > key commands. > > For example, I can activate the menus or form controls in > Safari with or without VoiceOver. The same should be true of > all ARIA widgets in that UA and AT control web application > widgets in the exact same way as the desktop equivalents. > Although I firmly believe this is the right approach, not all > browsers currently support DOM mutation events properly, and > that feature is required for this approach to be a practical solution. > > At this point, I've started mostly ignoring the DHTML Style > Guide as an overly-complex, but nice-to-have stop-gap measure > until user agents support all these controls natively. I'm > not saying this to make enemies in the DHTML Style Guide > Working Group, but that will probably happen anyway. I'd be > more on board with the more simple approach Victor > mentioned: very basic navigational controls, including the > keystroke to open a contextual menu that contains all the > more-complex methods of navigation and control. > > James > > > > >
Received on Thursday, 20 November 2008 14:04:02 UTC