E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 18 (In chronological order)

From: Robert Fentress
Date: Thu, Oct 29 2015 11:58AM
Subject: JavaScript library for display and customization of keyboard shortcuts?
No previous message | Next message →

Hello, all.

I was wondering if anyone was aware of an open source JavaScript library
that provides keyboard-only users the ability to view and change keyboard
shortcuts. It would work something like this:

- After the skip link would be a visible keyboard button.
- When the button receives focus a tooltip appears that says something
like "view/change keyboard shortcuts for page navigation and common
functions"
- Activating the button launches a modal dialog with fields for each
named (aria-label or aria-labelledby) landmark region, plus fields for any
functions the developer has exposed.
- The fields already contain default keyboard shortcuts, but with one of
these fields in focus, pressing a key combination changes the default value
to whatever is pressed.
- Ideally, it would include functions that allowed for persisting these
values across sessions.

How about it? Anybody know of anything like this? Ideally, it would be a
jQuery plugin or AngularJS module, but anything like this would do.

Thanks,
Rob

--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061

From: Brian Lovely
Date: Thu, Oct 29 2015 12:05PM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

There's the Aegis Project: http://access.aol.com/aegis/#goto_datepicker <http://access.aol.com/aegis/#goto_datepicker>; which modifies the jQuery UI library to include accessibility features.

Brian Lovely
= EMAIL ADDRESS REMOVED =



> On Oct 29, 2015, at 1:58 PM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hello, all.
>
> I was wondering if anyone was aware of an open source JavaScript library
> that provides keyboard-only users the ability to view and change keyboard
> shortcuts. It would work something like this:
>
> - After the skip link would be a visible keyboard button.
> - When the button receives focus a tooltip appears that says something
> like "view/change keyboard shortcuts for page navigation and common
> functions"
> - Activating the button launches a modal dialog with fields for each
> named (aria-label or aria-labelledby) landmark region, plus fields for any
> functions the developer has exposed.
> - The fields already contain default keyboard shortcuts, but with one of
> these fields in focus, pressing a key combination changes the default value
> to whatever is pressed.
> - Ideally, it would include functions that allowed for persisting these
> values across sessions.
>
> How about it? Anybody know of anything like this? Ideally, it would be a
> jQuery plugin or AngularJS module, but anything like this would do.
>
> Thanks,
> Rob
>
> --
> Robert Fentress
> Senior Accessibility Solutions Designer
> 540.231.1255
>
> Technology-enhanced Learning & Online Strategies
> Assistive Technologies
> 1180 Torgersen Hall
> 620 Drillfield Drive (0434)
> Blacksburg, Virginia 24061
> > > >

From: Jennifer Sutton
Date: Thu, Oct 29 2015 12:41PM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

But is that project still being maintained? Does it align with the most
current version of jQuery?

I'd recommend checking about that.

And my larger question would be, why is this idea under consideration?

Aren't we getting into the territory of possible keyboard conflicts with
screen reader and browser keyboard controls? And the issues of people
having to learn something new that only applies to a particular site?

I know there's been new thinking about this topic, so I'm hoping those
who've been thinking about it lately will chime in.

But my thinking is -- be sure to remember history, lest we repeat it.

I don't actually have a strong opinion; I'm just suggesting to proceed
with care. Personally, my brain is full of keystroke combinations, so I
never bother to learn any that won't apply somewhere that I need them
regularly.

Best,
Jennifer

From: Brian Lovely
Date: Thu, Oct 29 2015 12:45PM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

Jennifer, isn't the idea under consideration because there are complex behaviors that are commonly needed, so a library would avoid each developer from having to reinvent the wheel, or in this case the calendar picker or what not?

Unfortunately the jQuery UI project has not yet included accessibility in its widgets, although they seem to plan on doing so in the future.


Brian Lovely
= EMAIL ADDRESS REMOVED =



> On Oct 29, 2015, at 2:41 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
>
> But is that project still being maintained? Does it align with the most current version of jQuery?
>
> I'd recommend checking about that.
>
> And my larger question would be, why is this idea under consideration?
>
> Aren't we getting into the territory of possible keyboard conflicts with screen reader and browser keyboard controls? And the issues of people having to learn something new that only applies to a particular site?
>
> I know there's been new thinking about this topic, so I'm hoping those who've been thinking about it lately will chime in.
>
> But my thinking is -- be sure to remember history, lest we repeat it.
>
> I don't actually have a strong opinion; I'm just suggesting to proceed with care. Personally, my brain is full of keystroke combinations, so I never bother to learn any that won't apply somewhere that I need them regularly.
>
> Best,
> Jennifer
>
>
>
>
> > > >

From: Jennifer Sutton
Date: Thu, Oct 29 2015 2:08PM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

I'll try again.

