FW: [WebAIM] thought experiment: automated testing and built-in keyboard controls

FYI - this discussion of accesskey and potential proposal from the WebAIM list may be of interest to this group.  

Jonathan

-- 
Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
jon.avila@ssbbartgroup.com

703-637-8957 (o) 
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter


-----Original Message-----
From: WebAIM-Forum [mailto:webaim-forum-bounces@list.webaim.org] On Behalf Of Chaals McCathie Nevile
Sent: Tuesday, August 04, 2015 11:47 PM
To: WebAIM Discussion List; deborah.kaplan@suberic.net
Subject: Re: [WebAIM] thought experiment: automated testing and built-in keyboard controls

On Wed, 29 Jul 2015 11:03:06 -0400, <deborah.kaplan@suberic.net> wrote:

> I'm looking for some suggestions from the peanut gallery for this idea 
> I've been spitballing. Developers like to add JavaScript keyboard 
> shortcuts in webpages. JavaScript keyboard shortcuts can be big 
> accessibility wins, of course -- but equally frequently, it seems, 
> they cause conflicts with assistive technology. Even more importantly, 
> the frequency with which they are meaningfully and visibly documented 
> is rare. It's often quite difficult for users to find out keyboard 
> shortcuts exist. YouTube keyboard shortcuts, for example, only seem to 
> be documented on the screen reader help page, and they are documented 
> *inaccurately*.
[...]

I've been thinking about this for a while. ;)

Like you, I think fixing accesskey is the direction we should be going in to get the biggest win and smallest loss for the minimal cost. I hope to deal with this problem in my draft proposal to do that:  
http://chaals.github.io/accesskey/index.src.html


In the meantime, I'm not sure - the more I think of it the more I see using javascript to build shortcuts as a serious anti-pattern. Having aria-kbdshortcut as part of that anti-pattern mitigates the documentation problem. And importantly, the attributes are in the DOM - so it isn't only screenreaders that can use them. It might be the least-worst way we can approach this for now.

But it's got a lot of problems. Most notably, it might like the YouTube case, not be true. For a feature that can readily override things users rely on, that's a pretty minimal improvement - we've made it potentially possible *if you get it right* to provide some information. Or, to mislead users even further, if you missed something.

More complex is that Browsers, Operating Systems, and other user agents can interfere with particular keystrokes or other behaviour, essentially trapping it and preventing it from returning to the application. So unless a developer knows what is being silently "stolen", s/he *cannot know*, and therefore cannot accurately document what is going to happen.

As Mallory noted, different apps need different strategies for explaining what is available. In some cases the three shortcuts can be part of the overall UI, in others the three hundred should really come with a context-based reminder being available…

…just some thinking aloud.

cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com _______________________________________________
To manage your subscription, visit http://list.webaim.org/ List archives at http://webaim.org/discussion/archives

Address list messages to webaim-forum@list.webaim.org

Received on Friday, 7 August 2015 01:32:51 UTC