Re: Re: aria-kbdshortcuts

I had a chat to Dominic yesterday, and agreed that I would write a  
proposal for updating the accesskey spec, and he would work on a test  
implementation...

But I won't be doing that before next week.

In any event, I certainly agree with Lisa - things that are standard  
functions should generally have an activation that is the same for a given  
user in their browser on all sites, and accesskeys should be for things  
that aren't common enough to have a shortcut.

Note that this was the idea behind using the rel attribute to implement  
browser functionality, but at the time it didn't take off. We now have  
lots of sites trying to rebuild that on their own, which is harder to do  
and more prone to failure :(

But in practice, I think we'll see more of that as we get more  
intent-based events, and better use of semantics in web content.

Anyway, I have a task ahead of me. More to come…

cheers

On Thu, 30 Jul 2015 04:50:24 -0400, lisa.seeman <lisa.seeman@zoho.com>  
wrote:

> 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  
> &lt;schwer@us.ibm.com&gt; 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   &lt;schwer@us.ibm.com&gt; wrote:
> From: "Chaals McCathie Nevile" &lt;chaals@yandex-team.ru&gt;
>  To: "Dominic Mazzoni" &lt;dmazzoni@google.com&gt;, Richard  
> Schwerdtfeger/Austin/IBM@IBMUS
>  Cc: PF &lt;public-pfwg@w3.org&gt;
>  Date: 07/28/2015 10:40 AM
>  Subject: Re: aria-kbdshortcuts
>
> On Thu, 23 Jul 2015 14:34:31 -0400, Richard Schwerdtfeger
>  &lt;schwer@us.ibm.com&gt; wrote:
> &gt; Hi Dominic,
>  &gt;
>  &gt; This is in the current ARIA editors draft:
>  &gt; http://rawgit.com/w3c/aria/master/aria/aria.html#aria-kbdshortcuts
>  &gt;
>  &gt; 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
>
>
>
>
>
>
>


-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Saturday, 1 August 2015 15:08:26 UTC