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

The ARIA task force agree to put it in the ARIA 1.1 editor's draft for
review. I expect it to show up next week. There will be discussion on
providing help information associated with it.

The HTML working group can decide if it wants to use the ARIA property to
provide greater user control over what keys can be rebound to it. The ARIA
task force does not define browser functionality - that is up to the host
languages and user agents or plugin providers. I co-authored the first
access element draft which was first submitted in 2008. The accesskey
discussion has gone on before that. The HTML working group needs to address
the issue and I agree this does not interfere with that work but given how
long it the accesskey issue was out there and nothing concrete has been
done about it I don't think we should hold up the ARIA train for it.

Thanks for doing all the great work to bring a proposal to the group
Dominic!

Rich


Rich Schwerdtfeger



From:	Dominic Mazzoni <dmazzoni@google.com>
To:	chaals@yandex-team.ru, John Foliot <john.foliot@deque.com>,
            HTML Accessibility Task Force <public-html-a11y@w3.org>
Cc:	"public-pfwg@w3.org" <public-pfwg@w3.org>
Date:	06/11/2015 10:37 AM
Subject:	Re: ACTION-1642: New aria-kbdshortcuts property (for Issue 711)



Charles,

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

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.

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.

- Dominic


On Thu, Jun 11, 2015 at 4:12 AM <chaals@yandex-team.ru> wrote:
  Some thoughts on this:

  10.06.2015, 18:09, "Dominic Mazzoni" <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 - - - Find more at http://yandex.com