E-mail List Archives

Search E-mail List Archives for

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

From: Bruno, Michele
Date: Mon, Apr 18 2016 11:54AM
Subject: keyboard accessibility (WCAG) vs keyboard shortcuts?
No previous message | Next message →

Hello Fellow Advocates,
I have had multiple recent requests asking about "keyboard shortcuts for accessibility" we have in our web applications. I searched WCAG again just in case I missed something and only see reference to keyboard accessibility; users should be able to navigate/interact with web pages solely with standard keyboard navigation. I get this. Other than WebAIM reference: Keyboard shortcuts are a standard accessibility feature of most operating systems. Beyond this, and/or possible mis-understanding of keyboard (accessibility) vs keyboard shortcuts (OS standards), is there something more to be aware of?
Thank you in advance.

From: Caitlin Geier
Date: Mon, Apr 18 2016 12:11PM
Subject: Re: keyboard accessibility (WCAG) vs keyboard shortcuts?
← Previous message | Next message →

Could the requests be talking about bypass block mechanisms, like skip
links? WCAG 2.0 Success Criteria 2.4.1
<https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-skip.html>
requires
that there be at least one way to skip content that repeats on multiple
pages (like the header or the main menu) using a keyboard and/or assistive
technology. One of the most common ways is to include a skip link which
allows the user to skip to the main content of the page.

Webaim also has a good article about skip links and alternative navigation
which goes into more detail on techniques -
http://webaim.org/techniques/skipnav/

On Mon, Apr 18, 2016 at 1:54 PM, Bruno, Michele < = EMAIL ADDRESS REMOVED =
> wrote:

>
> Hello Fellow Advocates,
> I have had multiple recent requests asking about "keyboard shortcuts for
> accessibility" we have in our web applications. I searched WCAG again just
> in case I missed something and only see reference to keyboard
> accessibility; users should be able to navigate/interact with web pages
> solely with standard keyboard navigation. I get this. Other than WebAIM
> reference: Keyboard shortcuts are a standard accessibility feature of most
> operating systems. Beyond this, and/or possible mis-understanding of
> keyboard (accessibility) vs keyboard shortcuts (OS standards), is there
> something more to be aware of?
> Thank you in advance.
> > > > >



--
Caitlin Geier
User Experience Designer
= EMAIL ADDRESS REMOVED =

From: deborah.kaplan
Date: Mon, Apr 18 2016 12:12PM
Subject: Re: keyboard accessibility (WCAG) vs keyboard shortcuts?
← Previous message | Next message →

You should always be suspicious of somebody saying site-specific keyboard shortcuts are for accessibility. Keyboard shortcuts very rarely provide accessibility, and frequently conflict with the existing keyboard shortcuts of the browsers, assistive tech, and accessibility add-ons used by people with disabilities.

