Re: [DHTML Style Guide] Tablist: why alt+del?

I think we're saying the same thing. DHTML Style Guide is a start and, 
if anything, highlights the unbounded complexity of having anything 
close to a consistent keyboard interface. It's the Martian headset 
[http://www.joelonsoftware.com/items/2008/03/17.html] problem in that 
the organic process of paving cowpaths and wild west stakes claiming of 
key-object-action bindings was not forward thinking enough to support 
controlling/navigating new web interfaces. We're now in a corner where 
the only way to give appropriate keyboard controls to widgets is to take 
them away from other parts of the UI (browser, AT or OS) leaving messy 
compromises and inconsistencies. It gets even more complex when we start 
taking about meta navigation of widgets within widgets or objects within 
objects. I think Apple got one thing right with their idea of 
approaching a UI as layers so I can move from general to specific and 
not have to wade through every detail linerally. Plenty of work ahead.

CB

James Craig wrote:
> 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 Wednesday, 19 November 2008 22:03:04 UTC