Re: ACCESS_KEYS reassigned by device

On Wed, 24 Oct 2007 14:53:41 +0200, Alan Chuter <achuter@technosite.es>  
wrote:

> Concerning "provide a summary of access keys used in content on a  
> separate page."
>
> On Wed, 17 Oct 2007, Charles McCathieNevile wrote:
>> CMN: This is a bit difficult, since access keys can (and in some cases  
>> should) be reassigned by the device in ways the author cannot predict.
>
> I understand you to mean that this is done by some devices. So I've  
> added to the text like this:
> "If it is not apparent from the content or shown by the device, provide  
> a summary of access keys used in content on a separate page (but perhaps  
> warn that access key assignments may be changed by the device in ways  
> the author cannot predict)."
>
> Could you provide more background about this?

Sorry for the delay.

On IE and old versions of Firefox/Mozilla, the implementation of accesskey  
meant that pages which incorporated them could change the expected UI  
behaviour with no explanation or warning.

In order to combat this problem, various companies and individuals have  
produced browser extensions, add-ons, scripts, and so on that check which  
keys are given an accesskey, and then change that to make sure it is a key  
the user expects to have avaialable. Good implementations also show the  
user themselves which keys are actually assigned - in accordance with UAAG  
guideline 11, and especially  
http://www.w3.org/TR/UAAG/guidelines.html#tech-info-current-ua-config

The upshot is that a user agent should make it clear to the user what  
controls they can actually use, and not the page author. The only reason  
for an author to do so is in meeting [DEFICIENCIES] where they provide  
work-arounds for known problematic implementations...

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals              Try the Kestrel - Opera 9.5 alpha

Received on Wednesday, 28 November 2007 17:32:56 UTC