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

Hi Dominic,

so the equation goes

„Keyboard Shortcuts” = Hotkeys (aria-hotkey (such as CTRL+S, your button example)) + Access Keys (accesskey (old HTML property))

Right? Same camp now?


-      Stefan


From: Dominic Mazzoni [mailto:dmazzoni@google.com]
Sent: Mittwoch, 10. Juni 2015 18:09
To: John Foliot; HTML Accessibility Task Force
Cc: public-pfwg@w3.org
Subject: Re: FW: ACTION-1642: New aria-kbdshortcuts property (for Issue 711)

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.


On Wed, Jun 10, 2015 at 9:03 AM John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>> wrote:
Specifically copying the HTML-a11y TF, who may not always see PF-bound
emails.

Related to the @accesskey discussion underway. Coordination will be critical
here, as the same open questions exist for both efforts (discoverability,
alternate mapping options, etc.) .

JF


> -----Original Message-----
> From: Joseph Scheuhammer [mailto:clown@alum.mit.edu<mailto:clown@alum.mit.edu>]
> Sent: Wednesday, June 10, 2015 8:24 AM
> To: public-pfwg@w3.org<mailto:public-pfwg@w3.org>
> Subject: Re: ACTION-1642: New aria-kbdshortcuts property (for Issue 711)
>
> > Please review this proposal based on a proposal from Dominic Mazzoni
> > for the Thursday ARIA call. We may come up for another name for this
> > ... like aria-shortcuts, aria-key, or aria-keygboardshortcuts:
>
> Some thoughts and questions:
>
> 1. Name: I suggest aria-hotkey.
>
> 2. Discoverability -- how do users find out what the key combinations are?
>
> 3.  The spec text says that if the control is invisible, then its keyboard
shortcut
> does not trigger the action.  This will exclude menu items within a menu
that is
> not popped open.  That is different from how menuitems work on the
desktop;
> for example, cmd+s on a Mac activates the "File" menu's "Save" menuitem
even
> when the menu and menuitem are invisible.
>
> 4. How do aria-kbdshortcuts apply in the case of touch interfaces?
>
> 5.  How does this differ from accesskey [1], i.e. what problem does it
solve that
> accesskey doesn't?  I think part of the answer is that aria-kbdshortcuts
includes
> the modifier keys, whereas acceskey doesn't, which is clearer.
>
> 6.  How does aria-kbdshortcuts interact with accesskey?  Which one wins if
an
> element has both?
>
> [1]
> http://www.w3.org/html/wg/drafts/html/master/editing.html#assigned-

> access-key
>
> --
> ;;;;joseph.
>
> 'Array(16).join("wat" - 1) + " Batman!"'
>             - G. Bernhardt -
>