E-mail List Archives

Re: JavaScript library for display and customization of keyboard shortcuts?


From: Jennifer Sutton
Date: Oct 30, 2015 2:59PM

Rob and all:
Rob, sorry that what I suspect you thought would be such a simple
question isn't.

On 10/30/2015 6:05 AM, Robert Fentress wrote:
> How about two simple key commands to navigate to next/previous named
> landmark regions, rather than specific, separate ones for every landmark?

JS: How would non-screen reader users find out about these? And why
would screen reader users need them since all screen readers I know of
have a way to navigate from landmark to landmark, regardless of name?

> For instance, based on John Foliot's list
> <http://john.foliot.ca/accesskeys-and-reserved-keystroke-combinations/>;, *Alt
> + [* and *Alt + ] *are not taken. These could be mapped to, alternately,
> previous and next landmarks. Or perhaps *Alt + Shift + [* would be better
> for previous landmark--I don't know. They make sense mnemonically, since
> they are "bracketing off" sections of content, and so should be easy to
> remember. Just these two keyboard shortcuts, I think would be very
> helpful. You'd still want them to be customizable, but these defaults
> would be very simple and useful.

JS: For whom and how would they be discoverable, and where would they be
implemented? Only within/across sites at a particular institution? If
so, what happens when end-users don't know the difference and try to use
them more generally?
End users should not have to care, but that's not the way things tend to
ultimately fall out, in my experience.

And if I am reading John's post correctly, cited above, that's from
December of 200(4?) -- I'm rushing. So, I'm not taking time to see if
those combos have since been used by the new screen reader "kids" (not
to mention browsers) on the block, since then.

The overall question I have is what has changed in recent years that
makes this a better idea than it *wasn't* before? I can't see anything
at all, yet. In fact, I'd say things are even more confusing for screen
reader users since ARIA, itself, has added a heckuva lot of new
potential keystrokes, all on its own -- keystrokes that, in my
experience, most normal users have no clue how to use. And that's
because AT vendors and trainers have fallen down on the "training job .
, though they've had years to help with this. Believe you me, when I was
a Window-Eyes user, I used to send messages on this subject rather
regularly, but after a while, you know, one gets a little tired of
repeating oneself.

And should we even get started on how Nuance's Dragon Naturally Speaking
hasn't exposed ARIA much at all, thereby leaving out a lot of value for

As is so often the case, it seems to me that Deborah is on the right
track. So, the next question is, how do we work within the WAI/W3C to
make progress, including with the browser vendors?

What will make the case? I used to believe data would, but I think we've
seen enough, via some quarters, to know that data, apparently
(especially from end-users) isn't taken seriously. And when I say "some
quarters," I don't mean the W3C.