WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Access Keys

for

From: John Foliot
Date: Mar 27, 2018 7:15AM

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 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 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 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 REMOVED>

Advancing the mission of digital accessibility and inclusion