Re: Action-2036 aria-keyshortcuts

The one key combination that consistently bothers me is W3C's media
wiki using the accesskey n for some functionality.
In IE this conflicts with the alt-n key combination, which is used to
interact with the notification bar.
I would highly recommend against using the application role for
anything other than what the Jungle Book movie would term "the bear
necessities".
Web authors generally do not understand the intricacies of screen
reader modes (and I don't expect them to). This often leads to static
content ending up in an application role which in turn makes it near
impossible to read with a screen reader.
Screen readers should turn application mode on and off smartly based
on the ARIA widget roles used, and authors should use non-conflicting
key combinations or recommend that screen reader users utilize the key
pass through mode if that is not possible.
That will cause a lot less grief for the end user than a
misapplication of the application role.


On 4/17/16, Rich Schwerdtfeger <richschwer@gmail.com> wrote:
> Matt, please prepare a section in the APG that gives author guidance on use
> of aria-keyshortcut. Let’s see a proposal.
>
> Rich
>
> Rich Schwerdtfeger
>
>
>
>
>> On Apr 7, 2016, at 6:11 PM, Matt King <a11ythinker@gmail.com> wrote:
>>
>> Jason,
>>
>> I don't think that quick-nav mode keys are a good example of screen
>> readers failing to avoid keys that may be used by applications. VoiceOver
>> Quick-nav mode, JAWS virtual cursor mode, NVDA browse mode, and
>> Window-Eyes brows mode are all example of how screen readers have made an
>> effort to avoid conflicts. In that sense, they are similar to the VO key,
>> the NVDA key, the JAWS key, and the WE key, all of which are screen reader
>> specific modifiers that are also designed to avoid conflicts.
>>
>> I would not recommend we include any language in the aria-keyshortcuts
>> description that would encourage authors to use the application role to
>> thwart users' ability to use any of these screen reader keys.
>>
>> Matt
>>
>> -----Original Message-----
>> From: White, Jason J [mailto:jjwhite@ets.org]
>> Sent: Thursday, April 7, 2016 1:33 PM
>> To: Matt King <a11ythinker@gmail.com>; 'Joseph Scheuhammer'
>> <clown@alum.mit.edu>; 'Richard Schwerdtfeger' <richschwer@gmail.com>;
>> 'ARIA' <public-aria@w3.org>
>> Subject: RE: Action-2036 aria-keyshortcuts
>>
>>
>>
>>> -----Original Message-----
>>> Could you please provide some specific examples? I don't know that I
>>> have seen this type of conflict persist for long. Typically, screen
>>> reader developers regard them as screen reader bugs.
>>
>> Any screen reader in browse/virtual viewer mode is a very good example, as
>> it takes over most of the letter keys, some control key combinations, etc.
>> Unless you're in a widget that switches it into focus mode, it's going to
>> process these keystrokes first.
>>
>> I recall recommendations, for example, about using Google Docs with JAWS
>> under MS-Windows that the virtual cursor should be turned off. Key
>> conflicts were, as I understand it, one of the reasons, e.g., use of
>> unmodified letter keys.
>>
>>
>> ________________________________
>>
>> 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.
>>
>> ________________________________
>>
>
>


-- 
Birkir R. Gunnarsson
Senior Accessibility Subject Matter Expert | Deque Systems
2121 Cooperative Way, Suite 210
Herndon, VA, 20171

Ph: (919) 607-27 53
Twitter: @birkir_gun

Received on Sunday, 17 April 2016 21:34:30 UTC