Re: [DHTML Style Guide] Tablist: Revision of Tab proposal

Hi Stefan and all,

With Mac os and VoiceOver, we don't have this issue because in order to use 
special keys, we have to envoke them.  I learned quickly after 15 years of 
using JAWS that this is a much better fit to reality.  It is not perfect but 
its design allows for the browser and the site developer to provide for 
maximum usability where key action is concerned.  So yes, in addition to 
many folk not knowing that there is a pass through key or how to use it, 
this is a usability issue.  In recent versions of JAWS, it is possible to 
turn off "quick key navigation" if you know how and also to turn off the 
"virtual viewer" but the optimal solution would be for the AT to not 
interfere in the first place.

----- Original Message ----- 
From: "Schnabel, Stefan" <stefan.schnabel@sap.com>
To: "David Poehlman" <david.poehlman@handsontechnologeyes.com>; "Cain, 
Sally" <sally.cain@rnib.org.uk>; "David Bolter" <david.bolter@utoronto.ca>; 
"James Nurthen" <james.nurthen@oracle.com>
Cc: "Joseph Scheuhammer" <clown@utoronto.ca>; <wai-xtech@w3.org>; "earl 
johnson" <earlj.biker@gmail.com>
Sent: Wednesday, November 12, 2008 3:15 AM
Subject: RE: [DHTML Style Guide] Tablist: Revision of Tab proposal


David,

Advanced Jaws users will have always advantages. It's a geek world. Sad
but true. A different point is usability. I personally would hate to
press every time a special key combo to cause my AT to ignore its own
keys for a moment...

Can anybody tell me why W3C hat not already defined as a prerequisite
for web apps a bottom-up scenario for external content where the content
of a (signed/trusted) business app in an UA overrides ANY UA/OS keys?

That's the real problem, currently we have a top-down scenario where the
lowest layer always is the OS and
will always win.

The first step in this direction would be a reliable keyboard hook for
browser content for any hotkeys and shortcuts along with a *strong*
directive by W3C what navigational keys/modifier keys/hotkeys/shortcuts
to be used in web apps along with the mandatory requirement to provide
an option as part of UI to make them user-configurable.

I don't understand why W3C is so agnostic here and leave this job to
others. Really. Industry suffers from that.

- Stefan



-----Original Message-----
From: David Poehlman [mailto:david.poehlman@handsontechnologeyes.com]
Sent: Dienstag, 11. November 2008 14:57
To: Schnabel, Stefan; Cain, Sally; David Bolter; James Nurthen
Cc: Joseph Scheuhammer; wai-xtech@w3.org; earl johnson
Subject: Re: [DHTML Style Guide] Tablist: Revision of Tab proposal

two comments.  there is a player #4 and that is the os.

As for what you can do with the AT, many will not use what is considered
an
advanced function of key pass through.

----- Original Message ----- 
From: "Schnabel, Stefan" <stefan.schnabel@sap.com>
To: "Cain, Sally" <sally.cain@rnib.org.uk>; "David Bolter"
<david.bolter@utoronto.ca>; "James Nurthen" <james.nurthen@oracle.com>
Cc: "Joseph Scheuhammer" <clown@utoronto.ca>; <wai-xtech@w3.org>; "earl
johnson" <earlj.biker@gmail.com>
Sent: Tuesday, November 11, 2008 3:20 AM
Subject: RE: [DHTML Style Guide] Tablist: Revision of Tab proposal



Sally,

that's exactly what our CRM Web Client allows for Shortcuts and Access
Keys.

But don't forget the User Agents. Their Shortcuts and Access Keys should
be configurable, too.

As I see it, there are 3 different players

1) Application
2) User Agent (functional + navigational keys)
3) Assistive Tech

Chances are that 2) and 3) talk with each other to avoid collisions. But
there may be always some of them.
As a matter of last resort, Jaws for instance offers means to ignore its
own keys for the next key stroke (Ins+Numpad 3 to be pressed before any
application hotkey).

- Stefan

-----Original Message-----
From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
Behalf Of Cain, Sally
Sent: Montag, 10. November 2008 21:34
To: David Bolter; James Nurthen
Cc: Joseph Scheuhammer; wai-xtech@w3.org; earl johnson
Subject: RE: [DHTML Style Guide] Tablist: Revision of Tab proposal


Dear all,

Just a general comment on this thread. I agree with simplification of
keyboard shortcuts, but there is a balance to be found here and it is
*not* easy.
We need to provide navigation that is accessible, predictable and simple
without clashing with access technology.

In a desktop application environment I recommend to developers that you
provide all of the above and if there are then clashes with access
technology then the *application* should provide the functionality to be
flexible enough to change the keyboard shortcuts. In a web application
you do not have that same flexibility and the last thing we want is a
user to be constantly changing the keyboard shortcuts in their own
access technology as they just won't use the web application.

Thanks
Sally

Sally Cain
Digital Accessibility Development Officer
Digital Accessibility
RNIB Birmingham
Tel: 0121 665 4226
Email: sally.cain@rnib.org.uk



-- 
DISCLAIMER:

NOTICE: The information contained in this email and any attachments is
confidential and may be privileged.  If you are not the intended
recipient you should not use, disclose, distribute or copy any of the
content of it or of any attachment; you are requested to notify the
sender immediately of your receipt of the email and then to delete it
and any attachments from your system.

RNIB endeavours to ensure that emails and any attachments generated by
its staff are free from viruses or other contaminants.  However, it
cannot accept any responsibility for any  such which are transmitted.
We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email and
any attachments are those of the author and do not necessarily represent
those of RNIB.

RNIB Registered Charity Number: 226227

Website: http://www.rnib.org.uk



This message has been scanned for viruses by BlackSpider MailControl -
www.blackspider.com

Received on Wednesday, 12 November 2008 12:59:26 UTC