W3C home > Mailing lists > Public > wai-xtech@w3.org > February 2008

Which is it? - widget keynav

From: Earl Johnson <Earl.Johnson@Sun.COM>
Date: Wed, 13 Feb 2008 13:38:56 -0800
To: wai-xtech@w3.org
Message-id: <47B36370.1050608@sun.com>

Hi All;

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

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 Wednesday, 13 February 2008 21:43:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:25:18 UTC