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.

š

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

š

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

š

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

š

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

š

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

š

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

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

š

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

š