RE: Which is it? - widget keynav

It's a sticky wicket!  We have tried to follow a policy that says if
there is a well known convention already in place, we should follow it
unless there is a very good reason why we should modify it.

As an example, many people already understand how to operate a treeview
from the MS OS.  Therefore it makes sense to mimic that keyboard
behavior in the same type of widget on the web.



-----Original Message-----
From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
Behalf Of Earl Johnson
Sent: Wednesday, February 13, 2008 4:39 PM
To: wai-xtech@w3.org
Subject: Which is it? - widget keynav


Hi All;

I'm [possibly] gonna open a can of worms here so appologies in advance.

I've heard some voices saying the keynav best practices should consider,
respect, and not overide how browsers and screen readers [particular]
currently interact with each other.

One "camp" [camp 1] says don't disturb what's already been establised in
the browser and screen reader. A second "camp" 
[camp 2] basically says follow what the platform's UI toolkit provides
[my proposals always fall in here].

I need to know how we're defining the keynav sequences so I minimize
wasting your or my time [this discussion should be short if the decision
has already been made]. Here is how things appear to me now:
	- camp 1:
		= do not disturb how the browser and screen reader
currently interact with each other.
	- camp 2:
		= define keynav based on how the underlying platform
processes the key sequences.

So my questions to all of you are:
1. A can of worms means one camp "wins" while the other "loses", which
means someone needs to say "We use camp X.", which means someone needs
to be the final arbiter ["chooser"].
	- So, who is on the hook for making the final call?

2. Binary solutions, Camp 1 or Camp 2, always leave someone, or some
camp, unhappy:
	- Has a win-win, or some type of amenable solution been
identified here that we should follow that I don't know of yet?

The [possible] Can Opener: [aka Earl, Sun Microsystems].

Received on Tuesday, 26 February 2008 14:28:22 UTC