Re: authoring guidelines in aria-keyshortcuts

Matt, 

1. I agree. That is why it is worded the way it is: "Authors SHOULD avoid keyboard shortcuts that are used by supported assistive technologies running on the intended operating system platforms.”

“intended” operating systems and “supported” assistive technologies is in there for a reason. If you are writing a web application you need to test with an assistive technology. Those that you support on the targeted operating system should be what the author should be directed to do. We cannot expect the author to support everything on the planet. 

2. I agree. That is why it is written as a SHOULD and not a MUST. It is worded as:

"Authors SHOULD avoid using keyboard shortcuts that are used by the user agent. Implementing keyboard shortcuts that conflict with the user agent, will result in a loss of user agent functionality.”

3. Here we disagree. Every operating system has its own set of keys that are stolen. If the author is writing a web page and does not test for each OS platform they are targeting that is a problem. Sometimes people test on only one platform. 

Many designers look at the ARIA specs. In fact when they don’t think about the page semantically we get accessibility added late in the process further driving up costs. UX designers at IBM have started provided  keyboard implementations in their designs. I just saw this from the Verse design team this past week based on the discussion with the CSS Working Group at CSUN regarding Flexbox. The author is required to implement what the designer asked and this is a vehicle for exposing the documentation to the user. We are looking at creating new tools for designers to make this easier for them to expose the keyboard design to developers. 

Sorry, but you have not made a compelling argument and Apple has also provided feedback that these issues needed to be addressed. 

If you do not plan on addressing these issues then I definitely don’t want this guidance in the design guide. So, before I agree you need to show me a section of the authoring practices guide that includes guidance like this. Otherwise, I do not support taking it out. 

Also, if we want to make more references to the Authoring Practices we need a standard way of doing that in the ARIA spec. My concern is that the authoring practices is not a normative document. It is more of a living document where content changes. We can’t have broken links in a normative spec. Also, moving all the authoring guidance this late in ARIA 1.1’s development is a concern. I would rather consider that for an ARIA 1.2. … IOW I like the idea but we would need to do this throughout the document to put this in a normal flow for developers and designers. Neither the HTML or SVG specs. do this today. We would be a first to do it. We also need to address necessary RFC SHOULDs and MUSTS for an authoring guide. 

 

Rich

Rich Schwerdtfeger




> On Apr 7, 2016, at 7:26 PM, Matt King <a11ythinker@gmail.com> wrote:
> 
> 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