E-mail List Archives

Search E-mail List Archives for

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

From: Kakarla Meharoon
Date: Mon, Mar 26 2018 10:28AM
Subject: Access Keys
No previous message | Next message →

*Is it access keys are really necessary to implement?*

From: glen walker
Date: Mon, Mar 26 2018 11:10AM
Subject: Re: Access Keys
← Previous message | Next message →

Do you need to implement the accesskey attribute in order to be
accessible? No.

However, I really like it when there are access keys for common
functionality. The problem is that they're not normally discoverable. For
example, on wikipedia, the search field that's in the upper right (when
you're viewing a wiki page), has an accesskey='F', but you'd never know it
unless you look at the code. It lets me quickly get to that field no
matter where I am on the page, which I love, but again, you probably don't
know it's there.


On Mon, Mar 26, 2018 at 10:28 AM, Kakarla Meharoon <
= EMAIL ADDRESS REMOVED = > wrote:

> *Is it access keys are really necessary to implement?*
> > > > >

From: JP Jamous
Date: Mon, Mar 26 2018 12:31PM
Subject: Re: Access Keys
← Previous message | Next message →

No they are not. Do they make it easier to jump around a page? Absolutely.



--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Kakarla Meharoon
Sent: Monday, March 26, 2018 11:29 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Access Keys

*Is it access keys are really necessary to implement?*

From: Birkir R. Gunnarsson
Date: Mon, Mar 26 2018 12:36PM
Subject: Re: Access Keys
← Previous message | Next message →

Well put.
ON a retail website or public facing site that users are not likely to
frequent, access keys are not required. Good keyboard accessibility,
skip links and smart use of navigation patterns such as accordions for
menus and other repeated content with a lot of focusable elements,
usually makes pages not just accessible but pretty usable with the
keyboard.
On pages that users use frequently, such as for work-based online
applications like spreadsheet applications, email, Twitter, Facebook
etc, implementing access keys for the most frequently performed
actions are keyboard usability improvements, not required for WCAG,
unless the access key is the only way to navigate to the page
component, and that is pretty close to being an accessibility vilation
anyway, not unless user can navigate out of it with the keyboard and
the navigation is clearly documented on the webpage.

The problem lies in discoverability. The accesskey attribute has
little to no discoverability in browsers. Screen readers announce them
but a screen reader user actually benefits a lot less from access keys
than e.g. users with mobility impairments.

so if your application is one where users log in and are likely to use
frequently, you may consider picking the top 3 or 4 tasks the users
are likely to perform and assign access keys to those. Then make sure
they are discoverable.
Make sure to limit access keys to 5 or less for an application and try
to pick keybord shortcuts that do not override native browser
shortcuts, e.g. "f" often overrides the shortcut for the file menu, at
least in IE (FF and Chrome us ctrl and alt as modifier keys for the
accesskey so conflicts are not common).



On 3/26/18, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Do you need to implement the accesskey attribute in order to be
> accessible? No.
>
> However, I really like it when there are access keys for common
> functionality. The problem is that they're not normally discoverable. For
> example, on wikipedia, the search field that's in the upper right (when
> you're viewing a wiki page), has an accesskey='F', but you'd never know it
> unless you look at the code. It lets me quickly get to that field no
> matter where I am on the page, which I love, but again, you probably don't
> know it's there.
>
>
> On Mon, Mar 26, 2018 at 10:28 AM, Kakarla Meharoon <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> *Is it access keys are really necessary to implement?*
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: John Foliot
Date: Tue, Mar 27 2018 7:15AM
Subject: Re: Access Keys
← Previous message | Next message →

15 years ago, we wrote a series about accesskeys, starting here:
https://john.foliot.ca/using-accesskeys-is-it-worth-it/

Not much has changed, except for the emergence of single-key "accesskeys",
which are also problematic, to the point that we had to create a new
Success Criteria for WCAG 2.1:
https://www.w3.org/TR/WCAG21/#character-key-shortcuts

Today, the HTML 5 specification talks about the ability for user-agents to
re-map accesskeys, based upon the end-user's requirements, but to date I am
unaware of any User Agent that affords this ability (you used to be able to
do so in the older versions of Opera, but that functionality is now gone).
See: https://www.w3.org/TR/html52/editing.html#assigned-access-key

