W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2006

Re: More data on accesskeys (New article written Nov. 1)

From: Joshue O Connor <joshue.oconnor@ncbi.ie>
Date: Fri, 03 Nov 2006 15:14:52 +0000
Message-ID: <454B5CEC.9060900@ncbi.ie>
To: foliot@wats.ca
Cc: 'Alastair Campbell' <ac@nomensa.com>, 'Andy Mabbett' <andy_mabbett@birmingham.gov.uk>, w3c-wai-ig@w3.org, 'WebAIM Discussion List' <webaim-forum@list.webaim.org>

John Foliot - WATS.ca wrote:

>  I would only add that my little list is hardly "definitive", although
>> the research is/was solid at it's initial printing (2003). 

Hi John,

It pretty comprehensive. Its a clear guide to where there could be
problems with accesskeys.

Thanks

Josh


> Alastair Campbell wrote:
>> Josh wrote:
>>> At the risk of upsetting a hornets nest here, can you please point to
>>> any resources which indicate exactly what UA key combinations are
>>> mostly effected by user defined access keys?
>> There's a list of browser, OS & access technology keys here:
>> http://www.wats.ca/show.php?contentid=43 
> 
> Thanks Alastair (time differences being what they are).  
> 
> Josh, I would only add that my little list is hardly "definitive", although
> the research is/was solid at it's initial printing (2003).  I try to keep it
> up-to-date, but (for example) the keystrokes for JAWS are based on JAWS 5
> (and we've come some way since then).
> 
> None-the-less, it is (if nothing else) a cautionary list which hopefully
> illustrates the foibles of author declared accelerator keys - one thing I
> have not tracked for that list is the numerous Firefox extensions that have
> started to implement an (ALT+__) style "hotkey" for their particular
> function - which introduces a whole new layer of confusion.
> 
> 
> 
> 
> Andy Mabbett wrote:
>>> True, and several links were provided earlier in the thread to
>>> implementations,
>> Sorry; I seem to have missed those.
>>
> 
>  - http://juicystudio.com/article/user-defined-accesskeys.php
>  - http://juicystudio.com/article/user-defined-access-keys-aspversion.php
> 
> There are others...
> 
>> Again,  my proposal is precisely the opposite. The user would
>> configure their UA, once, regardless of which sites they subsequently
>> visit. 
> 
> This is pretty much how and what the ACCESS element and @role attribute are
> envisioned to do.  
> 
> Jon Gunderson, (University of Illinois at Urbana-Champaign) has set up some
> test cases that require the iCATA Accessibility Toolbar extension for
> Mozilla/Firefox to demonstrate (proof of concept)
>  - http://www.cita.uiuc.edu/software/mozilla/
>  - http://firefox.cita.uiuc.edu/test/ts-test-page-role.php
> 
> 
>> That is what I'm proposing!
>>
> 
> Not to flog a dead horse, but may I also point you to:
> Access + Key Still Equals Accesskey -
> http://www.wats.ca/show.php?contentid=47
> 
> ...where I detail my concerns on *how* the W3C are proposing this (the
> inclusion of the @key attribute)
> 
> The proposed solution (which still has not made it to the draft spec) for
> conflict resolution would go something along the lines of:
> 
> 	User-defined key mappings take precedence over all
> 	User Agent mappings (including AT tools) follow
> 	Author suggested mappings if none specified (although this still
> does not address discoverability)
> 
> JF
> --
> John Foliot  foliot@wats.ca
> Web Accessibility Specialist
> WATS.ca - Web Accessibility Testing and Services
> http://www.wats.ca    
> 
> 
> 
> 


********************************************************************

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.

NCBI 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 the views of NCBI


********************************************************************
Received on Friday, 3 November 2006 15:15:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:31 UTC