First of all, I'm well aware of what jQuery hasn't done/isn't doing.

Second, I'm well aware that there are a *lot* of these libraries, so any
that are chosen should be considered to see if they're actually being
maintained/still work. I'm not going to bother to list probably a half a
dozen that I could.

But finally, and again trying to repeat my larger point, take care that
you're following standard best practices with these ARIA controls,
rather than inventing *new* keyboard commands that people will never
learn anmd that conflict with keystroke combos already in use.

Study history, so you don't repeat some of the wrong turns that have
been taken in the past. That's all.

And good luck.

Jennifer

From: Brian Lovely
Date: Thu, Oct 29 2015 2:20PM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

Good points, Jennifer. …and sometimes a simple input with a date mask, or an html5 date input provides more universal usability than a fancy calendar widget.


Brian Lovely
= EMAIL ADDRESS REMOVED =



> On Oct 29, 2015, at 4:08 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
>
> I'll try again.
>
> First of all, I'm well aware of what jQuery hasn't done/isn't doing.
>
> Second, I'm well aware that there are a *lot* of these libraries, so any that are chosen should be considered to see if they're actually being maintained/still work. I'm not going to bother to list probably a half a dozen that I could.
>
> But finally, and again trying to repeat my larger point, take care that you're following standard best practices with these ARIA controls, rather than inventing *new* keyboard commands that people will never learn anmd that conflict with keystroke combos already in use.
>
> Study history, so you don't repeat some of the wrong turns that have been taken in the past. That's all.
>
> And good luck.
>
> Jennifer
>
>
> > > >

From: Asa Baylus
Date: Thu, Oct 29 2015 2:30PM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

While it's not a direct answer. I recommend mousetrap.js it's a small library that makes handling keyboard commands trivial, love it.

https://craig.is/killing/mice

But use sensibly :)

Asa

Sent from my iPhone

> On Oct 29, 2015, at 4:20 PM, Brian Lovely < = EMAIL ADDRESS REMOVED = > wrote:
>
> Good points, Jennifer. …and sometimes a simple input with a date mask, or an html5 date input provides more universal usability than a fancy calendar widget.
>
>
> Brian Lovely
> = EMAIL ADDRESS REMOVED =
>
>
>
>> On Oct 29, 2015, at 4:08 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> I'll try again.
>>
>> First of all, I'm well aware of what jQuery hasn't done/isn't doing.
>>
>> Second, I'm well aware that there are a *lot* of these libraries, so any that are chosen should be considered to see if they're actually being maintained/still work. I'm not going to bother to list probably a half a dozen that I could.
>>
>> But finally, and again trying to repeat my larger point, take care that you're following standard best practices with these ARIA controls, rather than inventing *new* keyboard commands that people will never learn anmd that conflict with keystroke combos already in use.
>>
>> Study history, so you don't repeat some of the wrong turns that have been taken in the past. That's all.
>>
>> And good luck.
>>
>> Jennifer
>>
>>
>> >> >> >> >
> > > >

From: Jennifer Sutton
Date: Thu, Oct 29 2015 2:58PM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

Here are some of the libraries and articles/code sets I've bookmarked.
Maybe report back to the list to indicate which one you choose, and why.
Or write up a blog post about pros/cons/currency.
Or probably best of all, contribute to improvements!

I think the one previously suggested is old, so I would not recommend it.
However, I'll be glad to be corrected re. age/maintenance doesn't matter.

Hope this helps folks, but everyone should always check dates!!,
including with respect to what's here.

I'm tossing in a lot of info which goes beyond the original question.
Why? In hopes of preventing duplication.


Jennifer

*** Angular:
You mentioned Angular, so here's a fairly recent video-presentation.
Hopefully, it'll give you pointers if you choose that route and
hopefully efforts begun to fix it will continue:
https://www.youtube.com/watch?v”cyS5V63B0

Here's the developer guide:
https://docs.angularjs.org/guide/accessibility

http://simplyaccessible.com/article/spangular-accessibility/

http://unobfuscated.blogspot.com/search/label/Angular

