RE: ACTION-1642: New aria-kbdshortcuts property (for Issue 711)

Dominic Mazzoni wrote:
> 
> I agree that an HTML5 feature allowing users to bind keyboard shortcuts to commands
> would be great, but I think that's out of the scope of this group, and I don't think that's
> an argument *against* also having aria-kbdshortcuts (or whatever we call it).

"A rose, by any other name..." (William Shakespeare)
We already have a (still flawed) HTML5 semantic attribute already, and this effort appears primarily an abstraction of that semantic, so that it could be used in other host languages. Trying to fix the basic problems inherent with @accesskey will be critical when expanding/abstracting the functionality of this thing you wish to declare and expand to other languages.

> If you have a concrete proposal for what this should look like, please post it to the relevant
> list and send us a link. I'd be happy to engage on that. One option would be to try to "fix"
> the accesskey spec.

It's not like we're not trying, but through a ton of discussion, exploration and head-banging, it has become obvious to many of us who have grappled with @accesskey for over a decade that we simply must request some functionality from the user-agents, despite the fact that neither HTML5 nor ARIA want to be in a position of telling user agents how to do something. For the latest discussions around fixing @accesskey, we last worked on it in earnest at the F2F in Redmond in April (see: http://www.w3.org/2015/04/16-html-a11y-minutes.html#item05)

> So yes, we should provide simpler, more straightforward ways for web authors to achieve what
> they want in a way that communicates all of the semantics to the browser and AT. However we
> also need to provide ways to let web authors implement things at a lower level and still describe
> those semantics to AT.

At the risk of coming off overly pedantic, web authors aren't "implementing" anything, it’s the user-agents that implement the functionality, all that the web-author does is author the call, and especially here where the author wants to bind a specific keystroke sequence (modifier + bound key) to trigger a function - not "do" the function, but trigger it to happen. Yes, that's nuanced, but it is also in-part the heart of the problem.

For example, keystroke error resolution (in say, SVG with this new ARIA attribute). Who's responsible for that? The web author? The browser? The AT? The end user? Without explicitly defining the answer to that, you're introducing a serious user-problem. Following this line of reasoning, and invoking the old HTML5 Priority of Constituents mantra of 'Users over Authors, Authors over Implementers, Implementers over Code Purity', I would suggest that the proper answer is that the end user should be allowed to resolve that conflict. But how? They can't re-write the HTML or other host language using aria-kbdshrtcts, so they can only make that adjustment in either their browser, or AT.

But what of the keyboard only user who doesn't use AT, but, perhaps uses a Cyrillic keyboard instead, one that doesn't have the specific key character declared by the author? Once again, he can't re-write the code, he isn't using AT, and yet he has a problem. How does he fix it? (hint: in the browser)

Then there is discoverability - adding this wonderful attribute (which will only be exposed to AT by the way) still does not address the major issue of telling all end users that there are keyboard shortcuts available. 

Now it could be argued that it's not the role of ARIA to be doing this for non-ARIA tools, that the role of ARIA is to provide the abstraction to the Accessibility API so that AT can know and understand the Role, Name and State of the function or widget, but then that leaves a major hole - how will the function actually be actuated? If not directly by ARIA, then by the host user-agent, so once again in HTML that means invoking @accesskey, or writing a JavaScript function that does essentially the same thing (because why not use JavaScript when it's already a native function?) - but in either case handing the heaving lifting off to the browser, as well as all of the problems.

>> * The specified keyboard shortcut would activate a control, not focus it.
>> If it's a button, it implies that pressing that shortcut clicks on the
>> button.
>
> What if it is an input element - date picker, search box, etc? In some cases, being able to focus is entirely reasonable.

+1. 
I'll also chime in and say that the last thing we need/want is something that can trigger a function on both onFocus *AND* onKeypress, a concern I have when I start thinking of some of the possible use-cases here. I can't recall how many broken fly-out menus I've seen where this "doubling of functions to a single event handler" has occurred. 

Additionally, now you are going beyond declaring Role, State and Name, you are specifying a function. You wrote:
"The specified keyboard shortcut would ACTIVATE a control" (CAPS mine). I'm not opposed to that idea (well, maybe a little because ARIA is AT only), but moving from advising the AAPI to actually invoking a function seems to be a new expansion of ARIA's role and function. If you want to add functionality to an ARIA attribute, then that moves some responsibility onto ARIA to solve problems invoked by the attribute/function.
 
> 
>>  * Adding this attribute to an element does not change any browser
>> behavior. Adding role=button to an element doesn't make it a button,
>> it just informs AT that it acts like a button. Similarly, adding
>> aria-kbdshortcuts to an element doesn't make those keyboard shortcuts
>> function, it just informs AT that those keyboard shortcuts are available.
>> It's up to the author to implement it.

Once again, the author *declares it*, the browser (user-agent) implements it. But no matter what, the end user must be in control of it, or you are building a FAIL. And given the functionality is essentially one that the browser performs, the ability to change or modify that functionality must also come from the browser, no matter how loathsome it seems for us to be stating so (or for the browser vendors to be hearing).      I get that.
 
>> * Discoverability: AT such as screen readers could now announce the shortcut
>> for a button or menu item upon focusing it, just like when a user explores
>> a native menu item in a desktop app. It is still totally up to the author
>> how to expose this keyboard shortcut to non-AT users.

How? It's easy to say that, but can you give a concrete or hypothetical example? 

