RE: authoring guidelines in aria-keyshortcuts

Hi Rich,

 

The reason I am pushing back on these statements about key conflicts is because I think the guidance statements, as written, are not helpful and may in fact cause confusion or lead authors astray. I do not believe it is useful to make a blanket statement that tells authors they SHOULD avoid key conflicts with all screen reader keys, all user agent keys, and all operating system keys. 

 

1.      Screen reader keys: it is almost impossible to conflict with them in the first place because of the way screen readers are designed.

2.      User agent keys: conflicting with them is often a necessary part of creating a good UX and rarely blocks access to or even inhibits convenient access to UA functionality. Of course, authors SHOULD avoid blocking UA functionality. This is a topic that should be addressed in the APG; it can’t be done in a sentence.

3.      Operating system keys, you can’t conflict with them in a web app so why bother mentioning it.

 

The other issue is that the keyshortcuts property is only a documenting mechanism, not an implementation mechanism. So, it is hard to imagine anyone turning to that part of the spec for UX design guidance. 

 

However, If there is consensus that the spec must include guidance on this topic, then I’d like to suggest we reword it in a way that is efficacious. I’d be happy to suggest some wording if there is consensus that the ARIA spec should include UX design.

 

That said, I’d like to reemphasize the idea that we should have a reasonably high bar for inclusion of authoring guidance in the spec. I would like to propose that the spec should only include authoring guidance that is essential to effective implementation of an ARIA role, state, or property and that such guidance be included in the description of that role, state, or property. In this case, you can effectively implement the keyshortcuts property no matter what silly key assignments someone may make. Guidance on which keys to implement is an UX design topic that generally only intersects with ARIA in the implementation of widgets. And, for that aspect, it is all non-normative and and deligated to the APG.

 

It is probably better that authors use the keyshortcuts property to reveal their design, no matter how crummy, rather than leave users in the dark.

 

Matt

 

From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
Sent: Thursday, April 7, 2016 3:49 PM
To: ARIA <public-aria@w3.org>; Matt King <mck@fb.com>
Subject: authoring guidelines in aria-keyshortcuts

 

For some reason my Mac mail was copying messages into my other personal mail folder vs. gmail and made a mess of things. I ended up cleaning up my personal email box so I don’t have a copy of your email about putting all the authoring guidance in the authoring practices. 

 

I principle I agree with this, however for some general guidance that I think is critical like remembering to think about the browser, platform AT, and OS and I can’t reference the authoring practices from the spec. at this time as I can’t really reference key shortcut guidance in the authoring practices document now and your list of to-dos is already extensive. So for now I would like to keep that guidance in here. If you create a section of the authoring practices that includes these points and all the other possible keyboard specific issues (it is comprehensive) we can reference that in the future. 

 

We agree this is definitely an authoring issue. There is precedence in the ARIA spec. to include authoring guidance in a number of places. 

 

Rich

Rich Schwerdtfeger