A site, in order to conform to WCAG, must make sure all controls that are accessible via mouse are also accessible via keyboard. This will happen naturally in the keyboard-accessible browsers if the techniques are followd (<https://www.w3.org/TR/WCAG20-TECHS/Overview.html>). Essentially, almost all native HTML5 elements will have the default accessibility (assuming best practice is followed for those elements), and then use WAI-ARIA and JavaScript as necessary to add keyboard accessibility where other practices mean it's not natively there.

Site-specific keyboard shortcuts (e.g. pressing on the right arrow takes you to the next page, or pressing on the question mark brings up a help page) have a high probability of clashing with existing assistive tech, and if you add them you should make sure:

1. there is a setting to turn them off and
2. there is a clearly labeled help page telling users how to find them and how to disable them

Outside of the kind of pure webapp which works more like a desktop app than a web page (eg. google sheets) or sites people use constantly (eg. Facebook), users are unlikely to remember keyboard controls that are different from their regular web browsing experience anyway.


Also see: https://github.com/chaals/accesskey

"This is a draft alternative specification for a proposed replacement for the accesskey section in HTML. It has now been proposed to the Web Incubator Community Group as an item for further development, so discussion can be fragmented between filing issues here, or talking about it there.

The rationale is that interaction for web applications at the moment commonly introduces unexpected changes to the way a user agent behaves, hijacking functions that users rely on. This is an inevitable result of using javascript to define the interaction. Without a standard mechanism for knowing what specific interaction behaviours an author has requested, nor for authors to request a behaviour and allow the user agent to remap it, there is no way to do conflict resolution.

The purpose of working on the accesskey attribute is in part to help resolve this situation: As a markup attribute reflected in the DOM, accesskey offers naive authors a simple way to extend interaction without the need for them to write script, while providing a framework which is exposed to script authors"


Deborah Kaplan

On Mon, 18 Apr 2016, Bruno, Michele wrote:

>
> Hello Fellow Advocates,
> I have had multiple recent requests asking about "keyboard shortcuts for accessibility" we have in our web applications. I searched WCAG again just in case I missed something and only see reference to keyboard accessibility; users should be able to navigate/interact with web pages solely with standard keyboard navigation. I get this. Other than WebAIM reference: Keyboard shortcuts are a standard accessibility feature of most operating systems. Beyond this, and/or possible mis-understanding of keyboard (accessibility) vs keyboard shortcuts (OS standards), is there something more to be aware of?
> Thank you in advance.
> > > > --

From: Jonathan Cohn
Date: Mon, Apr 18 2016 12:19PM
Subject: Re: keyboard accessibility (WCAG) vs keyboard shortcuts?
← Previous message | Next message →

JAWS 16 and 17 started providing this type of functionality with Twitter
and a couple other sites. I believe I heard Facebook call it Web
Application Accessible Keys. In JAWS you can get a list of the keys that
the web page has overridden default behavior and alsso get shift-1
functionality to speak explanations of the key.
Best wishes,

Jonathan Cohn


On 18 April 2016 at 13:54, Bruno, Michele < = EMAIL ADDRESS REMOVED = >
wrote:

>
> Hello Fellow Advocates,
> I have had multiple recent requests asking about "keyboard shortcuts for
> accessibility" we have in our web applications. I searched WCAG again just
> in case I missed something and only see reference to keyboard
> accessibility; users should be able to navigate/interact with web pages
> solely with standard keyboard navigation. I get this. Other than WebAIM
> reference: Keyboard shortcuts are a standard accessibility feature of most
> operating systems. Beyond this, and/or possible mis-understanding of
> keyboard (accessibility) vs keyboard shortcuts (OS standards), is there
> something more to be aware of?
> Thank you in advance.
> > > > >

From: Lucy Greco
Date: Mon, Apr 18 2016 12:37PM
Subject: Re: keyboard accessibility (WCAG) vs keyboard shortcuts?
← Previous message | Next message →

intresting i wonder why jaws added twitter key commands the ones that
twitter uses work grate so what whould these key commands be and do that
twitter is not already doing

Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces


On Mon, Apr 18, 2016 at 11:19 AM, Jonathan Cohn < = EMAIL ADDRESS REMOVED = >
wrote:

> JAWS 16 and 17 started providing this type of functionality with Twitter
> and a couple other sites. I believe I heard Facebook call it Web
> Application Accessible Keys. In JAWS you can get a list of the keys that
> the web page has overridden default behavior and alsso get shift-1
> functionality to speak explanations of the key.
> Best wishes,
>
> Jonathan Cohn
>
>
> On 18 April 2016 at 13:54, Bruno, Michele < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> >
> > Hello Fellow Advocates,
> > I have had multiple recent requests asking about "keyboard shortcuts for
> > accessibility" we have in our web applications. I searched WCAG again
> just
> > in case I missed something and only see reference to keyboard
> > accessibility; users should be able to navigate/interact with web pages
> > solely with standard keyboard navigation. I get this. Other than WebAIM
> > reference: Keyboard shortcuts are a standard accessibility feature of
> most
> > operating systems. Beyond this, and/or possible mis-understanding of
> > keyboard (accessibility) vs keyboard shortcuts (OS standards), is there
> > something more to be aware of?
> > Thank you in advance.
> > > > > > > > > >
> > > > >

From: Marc Solomon
Date: Mon, Apr 18 2016 1:38PM
Subject: Re: keyboard accessibility (WCAG) vs keyboard shortcuts?
← Previous message | Next message →

To clarify John's comments, at least two Windows screen readers that I am aware of have created a special mode that allows certain keys to be ignored by the screen reader while Browse mode/virtual cursor is enabled. This allows the user to have the best of both worlds. They can use commands available in the screen reader for virtual navigation (e.g. move by line with Up and Down Arrow, headings with H, buttons with B, links with L) and at the same time use the web applications keyboard shortcuts without conflicts. I recorded a webinar a few months back with Matt King from Facebook where we discussed our collaboration and demonstrated this functionality.

Regards,
Marc

From: Sean Murphy
Date: Tue, Apr 19 2016 12:43AM
Subject: Re: keyboard accessibility (WCAG) vs keyboard shortcuts?
← Previous message | Next message →

I am thinking you are asking about keystrokes that are built into the web page which are not related to the standard keystrokes for browsers. For example, safari o'rielly provides the user the ability to jump to the next or previous section by using a keyboard shortcut. Depending on the browser determines what keystrokes you have to use as IE and Firefox uses slightly different keys when this methodology is used.

Personally I don't think this is best practise based upon what everyone else has stated and from my personal usage of page via the keyboard. Other users like it because they feel it increases their productivity on a tool.

Jaws included the options because of keyboard conflicts. If WCAG 2.0 doesn't include this, then should it?

Sean
> On 19 Apr 2016, at 5:38 am, Marc Solomon < = EMAIL ADDRESS REMOVED = > wrote:
>
> To clarify John's comments, at least two Windows screen readers that I am aware of have created a special mode that allows certain keys to be ignored by the screen reader while Browse mode/virtual cursor is enabled. This allows the user to have the best of both worlds. They can use commands available in the screen reader for virtual navigation (e.g. move by line with Up and Down Arrow, headings with H, buttons with B, links with L) and at the same time use the web applications keyboard shortcuts without conflicts. I recorded a webinar a few months back with Matt King from Facebook where we discussed our collaboration and demonstrated this functionality.
>
> Regards,
> Marc
>
>

From: Joy Relton
Date: Tue, Apr 19 2016 3:20PM
Subject: Re: keyboard accessibility (WCAG) vs keyboard shortcuts?
← Previous message | Next message →

The first example of a "keyboard shortcut" that I can think of, is when I was auditing a web-based application which had various grids on the page between which the user needed to move. Since the labeling and keyboard navigation was difficult the developer devised shortcut keys which would bring the user to each of the control locations. For example, Alt+l would take the user to the close button. Developing Shortcut keys opens up a big can of worms because you have to avoid conflicts with known shortcut keys for operating systems and assistive technology. If the legacy app simply isn't going to allow the user to tab through the page, creating shortcut keys does provide keyboard access. I am fairly certain this is what they are talking about. For example, many applications often have shortcut keys to allow quick navigation, hence the word "shortcut" to various functions.

From: Chaals McCathie Nevile
Date: Tue, Apr 19 2016 3:50PM
Subject: Re: keyboard accessibility (WCAG) vs keyboard shortcuts?
← Previous message | Next message →

On Mon, 18 Apr 2016 20:37:25 +0200, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:

> intresting i wonder why jaws added twitter key commands the ones that
> twitter uses work grate so what whould these key commands be and do that
> twitter is not already doing

The problem with twitter keys is that they override things which many
users expect from their browser, so suddenly something unexpected happens
when using a shortcut.

This is an inherent problem with using javascript to implement shortcuts -
as Deborah pointed out elsewhere in the thread.

And a reason why the only kinds of solution I can see working are based on
accesskey - or something that can work the same with a different name,
which seems like a silly idea to me.

cheers

> Lucia Greco
> Web Accessibility Evangelist
> IST - Architecture, Platforms, and Integration
> University of California, Berkeley
> (510) 289-6008 skype: lucia1-greco
> http://webaccess.berkeley.edu
> Follow me on twitter @accessaces
>
>
> On Mon, Apr 18, 2016 at 11:19 AM, Jonathan Cohn < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> JAWS 16 and 17 started providing this type of functionality with Twitter
>> and a couple other sites. I believe I heard Facebook call it Web
>> Application Accessible Keys. In JAWS you can get a list of the keys that
>> the web page has overridden default behavior and alsso get shift-1
>> functionality to speak explanations of the key.
>> Best wishes,
>>
>> Jonathan Cohn
>>
>>
>> On 18 April 2016 at 13:54, Bruno, Michele < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> >
>> > Hello Fellow Advocates,
>> > I have had multiple recent requests asking about "keyboard shortcuts
>> for
>> > accessibility" we have in our web applications. I searched WCAG again
>> just
>> > in case I missed something and only see reference to keyboard
>> > accessibility; users should be able to navigate/interact with web
>> pages
>> > solely with standard keyboard navigation. I get this. Other than
>> WebAIM
>> > reference: Keyboard shortcuts are a standard accessibility feature of
>> most
>> > operating systems. Beyond this, and/or possible mis-understanding of
>> > keyboard (accessibility) vs keyboard shortcuts (OS standards), is
>> there
>> > something more to be aware of?
>> > Thank you in advance.
>> > >> > >> > >> > >> >
>> >> >> >> >>
> > > > --
Charles McCathie Nevile - web standards - CTO Office, Yandex
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com

From: _mallory
Date: Wed, Apr 20 2016 5:27AM
Subject: Re: keyboard accessibility (WCAG) vs keyboard shortcuts?
← Previous message | Next message →

On Tue, Apr 19, 2016 at 11:50:16PM +0200, Chaals McCathie Nevile wrote:
> On Mon, 18 Apr 2016 20:37:25 +0200, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:
>
> >intresting i wonder why jaws added twitter key commands the ones that
> >twitter uses work grate so what whould these key commands be and do that
> >twitter is not already doing
>
> The problem with twitter keys is that they override things which
> many users expect from their browser, so suddenly something
> unexpected happens when using a shortcut.

_m: yeah the j/k keys are supposed to move your focus between tweets
but then in Orca if I'm in browse mode the k is "next link."

I like the idea of being able to easily switch between your SR
commands and page commands, esp since a lot of these pages with
keyboard shortcuts work better with their shortcuts than if you're
navigating by focusables or element type.

The j/k keys are pretty popular, probably because of applications
like mutt and vim using them: besides Twitter, j and k work in
the search results of DuckDuckGo and other list-y pages.

_mallory

From: Chaals McCathie Nevile
Date: Wed, Apr 20 2016 7:31AM
Subject: Re: keyboard accessibility (WCAG) vs keyboard shortcuts?
← Previous message | Next message →

On Wed, 20 Apr 2016 13:27:50 +0200, _mallory < = EMAIL ADDRESS REMOVED = >
wrote:

> On Tue, Apr 19, 2016 at 11:50:16PM +0200, Chaals McCathie Nevile wrote:
>> On Mon, 18 Apr 2016 20:37:25 +0200, Lucy Greco < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> >intresting i wonder why jaws added twitter key commands the ones that
>> >twitter uses work grate so what whould these key commands be and do
>> that
>> >twitter is not already doing
>>
>> The problem with twitter keys is that they override things which
>> many users expect from their browser, so suddenly something
>> unexpected happens when using a shortcut.
>
> _m: yeah the j/k keys are supposed to move your focus between tweets
> but then in Orca if I'm in browse mode the k is "next link."

Right.

> I like the idea of being able to easily switch between your SR
> commands and page commands, esp since a lot of these pages with
> keyboard shortcuts work better with their shortcuts than if you're
> navigating by focusables or element type.

Yes - applications generally have a good idea about what will work if you
live in that application, which is why any solution needs to allow them to
suggest a set of shortcuts.

But enable the user to change them. If you live on a cyrillic keyboard, it
would be good to be able to change the suggestions to match things that
are useful to you, without each shortcut being a long dance of switching
keyboard, activating the shortcut key, remembering that it breaks
something you normally use for something else, and then switching back.

> The j/k keys are pretty popular, probably because of applications
> like mutt and vim using them: besides Twitter, j and k work in
> the search results of DuckDuckGo and other list-y pages.

They're vi keys, and were common in games controls in the 1980s, because
they're the central home keys for the right hand when touch-typing on a
qwerty keyboard... cue urban legend about horses' backsides and train
guages.

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com

From: Sean Murphy
Date: Thu, Apr 21 2016 8:28PM
Subject: Re: keyboard accessibility (WCAG) vs keyboard shortcuts?
← Previous message | Next message →

All,

Providing shortcut keys in a pure Application mode Web site, would this be regarded as a breach to WCAG 2.0 (AA) or best practise? The web site being reviewed everything is in the application mode when using a screen reader.

Sean

> On 20 Apr 2016, at 11:31 PM, Chaals McCathie Nevile < = EMAIL ADDRESS REMOVED = > wrote:
>
> On Wed, 20 Apr 2016 13:27:50 +0200, _mallory < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >> wrote:
>
>> On Tue, Apr 19, 2016 at 11:50:16PM +0200, Chaals McCathie Nevile wrote:
>>> On Mon, 18 Apr 2016 20:37:25 +0200, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> >intresting i wonder why jaws added twitter key commands the ones that
>>> >twitter uses work grate so what whould these key commands be and do that
>>> >twitter is not already doing
>>>
>>> The problem with twitter keys is that they override things which
>>> many users expect from their browser, so suddenly something
>>> unexpected happens when using a shortcut.
>>
>> _m: yeah the j/k keys are supposed to move your focus between tweets
>> but then in Orca if I'm in browse mode the k is "next link."
>
> Right.
>
>> I like the idea of being able to easily switch between your SR
>> commands and page commands, esp since a lot of these pages with
>> keyboard shortcuts work better with their shortcuts than if you're
>> navigating by focusables or element type.
>
> Yes - applications generally have a good idea about what will work if you live in that application, which is why any solution needs to allow them to suggest a set of shortcuts.
>
> But enable the user to change them. If you live on a cyrillic keyboard, it would be good to be able to change the suggestions to match things that are useful to you, without each shortcut being a long dance of switching keyboard, activating the shortcut key, remembering that it breaks something you normally use for something else, and then switching back.
>
>> The j/k keys are pretty popular, probably because of applications
>> like mutt and vim using them: besides Twitter, j and k work in
>> the search results of DuckDuckGo and other list-y pages.
>
> They're vi keys, and were common in games controls in the 1980s, because they're the central home keys for the right hand when touch-typing on a qwerty keyboard... cue urban legend about horses' backsides and train guages.
>
> cheers
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = > - - - Find more at http://yandex.com <http://yandex.com/>;
> > > >

From: Chaals McCathie Nevile
Date: Sat, Apr 23 2016 10:34AM
Subject: Re: keyboard accessibility (WCAG) vs keyboard shortcuts?
← Previous message | No next message

On Fri, 22 Apr 2016 03:28:42 +0100, Sean Murphy < = EMAIL ADDRESS REMOVED = >
wrote:

> All,
>
> Providing shortcut keys in a pure Application mode Web site, would this
> be regarded as a breach to WCAG 2.0 (AA) or best practise? The web site
> being reviewed everything is in the application mode when using a screen
> reader.

The question is not what happens for screen readers, but for all the other
users.

If there is a case for keyboard shortcuts, there are a couple of things
you need to do in practice:

1. Ensure the user can find out what they are.
2. Make sure they work for all users
3. Ideally, provide a way to ensure that the shortcuts don't over-ride
normal functionality users rely on, and if the shortcuts are still
necessary, allow the user to assign them to somethng that is helpful to
them.

If you put everything into application mode you're running a risk of
seriously going wrong on number 3 - do you really need to do that?

cheers

Chaals

> Sean
>
>> On 20 Apr 2016, at 11:31 PM, Chaals McCathie Nevile
>> < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> On Wed, 20 Apr 2016 13:27:50 +0200, _mallory < = EMAIL ADDRESS REMOVED =
>> <mailto: = EMAIL ADDRESS REMOVED = >> wrote:
>>
>>> On Tue, Apr 19, 2016 at 11:50:16PM +0200, Chaals McCathie Nevile wrote:
>>>> On Mon, 18 Apr 2016 20:37:25 +0200, Lucy Greco < = EMAIL ADDRESS REMOVED = >
>>>> wrote:
>>>>
>>>> >intresting i wonder why jaws added twitter key commands the ones
>>>> that
>>>> >twitter uses work grate so what whould these key commands be and do
>>>> that
>>>> >twitter is not already doing
>>>>
>>>> The problem with twitter keys is that they override things which
>>>> many users expect from their browser, so suddenly something
>>>> unexpected happens when using a shortcut.
>>>
>>> _m: yeah the j/k keys are supposed to move your focus between tweets
>>> but then in Orca if I'm in browse mode the k is "next link."
>>
>> Right.
>>
>>> I like the idea of being able to easily switch between your SR
>>> commands and page commands, esp since a lot of these pages with
>>> keyboard shortcuts work better with their shortcuts than if you're
>>> navigating by focusables or element type.
>>
>> Yes - applications generally have a good idea about what will work if
>> you live in that application, which is why any solution needs to allow
>> them to suggest a set of shortcuts.
>>
>> But enable the user to change them. If you live on a cyrillic keyboard,
>> it would be good to be able to change the suggestions to match things
>> that are useful to you, without each shortcut being a long dance of
>> switching keyboard, activating the shortcut key, remembering that it
>> breaks something you normally use for something else, and then
>> switching back.
>>
>>> The j/k keys are pretty popular, probably because of applications
>>> like mutt and vim using them: besides Twitter, j and k work in
>>> the search results of DuckDuckGo and other list-y pages.
>>
>> They're vi keys, and were common in games controls in the 1980s,
>> because they're the central home keys for the right hand when
>> touch-typing on a qwerty keyboard... cue urban legend about horses'
>> backsides and train guages.
>>
>> cheers
>>
>> --
>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>> = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = > - - - Find more at
>> http://yandex.com <http://yandex.com/>;
>> >> >> <http://list.webaim.org/>;
>> >> <http://webaim.org/discussion/archives>;
>> >> <mailto: = EMAIL ADDRESS REMOVED = >
> > > > --
Charles McCathie Nevile - web standards - CTO Office, Yandex
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com