As you've previously noted, the modifier keys for @accesskey are inconsistent across browsers (is that good or bad? I dunno), but we clearly can't state (in prose, in the FAQ or whatever) use ALT + [key], because that isn't correct for all users. You can't even state a specific character binding, as the HTML5 spec today suggests that that for @accesskey the attribute value to be "... an ordered set of unique space-separated tokens", and that the spec also states "The accesskey attribute's value is used by the user agent as a guide for creating a keyboard shortcut that activates or focuses the element." - which clearly to me means that the functionality is ultimately controlled by the user-agent, the browser. The current spec also says the user-agent should stop processing @accesskey "If the value does not correspond to a key on the system's keyboard, then skip the remainder of these steps for this value." (http://www.w3.org/TR/html5/editing.html#processing-model-4),  So so-much for the Cyrillic keyboard user. 

The current HTML spec says nothing about conflict resolution between the browser and the Assistive Technology, so then what?  While this research is admittedly now 12 years old, I strongly believe that for the most part it still isn't completely wrong: http://john.foliot.ca/accesskeys-and-reserved-keystroke-combinations/ (TL;DR - there aren't a lot of keys available on a western keyboard that haven't already been claimed by one AT or other on some platform in some browser...)

All of this adds up to one thing: we need to help the browsers understand the problem, and we need to help them solve the problem, but it has to be done together, we can't just toss it up in the air and say "here's how we're going to communicate something, a thing that is ultimately flawed, to AT via ARIA" and then walk away - it's a waste of time and resources IMHO.

 
> This is a problem, since authors are notoriously bad at getting this right. If
> there were browser-defined behaviour as there is for accesskey (although
> most browsers made dumb decisions about exactly what to define) the browser
> would be able to provide discoverability in a standard way to all users. That
> seems a vastly superior approach.
>
>> * Remember, lots of web sites *already* have keyboard shortcuts that
>> activate controls and menu items. This spec simply provides a consistent
>> way to provide this information to AT. Otherwise, authors have to include
>> this information in a control's label or description.
> 
> Agreed.
 
(and how many of those sites are accessible to the end users? How are thy handling keystroke conflicts with AT today? How do they communicate the presence and functionality of the keyboard shortcuts to the end users?)
 
>> * Providing the keyboard shortcut in a standard format allows the AT to
>> not only expose it to the user, it allows the AT to parse it, transform it,
>> or act on it.

Wait, hang on a second. You've gone from saying: 

     "...adding aria-kbdshortcuts to an element doesn't make those keyboard shortcuts function, it just informs AT that those keyboard shortcuts are available. It's up to the author to implement it"

...to:

     "Providing the keyboard shortcut in a standard format allows the AT to not only expose it to the user, it allows the AT to parse it, transform it, or ACT ON IT." (CAPS mine)
AND
     "The specified keyboard shortcut would ACTIVATE a control" (CAPS mine)

Are you "providing" the shortcut functionality, or simply informing AT of that functionality? And if that functionality is only being announced, where is the actual functionality coming from? Whether via @accesskey or via a scripted function, the same problems will exist. At the risk of sounding like a smart-alex, we're building an attribute to announce a broken function?

>> For example, a screen reader could discover that a key
>> conflicts with a built-in key and *automatically* suggest using the
>> passthrough key.

So, are you suggesting then that Assistive Technology can explicitly modify the functionality of the browser? That (using RFC @119 language) 
"Browsers SHOULD (MUST?) remap keystroke input functionality based upon Assistive Technology feedback", as that is sure how I read your statement.

>> Or, other AT could let the user press one modifier key
>> and then highlight all commands that can be activated using that modifier.

How does that work? Is AT rendering that DOM information somehow, similar to how I can call up a list of Headers or Links? And even if yes, how does the end user then do the remapping if there is indeed a conflict or problem? See my SHOULD statement above. 

(For what it is worth, that is how the old Opera sort of worked, where a keystroke combo opened a dialog that showed all @accesskeys on a page. The end user could then also navigate to those accesskey 'features' using that floating menu, or via the keystroke combos. You won't be surprised that Chaals was involved with that too...)

>>   - Web developers already have lots of other ways to support keyboard
>>   shortcuts in their web apps. Accesskeys are the only ones that are
>>   currently exposed to screen readers, but they're very limited, so web
>>   developers don't actually use them much.

And how many of those "other ways" are actually accessible? (Honest question) Can you (for my information if for nobody else) provide some examples of these alternate ways? Even if the flawed @accesskey is the only method of exposing this functionality to the AAPIs today (for screen readers), can you state that the "other ways" don’t have the same flaws around conflict resolution and discoverability issues that @accesskeys have? 
 
> 
> I worry that this proposal risks re-inventing accesskey, with some of the same
> mistakes and some special new ones. I think we could more readily fix accesskey
> to solve both sets of problems, but in any event I think it is a very bad idea to
> simply start down the path as if we had no knowledge or experience.

+1, and +1 again

There is no question that we need and want this type of functionality, and/but we need to ensure it is accessible. 

While I have extrapolated from your responses on list, it very much does feel that you want this ARIA attribute to be doing more than just communicate to the AAPIs - I've quoted you often - and that's cool. But if that is the case, we've already done a ton of discussion and thinking about this, for a really long time, and honest and truly, without providing instructions on expected outcomes and required functions to the browser implementers, you'll end up with a flawed ARIA attribute no better than the currently flawed @accesskey.  And as Chaals and I have chased this around the track for over a decade, the answer is, the browser MUST be involved in exposing both the keystroke bindings, and allowing for end-user re-mappings. *HOW* the browsers ultimately do that in their UI / operation can be finessed by browsers, but whether via @accesskey or a scripted function in SVG, the fundamental problems will remain, and make the functionality inaccessible to some (or many). And if that is the case, why bother creating this new attribute?

Respectfully,

JF
​-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

Received on Friday, 12 June 2015 03:15:20 UTC