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