RE: Accesskey Discussion

Hi Greg,
 
It's the Internet Explorer use of the ALT key that seems to cause most
problems for keyboard only users.  Not alone obviously, but when web
pages use the same letters as the browser toolbar trigger letters
(F,E,V,A,T,H (and D for taking the focus to the address bar)), the page
bindings have precedence, and for instance, ALT A would take the user
from their current position on the page to focus on an accesskey bound
"Accessibility" link, whereas the user really wanted to add the page to
Favourites.   For people with mobility difficulties, this is obviously
both confusing and frustrating, not only are they prevented from adding
the page to favourites, but have been taken away from their position on
a page, necessitating repeated navigation. 

We've tried for years to get web authors to avoid using letters (on the
grounds that other browsers may well use other letters with the ALT
modifier), but have had little success, and frequently found that sites
with A to Z listings will bind every letter in the alphabet.  Our
recommendation has always been to either use only numeric bindings or
preferably to provide a facility where the user can define their own
accesskeys.  They can then choose letters or numbers that they know
aren't required for other purposes. This has the added benefit that the
users with dyslexia or cognitive difficulties could define the same key
shortcut for similar links (i.e. Home, Search, Contact us, Login),   to
every site they visit that uses a self determined accesskey system,
cutting down on the cognitive overload of different keys for different
features on every site. 

I got involved in this discussion when the suggestion was made that HTML
5 should have pre-determined bindings, which sounds as though it might
be another way to help avoid the cognitive overload, but my concern
remains that the conflict with browser toolbar controls may not be
avoided, but cascaded across every site that uses this part of the
specification  unless great care and research is taken before
determining which letters/numbers to bind.

For the browsers that use other modifiers, the problem is different,
this is where the access tech users find themselves inadvertently
toggling access tech software controls on or off.  In one such
accidental instance, I turned off my screen reader speech. Unfortunately
I was just testing a few things at the time, not aiming for anything
deliberately, so I couldn't remember which keys I'd used  and had to
reboot the computer to recover.  
 
All the best,

Bim.




________________________________

From: Greg Lowney [mailto:gcl-0039@access-research.org] 
Sent: 25 September 2010 02:24
To: simon.harper@manchester.ac.uk
Cc: Egan, Bim; UAWG list
Subject: Re: Accesskey Discussion


Hi Simon, Bim,

The thing about that is, accesskey was originally put in specifically so
it *would* use the same modifier key as the browser UI. At least as it
was discussed within Microsoft, the goal was to allow HTML authoring of
forms, dialog boxes, and other user interfaces have the platform's "look
and feel" so the user wouldn't have to know or care whether UI was
written using HTML or the native Windows API, VB, etc. Since Windows
menus and dialog box controls used the Alt-key modifier, so did
accesskey.

Of course a browser can use a different modifier key for accesskey (or
its equivalent) than for its built-in UI, but that would make
HTML-authored dialog boxes and forms extremely confusing for users.
Imagine if a dialog box comes up and you have to guess which modifier
key to press to activate its controls, because you don't know whether
it's native or author-defined...

Luckily, the Windows UI (based on IBM's CUA standard) included a
mechanism for handling conflicts: if more than one element in the active
context shared the same underlined access key, pressing that key or key
combination would move the focus to the next element with that access
key, but not automatically activate it, leaving the user to either
navigate away (by repeating the access key or other means) or press a
key to activate the element. Thus, at least in native applications, you
could still do everything in a way that was pretty much optimal given
the conflict, but the UI did change enough that it could confuse users
who weren't used to this convention or to accesskeys suddenly changing
behavior.

    Thanks,
    Greg

-------- Original Message  --------
Subject: Re: Accesskey Discussion
From: Simon Harper <simon.harper@manchester.ac.uk>
<mailto:simon.harper@manchester.ac.uk> 
To: Egan, Bim <Bim.Egan@rnib.org.uk> <mailto:Bim.Egan@rnib.org.uk> 
Cc: UAWG list <w3c-wai-ua@w3.org> <mailto:w3c-wai-ua@w3.org> 
Date: 9/24/2010 2:00 AM


	Hi there Bim, this is really just a problem of the browser not
implementing the bindings in rationale way. Indeed, a modifier key would
easy sort this out. 
	
	
	Cheers 
	Si. 
	
	======================= 
	
	Simon Harper 
	University of Manchester (UK) 
	
	More: http://simon.harper.name/about/card/ 
	
	On 23/09/2010 19:04, Egan, Bim wrote: 
	

		Sorry to butt in here, but it concerns me that as
accesskey bindings 
		frequently conflict with keyboard access to browser
toolbars or 
		plug-ins, and can also change settings in access
technology that runs in 
		the background while being sensitive to all keystrokes,
such as screen 
		readers, defined accesskeys could result in all HTML5
pages using them 
		being inaccessible to people  who navigate via keyboard
or use access 
		tech software, instead of the current situation where it
is difficult 
		only on some sites using code that conforms to
specification. 
		
		Bim 
		
		-----Original Message----- 
		From: w3c-wai-ua-request@w3.org
[mailto:w3c-wai-ua-request@w3.org] On 
		Behalf Of Simon Harper 
		Sent: 23 September 2010 18:44 
		To: UAWG list 
		Subject: Accesskey Discussion 
		
		I seems to me that HTML5 is becoming increasingly
platform like. In this 
		case I suggest that HTML5 specify a number of predefined
accesskeys for 
		common functionality including those useful for WebApps.

		
		Cheers 
		Si. 
		
		======================= 
		
		Simon Harper 
		University of Manchester (UK) 
		
		More: http://simon.harper.name/about/card/ 
		
		
		
		  To report this e-mail as Spam, please forward it to: 
		spam@mailcontrol.com 
		
		
		





Click here
<https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==
hDyrrpCP7OJABvMbt2+54+b6KDzl3P8OaTTfDqWPgPvXQw==>  to report this email
as spam.



-- 
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 Websense Hosted Security - 
http://www.websense.com/content/HostedEmailSecurity.aspx

Received on Monday, 27 September 2010 08:45:19 UTC