Re: aria-kbdshortcuts

Charles,

Responses to some of your points inline.

On 2015-07-28 11:40 AM, Chaals McCathie Nevile wrote:
> I'd like to know what I don't understand, because to me this looks 
> like it has all the drawbacks accesskey still has, but loses most of 
> the benefits, effectively sending us *backwards*.
>
> 1. In particular, unlike accesskey it doesn't even work unless the 
> author hooked it up right.

That's no different from ARIA in general.  For example, applying 
"role='checkbox'" is pointless unless the author has done the work to 
make the element look and behave like a checkbox.  ARIA is 
after-the-fact.  A developer has re-purposed markup, using CSS and 
JavaScript to make the markup render as some widget, react to mouse 
clicks as if it were that kind of widget, and possibly allow users to 
interact with it using the keyboard.  Author/developers add ARIA in 
these scenarios to communicate this information to ATs (that it is a 
checkbox, what its checked state is, that it controls some other widget, 
and so on).  All aria-kbdshortcuts does is allow authors/developers to 
document what they have implemented keyboard-wise.

>
> 2. Assuming that authors mostly get keyboard listeners right, this 
> approach continues the problem of sites like twitter hijacking 
> standard browser interaction, which of course is amazingly confusing.

Yes, this is a problem.  But, again, authors have already done the 
hijacking, and *not* exposing it via aria-kbdshortcuts isn't going to 
stop it.  At least with aria-kbdshortcuts there is the possibility that 
an AT can warn the user what keystrokes the web app  supports, and by 
implication, what was hijacked.

On the other hand, authors should be encouraged to not override standard 
browser interaction, and to use well known interaction patterns.  The 
spec text for aria-keyboardshortcuts could emphasize that, and the ARIA 
Authors Practices Guide could further reinforce it.

>
> 3. It requires developers to use Javascript to detect particular user 
> behaviour, and map to their presumed intent. That assumes developers 
> know enough about a user's context to determine what behaviours are 
> appropriate for interacting with a control, which is simply Wrong™.
>
> 4. It encourages developers to document the resulting interface of a 
> User Agent about which they don't have enough information, in the 
> context of their particular site, rather than providing the user agent 
> sufficient information to provide documentation. The half-baked 
> approach of using .accessKeyLabel as per HTML5 would be better, as 
> instead of relying on the author to get interaction code right, at 
> least all they need to do in order to provide documentation is query a 
> simple DOM attribute.

I'm missing something here.  A developer has implemented keyboard 
interaction, and uses aria-kbdshortcuts to document for ATs what the 
keystrokes are.  I don't see how "... they don't have enough 
information".  They wrote the code and are in the best position to 
indicate what they did.

>
> 5. Like accesskey it becomes possible to find out what other scripts 
> claim they will trap, but unlike accesskey with .accesskeyLabel there 
> is no way to know if that is true, let alone "negotiate" among 
> scripts. Using accesskey allows that work to be devolved to the browser.
>
> With regards to the editor's note, understanding what an interactive 
> component does should come out of computing its accessible name 
> (possibly in context, e.g. increasing the month in a date-picker). The 
> only case this doesn't apply is where an accelerator is applied to a 
> pure JS function, but it isn't hard to imagine a standard approach 
> among the many quick hacks that would already work.

Right, using the accessible name is an answer to the editor's note. 
After all, a menuitem named "Save" likely performs a save function :-).  
Even so, it's possible there are limits to what can be accomplished with 
an accessible name, although I don't have a use case in hand.  In such 
cases, it would be useful to have some way to further describe the 
function invoked by the keystrokes.  For that matter, it would be useful 
to have descriptions for functions invoked by mouse clicks and touch 
events where/if the name isn't sufficient. Possibilities include 
aria-describedby and the proposed aria-hint [1].  The latter provides 
help text information that is meant to be complementary to the 
accessible name.  But, this still need discussion.

Ciao,

[1] https://www.w3.org/WAI/PF/Group/track/issues/406

-- 
;;;;joseph.

'Array(16).join("wat" - 1) + " Batman!"'
            - G. Bernhardt -

Received on Thursday, 30 July 2015 16:04:32 UTC