Bottom line: they are not required, they can be problematic, and unless the
site/page has a high-frequency repeat-visit rate, not worth the effort.

JF

On Mon, Mar 26, 2018 at 11:36 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Well put.
> ON a retail website or public facing site that users are not likely to
> frequent, access keys are not required. Good keyboard accessibility,
> skip links and smart use of navigation patterns such as accordions for
> menus and other repeated content with a lot of focusable elements,
> usually makes pages not just accessible but pretty usable with the
> keyboard.
> On pages that users use frequently, such as for work-based online
> applications like spreadsheet applications, email, Twitter, Facebook
> etc, implementing access keys for the most frequently performed
> actions are keyboard usability improvements, not required for WCAG,
> unless the access key is the only way to navigate to the page
> component, and that is pretty close to being an accessibility vilation
> anyway, not unless user can navigate out of it with the keyboard and
> the navigation is clearly documented on the webpage.
>
> The problem lies in discoverability. The accesskey attribute has
> little to no discoverability in browsers. Screen readers announce them
> but a screen reader user actually benefits a lot less from access keys
> than e.g. users with mobility impairments.
>
> so if your application is one where users log in and are likely to use
> frequently, you may consider picking the top 3 or 4 tasks the users
> are likely to perform and assign access keys to those. Then make sure
> they are discoverable.
> Make sure to limit access keys to 5 or less for an application and try
> to pick keybord shortcuts that do not override native browser
> shortcuts, e.g. "f" often overrides the shortcut for the file menu, at
> least in IE (FF and Chrome us ctrl and alt as modifier keys for the
> accesskey so conflicts are not common).
>
>
>
> On 3/26/18, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> > Do you need to implement the accesskey attribute in order to be
> > accessible? No.
> >
> > However, I really like it when there are access keys for common
> > functionality. The problem is that they're not normally discoverable.
> For
> > example, on wikipedia, the search field that's in the upper right (when
> > you're viewing a wiki page), has an accesskey='F', but you'd never know
> it
> > unless you look at the code. It lets me quickly get to that field no
> > matter where I am on the page, which I love, but again, you probably
> don't
> > know it's there.
> >
> >
> > On Mon, Mar 26, 2018 at 10:28 AM, Kakarla Meharoon <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> *Is it access keys are really necessary to implement?*
> >> > >> > >> > >> > >>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
= EMAIL ADDRESS REMOVED =

Advancing the mission of digital accessibility and inclusion

From: glen walker
Date: Tue, Mar 27 2018 1:03PM
Subject: Re: Access Keys
← Previous message | Next message →

Hi John. Regarding your last statement, does that mean if a page *does*
have a high-frequency visit rate, then it *is* worth it to have accesskeys?

Speaking as a keyboard user, I'd say yes, because it makes my life easier,
but I'd only want accesskeys on things that are commonly used on that
page. I don't expect every button or link to have one. Just 1 or 2 or
maybe 3 elements on the page.

Not to digress too far into another subject, but a page like amazon.com,
the first thing I always do there is search for something, yet the initial
focus is not on the search field. Same with imdb.com. Whereas
craigslist.org and wikipedia.org both put the focus in the search field
(which is not the first focusable object on the page). If a site chooses
not to put the initial focus on a commonly used element, it would be really
nice if there was an accesskey so I could quickly put my focus there.


On Tue, Mar 27, 2018 at 7:15 AM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:

>
> Bottom line: they are not required, they can be problematic, and unless the
> site/page has a high-frequency repeat-visit rate, not worth the effort.
>
> JF
>
>

From: John Foliot
Date: Tue, Mar 27 2018 1:33PM
Subject: Re: Access Keys
← Previous message | Next message →

Hi Glen,

To be sure, accesskeys can be hugely beneficial, but only in limited
instances. Discoverability (and also related: internationalization), along
with conflict management (what happens if a key stroke combo is 'reserved'
by assistive tech, for example), remain problematic.

In an 'intranet' solution, I'd be all over accesskeys for common commands
or activities, but for most general purpose sites, I'd recommend not
bothering, in part because there is no standardization of what key stroke
would map to what function (both a benefit and a curse). Looking at your
"Search" example and internationalization issues, what would you map the
accesskey to? "S" for Search? "C" for Chercher (French)? "B" for Buscar
(Spanish)?

