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

A few thoughts:

1.       aria-kbdshortcuts = aria-keys (the other is just too long and
spelling is too obscure).

2.       Why do we restrict ourselves to only one non-modifier key? I am
thinking of Voiceovers right/left arrow pressed simultamiously to to switch
modes, I like the idea of being able to use arrow keys, easy operation (as
opposed to trying to execute say, ctrl-alt-shift-q which causes hand
cramping).

3.       (probably premature), what about custom touch gestures (keyboard
equivalent on touch-screen devices)? Anything we can do about that as part
of this attribute?

 

Also

+1 to Charles for the following:

" 

.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.

"

 

Discoverability for keyboard only users is "key" to successful keyboard
operability. Adding an ARIA attribute primarily aimed at assistive
technologies does not really address that issue.

If we think the accesskey attribute is not usable because different browsers
have slightly differing keyboard behavior implementation, imagine how that
compares to every author defining keyboard operation for his/her own website
(sometimes without full testing).

This does not address the fundamental problem, which is discoverability, not
only by assistive technologies but also by keyboard only users.

 

I can totally see the use case for this in navigating within complex widgets
such as with roles menu, listbox, radiogroup, slider, spinbutton and
toolbar, but I think revisiting the accesskey attribute through user
implementation guidelines, making sure it is discoverable for keyboard only
users as well as users of assistive technologies is a more beneficial avenue
for simpler roles such as links, buttons and a way to make non-focusable
simple controls operable via keyboard.

Cheers

 

 

From: chaals@yandex-team.ru [mailto:chaals@yandex-team.ru] 
Sent: Thursday, June 11, 2015 7:13 AM
To: Dominic Mazzoni; John Foliot; HTML Accessibility Task Force
Cc: public-pfwg@w3.org
Subject: Re: ACTION-1642: New aria-kbdshortcuts property (for Issue 711)

 

Some thoughts on this:

 

10.06.2015, 18:09, "Dominic Mazzoni" <dmazzoni@google.com
<mailto:dmazzoni@google.com> >:

Answers to questions raised by both Joseph and Stefan:

 

* 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 boox, etc? In some
cases, being able to focus is entirely reasonable.

 

 

* 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.

 

* 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.

 

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.

 

 

* 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. For example, a screen reader could discover that a key

conflicts with a built-in key and *automatically* suggest using the

passthrough key. Or, other AT could let the user press one modifier key

and then highlight all commands that can be activated using that modifier.

These are not *primary* use cases, they are simply arguments in favor of

making this a standardized, parseable attribute as opposed to just free
text.

 

Agreed.

 

For what it is worth, any accesskey implementation that doesn't do this
isn't particularly good.

 

 

* How does this differ from accesskey? So many ways:

 

  - Accesskeys have different modifiers in every browser. See the Wikipedia

    page to get an idea of how confusing it is for web developers and users:

 

    http://en.wikipedia.org/wiki/Access_key

 

  - Accesskeys don't even have the same *behavior* in all browsers - some

    just focus, others activate.

 

Both of those things are features. Different browsers work in different ways
and serve different users. Insisting that all interfaces are the same is an
anti-pattern. Consistency is indeed helpful, but there are different things
to be consistent with - the same browser on a different device? A different
browser on the same device? Native applications on windows desktops?

 

 

  - Accesskeys don't let you choose the modifier keys. Setting

    accesskey='h' means to press Alt+H in IE, there's no way to make

    a shortcut like Ctrl+H, Alt+Shift+H, or just 'H' with no modifier keys.

 

This is a bug in HTML5, and in browser implementations. (As far as I know,
Presto-based Opera was the only browser that got this right in a native
implementation ;( ).

 

 

  - 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.

 

The fundamental problem is that they are limited by poor browser
implementation.

 

    This proposal allows web developers

    to *implement* keyboard access however they choose, and simply *expose*

    the information about those shortcuts to AT in a consistent way.

 

But makes it hard to expose the same features to most users, who don't
connect via the accessibility API - including probably most users who rely
on keyboard access.

 

It is also a bad idea to have every developer try to write their own
interface - it makes building consistency a nightmare. So if there is a way
that *reduces* the desire of authors to specify the details of the UI they
are adding, knowing that browsers will make it work, that would provide a
big improvement in accessibility of the platform.

 

 

* If a control has both accesskey and aria-kbdshortcuts, I think

aria-kbdshortcuts should be the only one exposed to AT, just like aria-label

overrides alt.

 

* I agree about the concern about invisible controls, but I don't see a

good alternative. If a control is invisible, it's not exposed to AT at all.

If a web author wants a keyboard shortcut to be available even when its

associated control is hidden, like a menu item, they should use CSS to

hide the item in such a way that leaves it accessible to AT, such as

by moving it offscreen or changing its z-index.

 

It should be possible to assign accelerated access to e.g. a javascript
function. While this may have a visual representation, in the mainstream use
cases that are likely to power real uptake it quite possible doesn't.

 

 

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.

 

--

Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru <mailto:chaals@yandex-team.ru>  - - - Find more at
http://yandex.com