RE: notation for access keys

Hi Lisa, Coga TF,

 

FWIW, there is some concern about adding this aria-kbdshortcuts to the mix, as it is a poor implementation of accesskeys, that delivers half the functionality, with all the problems that accesskeys still have, including discoverability, conflict resolution, internationalization, and the ability for the end-user to apply remapping of keys to meet their needs. 

 

I was fortunate enough to be at a lunch meeting were this issue was discussed with a number of Googlers who are involved in the aria-kbdshortcuts discussion, and there is some other activity going on around browser functionality and accesskeys that will be experimental to start, but an effort to address the issues with accesskeys, as opposed to re-inventing the wheel with a new aria attribute.

 

Bottom line? Wait and watch aria-kbdshortcuts, but do not expect that they will be adopted fully (or even partially) at this time.

 

I’ve copied Chaals McCathieNevile on this note, as he is actively heading up this accesskey work today – he may have further thoughts to add.

 

JF

 

 

On Jul 30, 2015, at 4:52 AM, lisa.seeman <lisa.seeman@zoho.com <mailto:lisa.seeman@zoho.com> > wrote:

Hi Folks 
Should  our default representation for keyboard short cuts be consistent with the following

 <http://rawgit.com/w3c/aria/master/aria/aria.html#aria-kbdshortcuts> http://rawgit.com/w3c/aria/master/aria/aria.html#aria-kbdshortcuts 

(This is for the personalization notation in 

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

)

All the best

Lisa Seeman

 <http://accessibility.athena-ict.com/> Athena ICT Accessibility Projects 
 <http://il.linkedin.com/in/lisaseeman/> LinkedIn,  <https://twitter.com/SeemanLisa> Twitter