Note as well that the new SC in WCAG 2.1 (Draft) emerged with a requirement
("A mechanism is available to remap the shortcut to use one or more
non-printable keyboard characters" - one of 3 possible solutions.
https://www.w3.org/TR/WCAG21/#character-key-shortcuts) that suggest a
multi-character string (The Understanding document will reference
voice-activated "shortcuts" that require more than a single key), so it's a
bit of a quicksand situation today.

Personally, I would proceed with extreme caution.

JF

On Tue, Mar 27, 2018 at 2:03 PM, glen walker < = EMAIL ADDRESS REMOVED = > wrote:

> Hi John. Regarding your last statement, does that mean if a page *does*
> have a high-frequency visit rate, then it *is* worth it to have accesskeys?
>
> Speaking as a keyboard user, I'd say yes, because it makes my life easier,
> but I'd only want accesskeys on things that are commonly used on that
> page. I don't expect every button or link to have one. Just 1 or 2 or
> maybe 3 elements on the page.
>
> Not to digress too far into another subject, but a page like amazon.com,
> the first thing I always do there is search for something, yet the initial
> focus is not on the search field. Same with imdb.com. Whereas
> craigslist.org and wikipedia.org both put the focus in the search field
> (which is not the first focusable object on the page). If a site chooses
> not to put the initial focus on a commonly used element, it would be really
> nice if there was an accesskey so I could quickly put my focus there.
>
>
> On Tue, Mar 27, 2018 at 7:15 AM, John Foliot < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> >
> > Bottom line: they are not required, they can be problematic, and unless
> the
> > site/page has a high-frequency repeat-visit rate, not worth the effort.
> >
> > JF
> >
> >
> > > > >



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
= EMAIL ADDRESS REMOVED =

Advancing the mission of digital accessibility and inclusion

From: glen walker
Date: Tue, Mar 27 2018 5:54PM
Subject: Re: Access Keys
← Previous message | Next message →

The i18n aspect doesn't bother me. If I frequented another country's site,
it wouldn't bother me if search was some letter I don't associate with
searching. It would just be a learning curve and then eventually, I would
associate that letter with searching (muscle memory) on their site.

But it sounds like in general we agree.



On Tue, Mar 27, 2018 at 1:33 PM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:

> Hi Glen,
>
> To be sure, accesskeys can be hugely beneficial, but only in limited
> instances. Discoverability (and also related: internationalization), along
> with conflict management (what happens if a key stroke combo is 'reserved'
> by assistive tech, for example), remain problematic.
>
> In an 'intranet' solution, I'd be all over accesskeys for common commands
> or activities, but for most general purpose sites, I'd recommend not
> bothering, in part because there is no standardization of what key stroke
> would map to what function (both a benefit and a curse). Looking at your
> "Search" example and internationalization issues, what would you map the
> accesskey to? "S" for Search? "C" for Chercher (French)? "B" for Buscar
> (Spanish)?
>
> Note as well that the new SC in WCAG 2.1 (Draft) emerged with a requirement
> ("A mechanism is available to remap the shortcut to use one or more
> non-printable keyboard characters" - one of 3 possible solutions.
> https://www.w3.org/TR/WCAG21/#character-key-shortcuts) that suggest a
> multi-character string (The Understanding document will reference
> voice-activated "shortcuts" that require more than a single key), so it's a
> bit of a quicksand situation today.
>
> Personally, I would proceed with extreme caution.
>
> JF
>
> On Tue, Mar 27, 2018 at 2:03 PM, glen walker < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Hi John. Regarding your last statement, does that mean if a page *does*
> > have a high-frequency visit rate, then it *is* worth it to have
> accesskeys?
> >
> > Speaking as a keyboard user, I'd say yes, because it makes my life
> easier,
> > but I'd only want accesskeys on things that are commonly used on that
> > page. I don't expect every button or link to have one. Just 1 or 2 or
> > maybe 3 elements on the page.
> >
> > Not to digress too far into another subject, but a page like amazon.com,
> > the first thing I always do there is search for something, yet the
> initial
> > focus is not on the search field. Same with imdb.com. Whereas
> > craigslist.org and wikipedia.org both put the focus in the search field
> > (which is not the first focusable object on the page). If a site chooses
> > not to put the initial focus on a commonly used element, it would be
> really
> > nice if there was an accesskey so I could quickly put my focus there.
> >
> >
> > On Tue, Mar 27, 2018 at 7:15 AM, John Foliot < = EMAIL ADDRESS REMOVED = >
> > wrote:
> >
> > >
> > > Bottom line: they are not required, they can be problematic, and unless
> > the
> > > site/page has a high-frequency repeat-visit rate, not worth the effort.
> > >
> > > JF
> > >
> > >
> > > > > > > > > >
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> = EMAIL ADDRESS REMOVED =
>
> Advancing the mission of digital accessibility and inclusion
> > > > >

From: mhysnm1964@gmail.com
Date: Wed, Mar 28 2018 10:51PM
Subject: Re: Access Keys
← Previous message | No next message

All,

Old solution but a goodie. Taking the page out of desktop apps. Remapping. Thus you could set up a set of keys and allow the user to remap them.

Personally, a standard way must be introduced into browsers and not conflict with the OS built-in shortcut keys. Single key access in my book is a no no. AS firefox can use this to search through your page if you have turned on the option, demonstrating a non-assistive tech possible conflict. I prefer firefox's method of ctrl+shift or alt+shift.

Shortcut keys in my view are very useful for non-screen reader users. (I am a screen reader user). I find they get in my way.

Sean
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Wednesday, 28 March 2018 10:55 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Access Keys

The i18n aspect doesn't bother me. If I frequented another country's site, it wouldn't bother me if search was some letter I don't associate with searching. It would just be a learning curve and then eventually, I would associate that letter with searching (muscle memory) on their site.

But it sounds like in general we agree.



On Tue, Mar 27, 2018 at 1:33 PM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:

> Hi Glen,
>
> To be sure, accesskeys can be hugely beneficial, but only in limited
> instances. Discoverability (and also related: internationalization),
> along with conflict management (what happens if a key stroke combo is 'reserved'
> by assistive tech, for example), remain problematic.
>
> In an 'intranet' solution, I'd be all over accesskeys for common
> commands or activities, but for most general purpose sites, I'd
> recommend not bothering, in part because there is no standardization
> of what key stroke would map to what function (both a benefit and a
> curse). Looking at your "Search" example and internationalization
> issues, what would you map the accesskey to? "S" for Search? "C" for
> Chercher (French)? "B" for Buscar (Spanish)?
>
> Note as well that the new SC in WCAG 2.1 (Draft) emerged with a
> requirement ("A mechanism is available to remap the shortcut to use
> one or more non-printable keyboard characters" - one of 3 possible solutions.
> https://www.w3.org/TR/WCAG21/#character-key-shortcuts) that suggest a
> multi-character string (The Understanding document will reference
> voice-activated "shortcuts" that require more than a single key), so
> it's a bit of a quicksand situation today.
>
> Personally, I would proceed with extreme caution.
>
> JF
>
> On Tue, Mar 27, 2018 at 2:03 PM, glen walker < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Hi John. Regarding your last statement, does that mean if a page
> > *does* have a high-frequency visit rate, then it *is* worth it to
> > have
> accesskeys?
> >
> > Speaking as a keyboard user, I'd say yes, because it makes my life
> easier,
> > but I'd only want accesskeys on things that are commonly used on
> > that page. I don't expect every button or link to have one. Just 1
> > or 2 or maybe 3 elements on the page.
> >
> > Not to digress too far into another subject, but a page like
> > amazon.com, the first thing I always do there is search for
> > something, yet the
> initial
> > focus is not on the search field. Same with imdb.com. Whereas
> > craigslist.org and wikipedia.org both put the focus in the search
> > field (which is not the first focusable object on the page). If a
> > site chooses not to put the initial focus on a commonly used
> > element, it would be
> really
> > nice if there was an accesskey so I could quickly put my focus there.
> >
> >
> > On Tue, Mar 27, 2018 at 7:15 AM, John Foliot < = EMAIL ADDRESS REMOVED = >
> > wrote:
> >
> > >
> > > Bottom line: they are not required, they can be problematic, and
> > > unless
> > the
> > > site/page has a high-frequency repeat-visit rate, not worth the effort.
> > >
> > > JF
> > >
> > >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> = EMAIL ADDRESS REMOVED =
>
> Advancing the mission of digital accessibility and inclusion
> > > archives at http://webaim.org/discussion/archives
> >