Re: [keyboard] Web application reserved keystrokes in Jaws


> On Apr 13, 2015, at 05:33, chaals@yandex-team.ru wrote:
>
>>
>> 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.

Recent screen readers and browser extensions, for example, VoiceOver and ChromeVox, avoid key combinations that are likely to be used by Web applications. In particular, they avoid the alphanumeric keys. I prefer this solution, as it avoids the problem you’re describing. Also, there are no “virtual viewers” and no modes. I think the navigational model of ChromeVox is excellent.

Some people are attracted to the way in which Vi takes over the alphanumeric and punctuation keys for editor commands, at the expense of having multiple modes; others dislike Vi for this among other reasons. The approach adopted by some Windows screen readers (and by Orca under Linux) is broadly similar, but it doesn’t seem to generate polarization among users between those who prefer this approach and those who resent it.

I don’t think users without disabilities would be so tolerant of an interface with so many modes, options and complexities if they had to rely on it for all of their interactions with the Web.

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

This is my understanding also.
>>
>> 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.
>>
Even worse, unless the user has changed the setting and remembers doing so, it won’t be obvious in advance what any given key will do on any particular site. It might invoke the screen reader command, or a completely unrelated Web application operation.

The best solution I can think of is to make it easy not only to switch modes, but to query which mode is currently in effect; and Web application authors should be cautious about providing keyboard bindings for potentially destructive or irreversible operations such as deletion. This solution doesn’t simplify the user’s task at all, but if they’re using such a screen reader, they’re already committed to the associated complexity.

Despite the above comments, using alphanumeric and punctuation keys without modifiers makes commands easier to type, so I still have a soft spot for programs which do this, including Vi, or more accurately, Vim. For a screen reader though, especially in modern Web conditions, it’s a liability in the end.


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________

Received on Monday, 13 April 2015 14:59:21 UTC