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

Re: Which is it? - widget keynav

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Tue, 26 Feb 2008 11:57:21 -0500
Message-Id: <ED69B4F5-E0D0-4FB6-8406-B868AEE7975A@IEEE.org>
To: wai-xtech@w3.org

On 26 Feb 2008, at 9:25 AM, Evans, Donald wrote:

> 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.

My current understanding is that where the OS conventions for keys
to operate something are the same, that we should have the ARIA keys
follow that desktop precedent.

The motivation for this is that the desktop look and feel development
is more mature than the WebTop equivalent.  The web exploded
on just point and click, but the need for richer action options
has re-surfaced as the web takes on bigger and bigger jobs.
Designers writing widget scripts seem to be trying to emulate
the desktop look and feel; we don't need to fight them to make
that look and feel accessible in the web applications.

Where there is no stable and cross-platform usage for some function
we need to complete access, I was hoping that then this group would
undertake the role of inventor for something that ought to blend in
well with the established keystroke conventions.

I would prefer that where the operating systems differ, this group
does a case-by-case choice among the precedents.  Although the
bulk of the decisions may emulate MS Windows, I would prefer than
you not make that a blanket decision up front.


> -----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 16:57:44 UTC

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