WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: thought experiment: automated testing and built-in keyboard controls

for

From: _mallory
Date: Jul 29, 2015 9:31AM

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 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
> > > >