Time to revisit accesskey?

Many websites provide keyboard shortcuts for common tasks. Keyboard shortcuts are useful things to have, but the way in which they’re provided is often problematic for Windows screen reader users.

Websites like Facebook, Twitter and Google provide keyboard shortcuts for repetitive tasks, like posting a status update, replying to a tweet, or deleting an email. The shortcuts are intended to make things easier for keyboard-only users, but also for mouse users (because it’s often quicker to hit a keyboard shortcut than it is to locate the relevant control and click on it with a mouse).

Each of these sites (and many others) provide keyboard shortcuts using JavaScript. On the face of it this seems like a reasonable way to do things, but layering keyboard functionality on top of the application means that none of the shortcuts are available to Windows screen reader users.

Caught in the virtual buffer

Windows screen readers use a virtual model to support interaction with content rendered in the browser. A virtual buffer of the content is created, based on information from the DOM and accessibility tree. It is this virtual version of the content that the screen reader presents to the user.

Interaction with the virtual buffer works like this: the screen reader listens for keyboard events. When it detects a key press that corresponds to a screen reader command, that action is executed in the virtual buffer. For example, if the h key is pressed when a Windows screen reader is running, focus will move to the next heading (h1 – h6) in the virtual buffer. Otherwise the key is passed back through to the browser, where it will be caught by the JavaScript that handles the shortcuts provided by the website.

The trouble is that Windows screen readers utilise almost every available key for screen reader specific commands. This means that few keys make it past the screen reader to the browser, and consequently the JavaScript shortcuts are never triggered.

To take a specific example, p is the Facebook shortcut for posting a status update. If you use it without a Windows screen reader running, focus moves to the “What’s on your mind” field. If you try it with Jaws running, focus will move to the next paragraph, and in NVDA nothing will happen at all. In both cases the p key is intercepted by the screen reader, and never makes it any further.

It is possible to tell both NVDA and Jaws to pass the next key through to the browser. In NVDA you press the NVDA modifier (insert) f2, followed by the key you want to pass through. In Jaws it’s the Jaws modifier (insert) 3, followed by the key to pass back to the browser. This is not a user-friendly way to interact with a website though, even assuming you know it’s possible in the first place.

Identifying shortcuts

If the screen reader could identify the shortcut keys provided by the website, it would be possible to give the user a choice: use the screen reader’s native shortcuts, or use the shortcuts provided by the website. The problem is that when JavaScript is used, there is no information about the available shortcuts exposed in the browser’s accessibility tree. Each of the platform accessibility APIs has a shortcut property (dating back to the days of accesskey), but it isn’t possible to access the APIs with JavaScript.

An April 2015 update to Jaws 16 introduced a feature that attempts to solve the problem. The “Web application reserved keystrokes” setting tells Jaws to stop intercepting keys that have been reserved by the website. In the case of Facebook, Jaws would ignore the p as a command to move to the next paragraph, and send the key through to the browser where it would trigger the JavaScript shortcut for posting a status update.

This feature does solve the problem (for Jaws users at least), but it’s something of a dirty hack. In order for Jaws to know which keys have been reserved by the website, it’s necessary to reference the shortcuts in the HTML. For example:


<div data-at-shortcutkeys={‘j’: ‘Key to navigate to next post’, ‘q’: ‘Key to place focus in chat’}></div>

Jaws then has to scrape the DOM to get at that information. It’s a method that’s prone to error, and scraping the DOM is always much less efficient than querying the accessibility API.

Accessibility API access

What we need is a way for websites to provide keyboard shortcuts that are exposed in the browser’s accessibility tree – so that the information can be queried by any assistive technology using the accessibility API. Perhaps it’s time to revisit accesskey, fix the broken bits and extend it to become a useful thing?

7 comments on “Time to revisit accesskey?”

Skip to Post a comment
  1. Comment by Jennison Asuncion

    Your post is timely as I just read at http://www.freedomscientific.com/downloads/jaws/JAWSWhatsNew that the latest release of JAWS V16 has a new feature called “Allow Web Application Reserved Keystrokes,” which if I understand it right will now allow folks to create shortcut keys even if they are the same as JAWS default keystrokes in virtual PC mode. The issue here then becomes, if people start designing for this feature, what about users of other screen reading software?

    1. Comment by Léonie Watson

      This is the Jaws feature mentioned in the post.

      I’m not sure how a developer would “design to this feature” though? It just gives the user a binary choice between using Jaws’ shortcuts or the website’s shortcuts.

      If anything it’ll encourage developers to continue providing JavaScript shortcuts exactly as they’ve always done. Not a good thing IMO.

  2. Comment by TenTen71

    I would think that a standard list of keyboard commands developed by the screen reader software developers needs to be implemented just like we have standards in web browsers. And we as web developers will need to prepare for them.

    We in turn could request a list of standards to be added for certain functionality like posting, tweeting, etc. They might be CTRL + key.

    Just like all other technology usually adapts to new features and ways of life, so should screen readers with web trends.

  3. Comment by James Edwards

    Hmm, I’m not convinced.

    Let’s say you’ve reassigned “p” to be a shortcut, then how does a Jaws user trigger “next paragraph”? Either they’ve lost that functionality on that particular page, or Jaws will have to ask them every single time they press it. Neither of those sounds good to me.

    Personally, I don’t think accesskeys have a future. I think a much better approach would be an extension to grouped reading modes. Jaws can use “h” to move between headings, while other readers have a “headings list” that you can navigate through for quick access to section of the page. Something like that could be used for functional shortcuts — so a single standardised keystroke triggers that menu (for screenreaders, and for sighted users), then the user can tab or arrow between the options to trigger a particular action.

    It’s a bit more long-winded, but it would have the advantage of zero conflict with other functional keys.

  4. Comment by JC

    Overriding the default behaviour of the screen reader doesn’t seem like a very good idea.

    Perhaps making the keystroke passthrough a toggle instead of a one-time-use would be better?

  5. Comment by glen

    @JC – You’re not really overriding the default behavior of the screen reader. Well, you sort of are, but it’s up to the screen reader *user* to enable it. They have to go into the settings center and enable the checkbox to allow reserved keystrokes. So the user is willingly letting an app override *some* keys.

    It’s sort of a shortcut to turning the virtual pc cursor off (ins+z) and is probably better than the app writer using role=application.

    It’d be nice if data-at-shortcutkeys were more of a hint and that JAWS would ask you if you want to enable it for this particular app/website. So I could have it enabled for, say, facebook, but not for gmail.

  6. Comment by Taylor Hunt

    The web version of FogBugz does/did something that might be worth copying. Even without assistive technology intercepting keystrokes, browsers eat some unpredictable amount of keys for their own functions. Some people like those functions, and hate it when pages appropriate keys for their own use.

    The way they got around this was to map `;` as a toggle to “enable keyboard mode,” and only then would JavaScript intercept keystrokes.

    It might be possible to get this behavior in screen-readers *today.* If the “enable keyboard mode” switch can be presented to them somehow (which would involve research and trial and error), `role=”application”` can be applied until the next keystroke, which should stop assistive tech from intercepting it.

Comment on this post

Will not be published
Optional