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

On Thu, Jun 11, 2015 at 8:14 PM John Foliot <john.foliot@deque.com> wrote:

> For example, keystroke error resolution (in say, SVG with this new ARIA
> attribute). Who's responsible for that? The web author? The browser? The
> AT? The end user? Without explicitly defining the answer to that, you're
> introducing a serious user-problem.
>

I'm sorry for any confusion about this. I've tried to be clear that adding
the aria-kbdshortcuts does NOT actually introduce a key binding, so there's
no need for conflict resolution by the browser.

If anything I've said implies otherwise, I wasn't being clear. All that
happens is that we expose this information to AT. Then AT has more
information that it can choose to present to the user.

Let me give you some examples of existing keyboard shortcuts on the web.

1. Open Gmail and enable keyboard shortcuts. Pressing the 'C' key lets you
compose a new message. It's a shortcut for clicking on the Compose button
on the screen.

2. Open Facebook.com and sign in. From your news feed, press Ctrl+Alt+3 to
open the Friends page, Ctrl+Alt+6 for Settings, and so on.

3. Open Twitter and sign in. Press 'n' to compose a new tweet. It's a
shortcut for the Tweet button near the top.

All of these examples *already exist*. The web authors have already
implemented these keyboard shortcuts using existing JavaScript
functionality (addEventListener for a 'keydown' event, most often).
Millions of users take advantage of these shortcuts today, and they're
already accessible even if you use a screen reader - but they're not very
discoverable and a lot of users don't know how to resolve conflicts using
the passthrough key.

Web authors don't *need* a new way to bind keyboard shortcuts to actions.
They can already do that.

Screen reader users don't *need* a new way to activate these existing
shortcuts. They can already do that. There's already a way to work around
conflicts, too.

All of this adds up to one thing: we need to help the browsers understand
> the problem, and we need to help them solve the problem, but it has to be
> done together, we can't just toss it up in the air and say "here's how
> we're going to communicate something, a thing that is ultimately flawed, to
> AT via ARIA" and then walk away - it's a waste of time and resources IMHO.
>

Well, I am here on behalf of one of "the browsers" - I'm the tech lead and
primary engineer for everything related to accessibility in Chrome. If you
want to help someone understand the problem, you should be talking to me.

I guess I don't see what we have today as "ultimately flawed". I see lots
of popular web apps with keyboard shortcuts, and lots of users who enjoy
these shortcuts. Heck, most apps seem to understand that the same modifier
keys don't exist on all platforms, and that the shortcuts shouldn't
necessarily be the same in every locale.

Should there be a better way to bind keyboard shortcuts to commands? One
where platform differences are taken into account, and users can override
or modify the keys? Sure! In fact, Chrome has had such a feature for a long
time for Chrome apps and extensions:
https://developer.chrome.com/extensions/commands - maybe that would be a
useful model for a future HTML5 feature.

I just don't see that as an argument against *also* having
aria-kbdshortcuts, though. Some authors may still prefer to roll their own
keyboard bindings using JavaScript, just like some authors prefer to roll
their own UI elements from scratch. ARIA means you don't have to give up
accessibility just because you're rolling your own UI.

>> For example, a screen reader could discover that a key
> >> conflicts with a built-in key and *automatically* suggest using the
> >> passthrough key.
>
> So, are you suggesting then that Assistive Technology can explicitly
> modify the functionality of the browser? That (using RFC @119 language)
> "Browsers SHOULD (MUST?) remap keystroke input functionality based upon
> Assistive Technology feedback", as that is sure how I read your statement.
>

Well, keep in mind that all screen readers I'm aware of already intercept
all keyboard events and sometimes dynamically modify them before passing
them to the browser. So it'd be easy for any screen reader to allow the
user to press one key, and have it trigger a different key - if they wanted
to. I'm not necessarily suggesting that they do this - I'm suggesting that
they'd have the *option* to consider ideas like this. What they actually do
is totally up to them.

As a more realistic example, if NVDA encounters a button with a shortcut of
'H', and NVDA knows that 'H' will conflict with one of its own shortcuts,
it could announce 'Ins+F2 H', which is the proper sequence that the user
could press to pass through the 'H' key to the browser. Again, totally up
to them - but it'd be possible then, and it's not possible now.

>> Or, other AT could let the user press one modifier key
> >> and then highlight all commands that can be activated using that
> modifier.
>
> How does that work? Is AT rendering that DOM information somehow, similar
> to how I can call up a list of Headers or Links?


Yes, exactly like this.


> And even if yes, how does the end user then do the remapping if there is
> indeed a conflict or problem? See my SHOULD statement above.
>

Well, the user could press the passthrough key, or the AT could implement a
remapping function since it's already intercepting low-level key events
before the browser is.

>>   - 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.
>
> And how many of those "other ways" are actually accessible? (Honest
> question)


They're not as easy to discover as they should be and a lot of users don't
know how to use a passthrough key or switch modes, but nevertheless all of
the shortcuts I mentioned above work perfectly fine with assistive
technology.