- From: Earl Johnson <Earl.Johnson@Sun.COM>
- Date: Wed, 13 Feb 2008 13:38:56 -0800
- To: wai-xtech@w3.org
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 Wednesday, 13 February 2008 21:43:47 UTC