E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: deborah.kaplan
Date: Wed, Jul 29 2015 9:03AM
Subject: thought experiment: automated testing and built-in keyboard controls
No previous message | Next message →

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'm thinking about what a community standard would look like for the way to visibly document the presence of keyboard shortcuts on any page that had them, so that all users (regardless of assistive technology) would be able to easily discover what they are. And then, because I'm thinking about automated test suites right now, sites could run modular, shareable automated tests which looked to see if keyboard shortcuts were documented according to that standard.

I'm thinking of something such as:

"If the page has JavaScript listeners responding to keyboard shortcuts, beyond certain standards required to replicate mouse movement behavior on keyboard focus (e.g. checking for keypress events to bring up hover menus), then the page will have, in visible text, on screen without any hover or activation, with good contrast, no smaller than .8em:
* A link with the text "Keyboard shortcuts help" or internationalized equivalent
* Which brings up access to the keyboard shortcuts, if in a modal, than in an accessible, labeled, keyboard-trapping modal
* Which includes instructions to disable keyboard shortcuts

If the page has an application with menus and/or icons (eg. a rich text editor), then that application will have, in visible *text* in the button/menu bar, without any hover or activation, etc.:
* A button with the text... ugh. No idea what would be short enough that people would put it in a menubar, but long enough to be informative. My impression is that usability testing shows that throwing a "?" icon in a webapp menubar does not give anyone the idea they might be able to look up functionality that had not occurred to them; e.g. you would only go to a "?" icon looking for keyboard shortcuts if you were specifically choosing to go look for keyboard shortcuts. In other words, if you were already somebody involved in web development/design/accessibility. Maybe "Shortcuts"?
* If the web application has textual menu/button labels, then, either by default or by user-configurable option, they can be displayed with a standard visual KB shortcut indicator right there on the default menu/button label. (E.g. Underscore under the shortcut letter, Windows default; Letter + modifier key next to the menu item, OS X default)"

I'm not sure if any of these standards even make sense, let alone if they are things we could convince people would make good community standards. That's why I'm throwing it out to all y'all for your opinions.

Note: I think we all agree here that the best way to make things standard is to build them into the semantics, so that individual web developers don't need to think about these issues, and instead browsers, assistive tech, and extensions can make the keyboard shortcuts visible in the most appropriate way. I know that this could happen with aria-kbdshortcuts in the current WAI-ARIA editor's draft, and I also know it could happen with a solid revision to access keys (my preference; reasons at <http://discourse.wicg.io/t/keyboard-shortcuts-need-to-be-configurable/963>;). But right now I'm thinking about conventions for the web we have today. In the web we have today, the preference seems to be for web developers to roll their own, while hopefully community standards sometimes start to dominate for all of those individual implementations. And hopefully those community standards aren't for hamburger menus on desktop.

Deborah Kaplan

From: _mallory
Date: Wed, Jul 29 2015 9:31AM
Subject: Re: thought experiment: automated testing and built-in keyboard controls
← Previous message | Next message →

At the very least, I think stuff like webby editors and the like need
somthing different and comprehensive from stuff like shortcuts as seen
on Twitter, DuckDuckGo, etc.

Also possible to cheat (for internationalisation) with an onscreen
focusable with a keyboard icon + "?" where onfocus (maybe hover too)
this expands to show the full text, on sites where they simply don't
have the room in all languages. This way it doesn't rely on title
attributes and users don't have to click it to know what it does
(mystery meat).

More of a problem is non-conflicting keys. I've seen proposals using
F1 for stuff for example. That brings up my application Help dialog
usually.

_mallory


On Wed, Jul 29, 2015 at 11:03:06AM -0400, = EMAIL ADDRESS REMOVED = 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'm thinking about what a community standard would look like for the way to visibly document the presence of keyboard shortcuts on any page that had them, so that all users (regardless of assistive technology) would be able to easily discover what they are. And then, because I'm thinking about automated test suites right now, sites could run modular, shareable automated tests which looked to see if keyboard shortcuts were documented according to that standard.
>
> I'm thinking of something such as:
>
> "If the page has JavaScript listeners responding to keyboard shortcuts, beyond certain standards required to replicate mouse movement behavior on keyboard focus (e.g. checking for keypress events to bring up hover menus), then the page will have, in visible text, on screen without any hover or activation, with good contrast, no smaller than .8em:
> * A link with the text "Keyboard shortcuts help" or internationalized equivalent
> * Which brings up access to the keyboard shortcuts, if in a modal, than in an accessible, labeled, keyboard-trapping modal
> * Which includes instructions to disable keyboard shortcuts
>
> If the page has an application with menus and/or icons (eg. a rich text editor), then that application will have, in visible *text* in the button/menu bar, without any hover or activation, etc.:
> * A button with the text... ugh. No idea what would be short enough that people would put it in a menubar, but long enough to be informative. My impression is that usability testing shows that throwing a "?" icon in a webapp menubar does not give anyone the idea they might be able to look up functionality that had not occurred to them; e.g. you would only go to a "?" icon looking for keyboard shortcuts if you were specifically choosing to go look for keyboard shortcuts. In other words, if you were already somebody involved in web development/design/accessibility. Maybe "Shortcuts"?
> * If the web application has textual menu/button labels, then, either by default or by user-configurable option, they can be displayed with a standard visual KB shortcut indicator right there on the default menu/button label. (E.g. Underscore under the shortcut letter, Windows default; Letter + modifier key next to the menu item, OS X default)"
>
> I'm not sure if any of these standards even make sense, let alone if they are things we could convince people would make good community standards. That's why I'm throwing it out to all y'all for your opinions.
>
> Note: I think we all agree here that the best way to make things standard is to build them into the semantics, so that individual web developers don't need to think about these issues, and instead browsers, assistive tech, and extensions can make the keyboard shortcuts visible in the most appropriate way. I know that this could happen with aria-kbdshortcuts in the current WAI-ARIA editor's draft, and I also know it could happen with a solid revision to access keys (my preference; reasons at <http://discourse.wicg.io/t/keyboard-shortcuts-need-to-be-configurable/963>;). But right now I'm thinking about conventions for the web we have today. In the web we have today, the preference seems to be for web developers to roll their own, while hopefully community standards sometimes start to dominate for all of those individual implementations. And hopefully those community standards aren't for hamburger menus on desktop.
>
> Deborah Kaplan
> > > >

From: Chaals McCathie Nevile
Date: Tue, Aug 04 2015 9:46PM
Subject: Re: thought experiment: automated testing and built-in keyboard controls
← Previous message | No next message

On Wed, 29 Jul 2015 11:03:06 -0400, < = EMAIL ADDRESS REMOVED = > 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
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com