*** Prefer Bootstrap? Here's a place to start:
http://assets.cms.gov/resources/framework/2.0/Pages/index.html
[not sure if it's being updated as the framework is.]

*** Ember:
https://github.com/trentmwillis/ember-a11y-testing

http://words.steveklabnik.com/emberjs-and-accessibility

https://gist.github.com/jdjkelly/0bddf2e834b6d6bc2174

https://www.linkedin.com/pulse/building-accessible-ember-app-sarah-clatterbuck

*** jQuery:
http://hanshillen.github.io/jqtest/

*** React:
https://github.com/rackt/react-a11y/

*** More generic things that could be added to/built upon:
http://heydonworks.com/practical_aria_examples/#submenus

AccDC:
http://whatsock.com/

And the Technical Style Guide:
https://github.com/accdc/tsg

Here's this code library that Deque's putting together:
https://dequeuniversity.com/library/

Open Ajax Alliance:
http://www.oaa-accessibility.org/examples/
[not sure if there's a library being built/improved.]

Goes way beyond accessibility, but they did open source their
accessibility examples from the book put out a few years ago:
https://www.filamentgroup.com/code/

Gotta make a Web Component? Here's a place to start:
http://www.paciellogroup.com/blog/2014/09/web-components-punch-list/

From: _mallory
Date: Fri, Oct 30 2015 2:54AM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

On Thu, Oct 29, 2015 at 11:41:37AM -0700, Jennifer Sutton wrote:
> And my larger question would be, why is this idea under consideration?
>
> Aren't we getting into the territory of possible keyboard conflicts
> with screen reader and browser keyboard controls? And the issues of
> people having to learn something new that only applies to a
> particular site?

I think such an idea could have merit for:

1. non-SR-using keyboarders (and other keyboard-oriented users via things
like switches, Dragon, whatever) who for example cannot navigate around
by aria-thingies and, at least without any AT, are at the mercy of the
Thousand Tabs of Death

2. and then actually only useful for sites that are large, often-
revisited sites/apps like Gmail. There are javascripted keyboard
shortcuts in Gmail but I still have a lot of trouble moving around
big sections so I dunno what I'm missing, and if this were a library
where the user could set their own keystrokes, what this could allow
is users who've already put time and effort learning another similar
app (let's say a very awesome mail client like mutt) could put their
investment to use on this other site. Again, it would only make sense
on things like news sites, mail apps, maybe stuff like Twitter-- the
kinds of sites that you notice often already have a bunch of javascripted
keyboard shortcuts hidden behind a "?" key already, because people
revisit them. I actually don't see it being useful for a shop, even
if people visit the shop often, it's not such a daily thing as mail or
news.

I don't see anything like this necessarily being useful for SR-users
as they have a nice set of navigation keystrokes available to them,
and as you mention, they have more possibility for conflicts.

What I'd much rather want to see is more basic keyboard stuff
integrated into browsers, such as possibly giving non-SR browser
users the ability to at least navigate via [aria] roles, or by
HTML type (like quick keys for Tables, Forms, etc). But since that's
never going to come, a steaming pile of JS on every large site/app
might be the distant-but-best-shot number 2.

_mallory

From: Robert Fentress
Date: Fri, Oct 30 2015 6:20AM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

_mallory, you have expressed well my intent here. Screen reader users
have a lot of great affordances, but straight-up keyboarders, not so much.
On pages with lots of tab stops, this is a pain. Perhaps the keyboard
shortcuts should be off by default to avoid conflicts with other AT, but I
do think providing customizable hotkeys as an easily-enabled affordance
could provide great value.

Jennifer, thanks for the info. I had seen Marcy Sutton's slides, but
didn't know there was a recording of her presentation, so that is helpful.

Asa, thanks for the link to MouseTrap.

Brian, I wonder if the accessibility enhancements in Aegis have since been
folded into jQueryUI core. I thought they had, but I haven't really
checked. Is there something in there that provides a customizable keyboard
shortcut tool?

Best,
Rob

On Fri, Oct 30, 2015 at 4:54 AM, _mallory < = EMAIL ADDRESS REMOVED = > wrote:

> On Thu, Oct 29, 2015 at 11:41:37AM -0700, Jennifer Sutton wrote:
> > And my larger question would be, why is this idea under consideration?
> >
> > Aren't we getting into the territory of possible keyboard conflicts
> > with screen reader and browser keyboard controls? And the issues of
> > people having to learn something new that only applies to a
> > particular site?
>
> I think such an idea could have merit for:
>
> 1. non-SR-using keyboarders (and other keyboard-oriented users via things
> like switches, Dragon, whatever) who for example cannot navigate around
> by aria-thingies and, at least without any AT, are at the mercy of the
> Thousand Tabs of Death
>
> 2. and then actually only useful for sites that are large, often-
> revisited sites/apps like Gmail. There are javascripted keyboard
> shortcuts in Gmail but I still have a lot of trouble moving around
> big sections so I dunno what I'm missing, and if this were a library
> where the user could set their own keystrokes, what this could allow
> is users who've already put time and effort learning another similar
> app (let's say a very awesome mail client like mutt) could put their
> investment to use on this other site. Again, it would only make sense
> on things like news sites, mail apps, maybe stuff like Twitter-- the
> kinds of sites that you notice often already have a bunch of javascripted
> keyboard shortcuts hidden behind a "?" key already, because people
> revisit them. I actually don't see it being useful for a shop, even
> if people visit the shop often, it's not such a daily thing as mail or
> news.
>
> I don't see anything like this necessarily being useful for SR-users
> as they have a nice set of navigation keystrokes available to them,
> and as you mention, they have more possibility for conflicts.
>
> What I'd much rather want to see is more basic keyboard stuff
> integrated into browsers, such as possibly giving non-SR browser
> users the ability to at least navigate via [aria] roles, or by
> HTML type (like quick keys for Tables, Forms, etc). But since that's
> never going to come, a steaming pile of JS on every large site/app
> might be the distant-but-best-shot number 2.
>
> _mallory
> > > > >



--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061

From: Brian Lovely
Date: Fri, Oct 30 2015 6:35AM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

Rob,

The Aegis project has keyboard shortcuts, but they are baked in. jQuery UI does not appear to fully support accessibility and keyboard shortcuts at this time (assuming date picker to be typical of all widgets). http://wiki.jqueryui.com/w/page/12137778/Datepicker <http://wiki.jqueryui.com/w/page/12137778/Datepicker>;


Brian Lovely
= EMAIL ADDRESS REMOVED =



> On Oct 30, 2015, at 8:20 AM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
>
> _mallory, you have expressed well my intent here. Screen reader users
> have a lot of great affordances, but straight-up keyboarders, not so much.
> On pages with lots of tab stops, this is a pain. Perhaps the keyboard
> shortcuts should be off by default to avoid conflicts with other AT, but I
> do think providing customizable hotkeys as an easily-enabled affordance
> could provide great value.
>
> Jennifer, thanks for the info. I had seen Marcy Sutton's slides, but
> didn't know there was a recording of her presentation, so that is helpful.
>
> Asa, thanks for the link to MouseTrap.
>
> Brian, I wonder if the accessibility enhancements in Aegis have since been
> folded into jQueryUI core. I thought they had, but I haven't really
> checked. Is there something in there that provides a customizable keyboard
> shortcut tool?
>
> Best,
> Rob
>
> On Fri, Oct 30, 2015 at 4:54 AM, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
>
>> On Thu, Oct 29, 2015 at 11:41:37AM -0700, Jennifer Sutton wrote:
>>> And my larger question would be, why is this idea under consideration?
>>>
>>> Aren't we getting into the territory of possible keyboard conflicts
>>> with screen reader and browser keyboard controls? And the issues of
>>> people having to learn something new that only applies to a
>>> particular site?
>>
>> I think such an idea could have merit for:
>>
>> 1. non-SR-using keyboarders (and other keyboard-oriented users via things
>> like switches, Dragon, whatever) who for example cannot navigate around
>> by aria-thingies and, at least without any AT, are at the mercy of the
>> Thousand Tabs of Death
>>
>> 2. and then actually only useful for sites that are large, often-
>> revisited sites/apps like Gmail. There are javascripted keyboard
>> shortcuts in Gmail but I still have a lot of trouble moving around
>> big sections so I dunno what I'm missing, and if this were a library
>> where the user could set their own keystrokes, what this could allow
>> is users who've already put time and effort learning another similar
>> app (let's say a very awesome mail client like mutt) could put their
>> investment to use on this other site. Again, it would only make sense
>> on things like news sites, mail apps, maybe stuff like Twitter-- the
>> kinds of sites that you notice often already have a bunch of javascripted
>> keyboard shortcuts hidden behind a "?" key already, because people
>> revisit them. I actually don't see it being useful for a shop, even
>> if people visit the shop often, it's not such a daily thing as mail or
>> news.
>>
>> I don't see anything like this necessarily being useful for SR-users
>> as they have a nice set of navigation keystrokes available to them,
>> and as you mention, they have more possibility for conflicts.
>>
>> What I'd much rather want to see is more basic keyboard stuff
>> integrated into browsers, such as possibly giving non-SR browser
>> users the ability to at least navigate via [aria] roles, or by
>> HTML type (like quick keys for Tables, Forms, etc). But since that's
>> never going to come, a steaming pile of JS on every large site/app
>> might be the distant-but-best-shot number 2.
>>
>> _mallory
>> >> >> >> >>
>
>
>
> --
> Robert Fentress
> Senior Accessibility Solutions Designer
> 540.231.1255
>
> Technology-enhanced Learning & Online Strategies
> Assistive Technologies
> 1180 Torgersen Hall
> 620 Drillfield Drive (0434)
> Blacksburg, Virginia 24061
> > > >

From: Robert Fentress
Date: Fri, Oct 30 2015 7:05AM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

How about two simple key commands to navigate to next/previous named
landmark regions, rather than specific, separate ones for every landmark?
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.

Best,
Rob

On Fri, Oct 30, 2015 at 8:35 AM, Brian Lovely < = EMAIL ADDRESS REMOVED = > wrote:

> Rob,
>
> The Aegis project has keyboard shortcuts, but they are baked in. jQuery UI
> does not appear to fully support accessibility and keyboard shortcuts at
> this time (assuming date picker to be typical of all widgets).
> http://wiki.jqueryui.com/w/page/12137778/Datepicker <
> http://wiki.jqueryui.com/w/page/12137778/Datepicker>;
>
>
> Brian Lovely
> = EMAIL ADDRESS REMOVED =
>
>
>
> > On Oct 30, 2015, at 8:20 AM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > _mallory, you have expressed well my intent here. Screen reader users
> > have a lot of great affordances, but straight-up keyboarders, not so
> much.
> > On pages with lots of tab stops, this is a pain. Perhaps the keyboard
> > shortcuts should be off by default to avoid conflicts with other AT, but
> I
> > do think providing customizable hotkeys as an easily-enabled affordance
> > could provide great value.
> >
> > Jennifer, thanks for the info. I had seen Marcy Sutton's slides, but
> > didn't know there was a recording of her presentation, so that is
> helpful.
> >
> > Asa, thanks for the link to MouseTrap.
> >
> > Brian, I wonder if the accessibility enhancements in Aegis have since
> been
> > folded into jQueryUI core. I thought they had, but I haven't really
> > checked. Is there something in there that provides a customizable
> keyboard
> > shortcut tool?
> >
> > Best,
> > Rob
> >
> > On Fri, Oct 30, 2015 at 4:54 AM, _mallory < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >> On Thu, Oct 29, 2015 at 11:41:37AM -0700, Jennifer Sutton wrote:
> >>> And my larger question would be, why is this idea under consideration?
> >>>
> >>> Aren't we getting into the territory of possible keyboard conflicts
> >>> with screen reader and browser keyboard controls? And the issues of
> >>> people having to learn something new that only applies to a
> >>> particular site?
> >>
> >> I think such an idea could have merit for:
> >>
> >> 1. non-SR-using keyboarders (and other keyboard-oriented users via
> things
> >> like switches, Dragon, whatever) who for example cannot navigate around
> >> by aria-thingies and, at least without any AT, are at the mercy of the
> >> Thousand Tabs of Death
> >>
> >> 2. and then actually only useful for sites that are large, often-
> >> revisited sites/apps like Gmail. There are javascripted keyboard
> >> shortcuts in Gmail but I still have a lot of trouble moving around
> >> big sections so I dunno what I'm missing, and if this were a library
> >> where the user could set their own keystrokes, what this could allow
> >> is users who've already put time and effort learning another similar
> >> app (let's say a very awesome mail client like mutt) could put their
> >> investment to use on this other site. Again, it would only make sense
> >> on things like news sites, mail apps, maybe stuff like Twitter-- the
> >> kinds of sites that you notice often already have a bunch of
> javascripted
> >> keyboard shortcuts hidden behind a "?" key already, because people
> >> revisit them. I actually don't see it being useful for a shop, even
> >> if people visit the shop often, it's not such a daily thing as mail or
> >> news.
> >>
> >> I don't see anything like this necessarily being useful for SR-users
> >> as they have a nice set of navigation keystrokes available to them,
> >> and as you mention, they have more possibility for conflicts.
> >>
> >> What I'd much rather want to see is more basic keyboard stuff
> >> integrated into browsers, such as possibly giving non-SR browser
> >> users the ability to at least navigate via [aria] roles, or by
> >> HTML type (like quick keys for Tables, Forms, etc). But since that's
> >> never going to come, a steaming pile of JS on every large site/app
> >> might be the distant-but-best-shot number 2.
> >>
> >> _mallory
> >> > >> > >> > >> > >>
> >
> >
> >
> > --
> > Robert Fentress
> > Senior Accessibility Solutions Designer
> > 540.231.1255
> >
> > Technology-enhanced Learning & Online Strategies
> > Assistive Technologies
> > 1180 Torgersen Hall
> > 620 Drillfield Drive (0434)
> > Blacksburg, Virginia 24061
> > > > > > > > >
> > > > >



--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061

From: Bryan Garaventa
Date: Fri, Oct 30 2015 2:08PM
Subject: Re: JavaScript library for display and customization ofkeyboard shortcuts?
← Previous message | Next message →

Hi,
I'm coming into this thread a bit late, is the desire to have customizable key assignments for all widget types? Or is the desire to optionally expose all assigned keystrokes visually? I'm not sure which, and both would have different ways to approach.

I'm not really sure how valuable it would be to have totally customizable hotkeys for all widget types, especially for something as complex as a date picker for example.

E.G
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm
This provides full keyboard support for all date picker functionality using common keystrokes.

Since I've already got all of these included, it wouldn't be difficult to make them customizable, though it would require writing a popup dialog for controlling all of these things, which would in turn require a UI change for every such calendar implementation everywhere where this was included. For it to be scalable, it too would require full programmatic customization as well for support in different languages, and so on, just to give an idea of what would be needed to make this work accessibly everywhere. It is doable, but when this is done for every widget type across the board, it can be quite expensive to implement.

The desire to show key assignments visually is quite a bit easier in contrast, if this was the original question. For example this can be done currently by adding a custom attribute to an element such as data-keystroke="whatever", then use a CSS pseudo element like *[data-keystroke]:focus:before or *[data-keystroke]:focus:after to display this visually when the element receives focus.

There are problems here too though, for example it wouldn't make sense on touch devices, nor does it account for AT keystroke conflicts. Also, going back to the date picker, to get an idea how complex the key assignments are, every focusable date in the date picker supports all of the following keystroke assignments:

Press the Left and Right arrow keys to navigate the row by week day.
Press the Home and End keys to jump to the beginning or end of the current row.
Press the Up and Down arrow keys to navigate between weeks on the same week day.
Press the PageDown and PageUp keys to navigate backwards or forwards by month.
Press Alt+PageDown and Alt+PageUp to navigate backwards or forwards by year.
Press the Enter key to activate the selected date.
Press Escape to close the calendar without making a selection.

Plus you can press Shift+Tab to access the date picker buttons that appear before the focusable dates, or Tab to leave the date picker and close it automatically.

I agree that having keystrokes automatically built into browsers would be convenient, but this is going to be a long ways down the road, especially since browsers cannot currently predict the nature and intent of every widget in existence simply based on markup and styling.

From: deborah.kaplan
Date: Fri, Oct 30 2015 2:32PM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

So I'm wading in here with a response to Bryan's question which less practical, and more philosophical. This is something I've been brewing ideas about for a while:

Bryan asked:

> I'm coming into this thread a bit late, is the desire to have customizable key assignments for all widget types? Or is the desire to optionally expose all assigned keystrokes visually? I'm not sure which, and both would have different ways to approach.

Ultimately, this question is a symptom of how we have fallen down on the job with respect to the way we deal with the web and keyboard bindings ("we" writ large, as the accessibility and web standards and browser communities).

Once the ideal was access keys. They were a web standard, albeit a standard which needed work.The browser implementations also needed work. They were nearly always only advertised to screen reader users. Users outside of the screen reader and accessibility communities might not even have known that they were something that could be used. Rather than fixing the standard and the browser implementations, the modern web community switched over to implementing key bindings in the same way it's fixed everything else for the last several years: JavaScript. Roll your own JavaScript, uniquely implemented per-site, not exposed in any meaningful way to the browser. Proto-polyfills, if you will.

This is a mistake.

This is a flat out, unquestionable roll back of the way the web ought to work.

Even leaving accessibility out of the equation (all of the ways in which site-specific key bindings can help and most definitely hurt web users with disabilities), the environment we have now is chaos. On any given modern site I go to, my keys may have been hijacked for a number of different and site-unique functions. Since they are not exposed to the browser in any semantically meaningful way, I can't install some browser add-on to say "show me all of the key bindings and their human readable names". Since modern designer trends is so minimalist that many sites are opposed to even having a link on the page that says "keyboard shortcut help", it can be difficult or impossible to discover what those keyboard shortcuts are. In addition, it's entirely possible that those keyboard shortcuts collide with built-in shortcuts from my browser and my browser extensions, let alone my AT.

Any end user, without needing to worry about the technical aspects, ought to be able to bring up a list while they are on a webpage that says "right now, these are the current key bindings." Ideally, they should be able to bring up one that lists both the key bindings for the current webpage, and the key bindings that are currently active with the browser and the browser extensions. They should be able to have something that highlights collisions. In a perfect world, and end user would be able to disable key bindings on a case-by-case basis, both at large and for any individual site, eg. something like Stylish, but for keyboard control. They would be able to redefine key bindings.

And again, your average end-user is not going to really care whether those keyboard shortcuts came from the browser, their favorite extension, or the webpage. They just want the site to be able to work.

This would require a change in HTML, and a change at the browsers, but it really does need to happen. Key bindings are only one of the ways in which we have relegated behavior which ought to be standardized so users understand how it works to individual, site-specific, roll your own JavaScript. (Drop-down menus, for goodness sake. If we had CSS-stylable HTML standard drop-down/fly out menus, or modal dialog boxes, implemented in the browsers because these are nigh-universal webpage constructs so shouldn't they really be implemented in the browsers at this point, think how many of us who are accessibility professionals would be able to take up croquet with all of our extra free time.)

</soapbox>

Deborah Kaplan

From: Jennifer Sutton
Date: Fri, Oct 30 2015 2:59PM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

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

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.

Jennifer

From: _mallory
Date: Fri, Oct 30 2015 3:56PM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

On Fri, Oct 30, 2015 at 01:59:34PM -0700, Jennifer Sutton wrote:
> 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?

They wouldn't be for SR users. They'd be for everyone else. But then yes,
landmarks have to be made known, and only to those who care, in some
standard(ish) way.

> The overall question I have is what has changed in recent years that
> makes this a better idea than it *wasn't* before?

What has changed: more and more Big-Name sites have started implementing
their own keyboard shortcuts anyways. Not for SR users, but for
keyboarders (usually under the guise of "power users"). The "?" key
is not universal but it seems common to call up the list.

What has changed: it seems we now have more opportunity as web devs
to make more "semantic" structure in our larger overall page
structures, both with aria landmark roles and with new HTML5 elements
like aside, main, and nav.

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

At least some ARIA should, in my opinion, be exposed to everyone who
needs it. Navigation by landmark would be teh jawsome. Right now,
I can only do this either with an SR running, or I hear there's a
mystical Firefox extension. I believe navigation is core to browsing,
and therefore navigation beyond "tab" and "shift-tab" should be core
as well (vendors have argued against "more bloat" in their cores,
though lots of what they've got in there I'd consider bloat anyway :)

_mallory

From: Jonathan Avila
Date: Sat, Oct 31 2015 3:49PM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | Next message →

> Any end user, without needing to worry about the technical aspects, ought to be able to bring up a list while they are on a webpage that says "right now, these are the current key bindings.

Yes, I think this would also really help speech users. Also, I'd like to take this a step further and say that controls should expose all of their interactions through device independent methods so the user could just pull up a menu of actions for a control and be able to perform those actions without requiring specific keystrokes. This idea may tie into IndieUI -- but why have keystroke specific commands. Consider the benefit to mobile users who may not have a physical or virtual keyboard but want to use speech or a mobile screen reader to change an ARIA slider that today requires pressing up or down arrows. I envision a web where the user would just land on the control and then have some sort of actions list like the rotor on iOS to review the available actions and then select the desired action. This would reduce many interactions down to single taps making custom controls available to users of switch control, prosthetics, and screen readers users who don't want to carry around a keyboard, etc.

Jonathan

--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =

703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Chaals McCathie Nevile
Date: Sun, Nov 01 2015 4:24AM
Subject: Re: JavaScript library for display and customization of keyboard shortcuts?
← Previous message | No next message

TL;DR: Deborah is right and
http://chaals.github.io/accesskey/index.src.html is being developed to try
and fix the underlying problem. That might only take a few years...

On Sat, 31 Oct 2015 05:32:10 +0900, < = EMAIL ADDRESS REMOVED = > wrote:

> So I'm wading in here with a response to Bryan's question which less
> practical, and more philosophical. This is something I've been brewing
> ideas about for a while:

I've been thinking about (and discussing with John Foliot) this issue for
more than a decade.

I don't think your suggestion is philosophical, it is intensely practical.

Most of the pieces point to *fixing* accesskey. Browser implementations
have gone from horrible to not very good, which is a step in the right
direction. But there is a bit more to do before we get to where you want
to be:

1. Browsers need to provide discoverability.

This is a bug with existing implementations. The spec should clarify the
requirement.

The nice thing about using accesskey attributes is that querying the DOM
is easy (outside the Edge browser, where we would need to ask MS for
special magic ;( ). HTML now allows multiple suggestions to be given for
the accesskey attribute, but asks the user agent to provide
.accessKeyLabel in the DOM, identifying the shortcut used.

This means we *can* make the extensions that say "what is already bound" -
although they are not yet easy, at least we are not fighting the problem
of trying to interpret arbitrary javascript.

The browser needs to alert the user through the interface that there *are*
shortcuts available, and what they are. Opera for Presto got the second
part right with its accesskey menu - and to the extent that accesskey was
the tool for providing shortcuts, I made an extension to show there are
accesskeys. It is very very simple to do:

if(document.querySelector('*[accesskey]'))
hasAccessKeys = true;
else hasAccessKeys = false;

2. User agents need to handle *actual* key assignment, allowing for
conflict management

I guess this is a lot of what Robert was asking for in his original
request.

Instead of looking for the mythical shortcut - or gesture on touch
devices, or voice command, or whatever - that hasn't been taken up, in
reality we only need to provide shortcuts for a given user that don't
conflict with *their* world. Allowing the user agent to decide, presumably
in concert with the user for whom they are an agent, what to use, is
relatively simple. I built an extension for the old Opera which did this.
The documentation died when Opera killed myopera.com but the code is on
bitbucket still: https://bitbucket.org/chaals/excesskey/src

This means the value authors give the accesskey attribute is a
*suggestion*, and the browser can assign something else. Which is why the
browser has to be responsible for discoverability instead of the author -
besides the fact that browsers know how they work, whereas asking millions
of authors to write documentation for that, which is what we do now with
pages describing the accesskeys, is stupid. Too many people doing a lot of
repetitive work with a high risk of getting it wrong.

3. Browsers should be able to use accesskey to assign a voice command or
gesture

This follows on from 1, 2, and reality.

The accesskey attribute is basically a request for a shortcut method. On
some platforms that means a keyboard, on others it means something else.
Javascript gives keyboard users real shortcuts, and in certain cases might
do so for gestures although writing that is a nightmare. Shift-ctrl-alt-語
might be a legitimate accessKeyLabel value but isn't a *short* cut.

For voice commands, a word should be a valid entry in the list of values
accesskey can take. For touch devices, a gesture.

4. There *should* be a continuous use mode

For some applications such as games, the author should be able to
*request* a mode where shortcut keys are really simple to use. Right now
there is role="application" that does this for screenreaders, but badly.
Having this functionality, with the user in control when needed, would be
pretty useful for many people.

Some of this stuff is documented already as part of a proposal that I am
preparing for HTML. You can see it at
http://chaals.github.io/accesskey/index.src.html and raise issues on
github "pretty easily" at http://github.com/chaals/accesskey/issues but my
plan is to edit out the things that are clearly wrong, and then propose it
for the Web Incubator Community Group at W3C, as a proposal for the next
version of HTML.

> Bryan asked:
>
>> I'm coming into this thread a bit late, is the desire to have
>> customizable key assignments for all widget types? Or is the desire to
>> optionally expose all assigned keystrokes visually? I'm not sure which,
>> and both would have different ways to approach.
>
> Ultimately, this question is a symptom of how we have fallen down on
> the job with respect to the way we deal with the web and keyboard
> bindings ("we" writ large, as the accessibility and web standards and
> browser communities).
>
> Once the ideal was access keys. They were a web standard, albeit a
> standard which needed work.The browser implementations also needed work.
> They were nearly always only advertised to screen reader users. Users
> outside of the screen reader and accessibility communities might not
> even have known that they were something that could be used. Rather
> than fixing the standard and the browser implementations, the modern web
> community switched over to implementing key bindings in the same way
> it's fixed everything else for the last several years: JavaScript. Roll
> your own JavaScript, uniquely implemented per-site, not exposed in any
> meaningful way to the browser. Proto-polyfills, if you will.
>
> This is a mistake.
>
> This is a flat out, unquestionable roll back of the way the web ought to
> work.
>
> Even leaving accessibility out of the equation (all of the ways in which
> site-specific key bindings can help and most definitely hurt web users
> with disabilities), the environment we have now is chaos. On any given
> modern site I go to, my keys may have been hijacked for a number of
> different and site-unique functions. Since they are not exposed to the
> browser in any semantically meaningful way, I can't install some browser
> add-on to say "show me all of the key bindings and their human readable
> names". Since modern designer trends is so minimalist that many sites
> are opposed to even having a link on the page that says "keyboard
> shortcut help", it can be difficult or impossible to discover what those
> keyboard shortcuts are. In addition, it's entirely possible that those
> keyboard shortcuts collide with built-in shortcuts from my browser and
> my browser extensions, let alone my AT.
>
> Any end user, without needing to worry about the technical aspects,
> ought to be able to bring up a list while they are on a webpage that
> says "right now, these are the current key bindings." Ideally, they
> should be able to bring up one that lists both the key bindings for the
> current webpage, and the key bindings that are currently active with the
> browser and the browser extensions. They should be able to have
> something that highlights collisions. In a perfect world, and end user
> would be able to disable key bindings on a case-by-case basis, both at
> large and for any individual site, eg. something like Stylish, but for
> keyboard control. They would be able to redefine key bindings.
>
> And again, your average end-user is not going to really care whether
> those keyboard shortcuts came from the browser, their favorite
> extension, or the webpage. They just want the site to be able to work.
>
> This would require a change in HTML, and a change at the browsers, but
> it really does need to happen. Key bindings are only one of the ways in
> which we have relegated behavior which ought to be standardized so users
> understand how it works to individual, site-specific, roll your own
> JavaScript. (Drop-down menus, for goodness sake. If we had CSS-stylable
> HTML standard drop-down/fly out menus, or modal dialog boxes,
> implemented in the browsers because these are nigh-universal webpage
> constructs so shouldn't they really be implemented in the browsers at
> this point, think how many of us who are accessibility professionals
> would be able to take up croquet with all of our extra free time.)
>
> </soapbox>
>
> Deborah Kaplan
> > > > --
Charles McCathie Nevile - web standards - CTO Office, Yandex
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com