Re: Re: aria-kbdshortcuts

Should we also be binding accesskeys to the coga proposal for aria-function via defaults that can be overridden by the user preferences fr the default behavior for that function? It seems like a better way then having access keys for common functions set by the author.  Further the device can have default implementations that are intuitive on the operating system aria-kbdshortcuts should be only for functions that are unique to the site.


see https://rawgit.com/w3c/coga/master/issue-papers/links-buttons.html
and  https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Easy_Personalization


and the start of implementations at https://github.com/ayelet-seeman/coga.personalisation




 


All the best

Lisa Seeman

Athena ICT Accessibility Projects
LinkedIn, Twitter





---- On Tue, 28 Jul 2015 23:37:25 +0300 Richard Schwerdtfeger <schwer@us.ibm.com> wrote ---- 

 This is informative information provided by the author that is provided in a standardized format to define how to activate an element. It is not a browser behavior directive. 
 
 accesskey is busted and has been for over a decade. HTML5 was unable to get it done even though IBM contributed a patent to the former HTML working group to solve the problem of access key. 
 
 Access key, today, is a hack. It does not tell you what the access key is for and implementation across browsers is inconsistent. Some browsers give focus to the element while others do an activation. HTML has set the bar for hacks here. 
 
 I have absolutely no faith that the HTML working group can get a replacement for access key done. Part of that stems from the move to mobile where keyboards are used less. I just don't see motivation to do this in the HTML working group. I personally, burned a lot of cycles in the beginning to fix access key by working for months with lawyers to get the IP behind an earlier version of access element donated to the W3C and the whole discussion went into the weeds trying to resurrect the access key hack. 
 
 Dominic has done a fine job in providing a standard way to share what key strokes they have applied to respond to keyboard command to activate an element.  
 
 
 
 
 Rich Schwerdtfeger
 
 "Chaals McCathie Nevile" ---07/28/2015 10:40:31 AM---On Thu, 23 Jul 2015 14:34:31 -0400, Richard Schwerdtfeger   <schwer@us.ibm.com> wrote:
 
 From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
 To: "Dominic Mazzoni" <dmazzoni@google.com>, Richard Schwerdtfeger/Austin/IBM@IBMUS
 Cc: PF <public-pfwg@w3.org>
 Date: 07/28/2015 10:40 AM
 Subject: Re: aria-kbdshortcuts
 

 
 
 On Thu, 23 Jul 2015 14:34:31 -0400, Richard Schwerdtfeger  
 <schwer@us.ibm.com> wrote:
 
 > Hi Dominic,
 >
 > This is in the current ARIA editors draft:
 > http://rawgit.com/w3c/aria/master/aria/aria.html#aria-kbdshortcuts
 >
 > Please let us know if you have any issues.
 
 I'd like to know what I don't understand, because to me this looks like it  
 has all the drawbacks accesskey still has, but loses most of the benefits,  
 effectively sending us *backwards*.
 
 1. In particular, unlike accesskey it doesn't even work unless the author  
 hooked it up right.
 
 2. Assuming that authors mostly get keyboard listeners right, this  
 approach continues the problem of sites like twitter hijacking standard  
 browser interaction, which of course is amazingly confusing.
 
 3. It requires developers to use Javascript to detect particular user  
 behaviour, and map to their presumed intent. That assumes developers know  
 enough about a user's context to determine what behaviours are appropriate  
 for interacting with a control, which is simply Wrong™.
 
 4. It encourages developers to document the resulting interface of a User  
 Agent about which they don't have enough information, in the context of  
 their particular site, rather than providing the user agent sufficient  
 information to provide documentation. The half-baked approach of using  
 .accessKeyLabel as per HTML5 would be better, as instead of relying on the  
 author to get interaction code right, at least all they need to do in  
 order to provide documentation is query a simple DOM attribute.
 
 5. Like accesskey it becomes possible to find out what other scripts claim  
 they will trap, but unlike accesskey with .accesskeyLabel there is no way  
 to know if that is true, let alone "negotiate" among scripts. Using  
 accesskey allows that work to be devolved to the browser.
 
 With regards to the editor's note, understanding what an interactive  
 component does should come out of computing its accessible name (possibly  
 in context, e.g. increasing the month in a date-picker). The only case  
 this doesn't apply is where an accelerator is applied to a pure JS  
 function, but it isn't hard to imagine a standard approach among the many  
 quick hacks that would already work.
 
 cheers
 
 Chaals
 
 -- 
 Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com