+ public-html@
- public-html-a11y@

Moved to public-html, as we decided to do some time ago.
 
11.04.2015, 12:58, "Léonie Watson" <lwatson@paciellogroup.com>:

In the latest update to Jaws 16, Freedom Scientific has introduced a mechanism for handling shortcuts provided by websites [1]. Thought this may be of interest to anyone interested in the TF’s work on keyboard accessibility [2].

(corrected link [2] - CMN)
 
Yes - thanks :)
 

Websites like Facebook, Twitter, Google and others provide keyboard shortcuts for performing common tasks. On facebook.com it’s possible to move to the post status field by hitting the p key for example.

At Yandex we currently do this with javascript - as do many people. One of the problems with this is that we have to be very careful about mixing javascript even from different internal sources - there is a significant impact on our ability to modularise the development of a site in the way we generally do through e.g. the BEM methodology, where we want a global shortcut to work.

 

Windows screen readers struggle with these shortcuts because they use a virtual mode to support user-interaction [3]. When someone uses a website shortcut, the screen reader intercepts the keystroke and uses it for its own purpose. In Jaws the p key will move focus to the next paragraph for example.

This also impacts browsers that have some reasonably high-quality keyboard navigation system - which sadly are therefore fewer, and poorer, than they used to be.

 

Up until now, it has been necessary to manually inform the screen reader that it should ignore the next keystroke and pass it back through to the browser where the website shortcut can be executed. In Jaws this means pressing insert + 3, then the relevant shortcut key.

The new “Web application reserved keystrokes” setting in Jaws tells the screen reader to stop intercepting keystrokes in the browser. When enabled, Jaws will automatically execute the website shortcut as intended. So on facebook.com the p key will move focus to the post status field, and not to the next paragraph on the page.

I thought this was the purpose of the way role="application" was implemented. I don't think that is sufficient for anything except the simple case of the site and the user agent competing for keystrokes - where the reality is that you can have two or more parts of the site, the browser, and an assistive technology doing so. 

 

At the moment it doesn’t seem to be possible to enable this setting on a per website basis. That’s likely to be a bug though, since enabling this setting on a blanket “all sites” basis seems unhelpful.

Yes, that seems like a big but, unless it is simple to switch between the two modes.

 

[1] http://freedomscientific.com/Downloads/jaws/JAWSWhatsNew

[2] http://www.w3.org/WAI/PF/HTML/wiki/Keyboard

[3] http://tink.uk/understanding-screen-reader-interaction-modes/

cheers
 
Chaals

 

 

--

Léonie Watson Senior accessibility engineer, TPG

@LeonieWatson @PacielloGroup PacielloGroup.com

 

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