Before Using the HTML Accesskey, Read This

The HTML (HyperText Markup Language) attribute accesskey allows a webpage to create a keyboard shortcut for an element. The intended purpose of the attribute was to improve accessibility — but unfortunately, it’s not the best tool for the job. 

That’s because different web browsers provide different levels of support for accesskey. Additionally, setting a keyboard shortcut can interfere with screen readers (software that converts text to audio or braille) and other assistive technologies (AT). 

In this article, we’ll explain how using the HTML accesskey attribute can create problems for all users, including (but not limited to) those with disabilities. We’ll also provide an accessible alternative using WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications). 

HTML accesskey creates keyboard shortcuts, but browser support is poor

Let’s review a quick example of accesskey markup. In the HTML below, a search button can be triggered by using a keyboard shortcut with the letter “S.” 

<button accesskey="s">Search our website</button>

This would not allow users to simply press the letter “S" to activate the button — the user would need to activate the accesskey with a combination of keyboard buttons, depending on their web browser and operating system. 

For example, a Windows user would need to press Alt + S on Google Chrome, while a Windows Firefox user would need to press Alt + Shift + S. On MacOS, a Firefox user would need to use Ctrl + Option + S — unless they’re using an older version of Firefox, in which case they’d use Ctrl + S or Ctrl + Alt + S. 

Confused yet? That’s the primary issue with accesskey: Generally speaking, it creates a worse user experience. If your webpage uses accesskey, you’d need to provide instructions for all combinations of web browsers and operating systems to make sure that your users understood how to activate the element. 

Related: What Is Keyboard Accessibility?

The accesskey attribute also introduces serious accessibility concerns

Most people who use screen readers use their keyboards to browse the internet. Screen-reading applications use hotkeys for navigation — and if you’ve defined a keyboard shortcut value that conflicts with screen reader hotkeys, your website might operate in unpredictable ways. 

Other accessibility issues could impact your users: 

• The accesskey attribute value consists of a single printable character. Some characters aren’t present on all keyboards. 
• If the accesskey value is an English character, people who use non-English keyboards might be unable to activate it.
• Numeric accesskey values may be confusing for people with cognitive conditions such as attention disorders and dyslexia. 
• The user must be informed of how accesskey works. Some users may activate keyboard shortcuts accidentally. 
• Some screen readers will announce the accesskey value each time the element is encountered. This can become repetitive and distracting for screen reader users, particularly if the element appears throughout a website.

For these reasons, accesskey is not recommended. This is one of the few situations where ARIA is a more appropriate choice than plain old semantic HTML — provided that you actually need to implement keyboard shortcuts in the first place.

Related: 5 Tips for Using ARIA to Improve Web Accessibility

ARIA keyboard shortcuts are preferable, but be careful

The aria-keyshortcuts attribute informs AT users of site-specific keyboard shortcuts. It does not modify the functionality of your page for all users — just for AT users — but it’s widely supported by popular screen readers and other AT. 

Instead of using HTML, you can script your shortcuts, then use ARIA to inform AT users of the functionality. However, if you use ARIA, remember that you’re making a commitment to test your work. Poor ARIA implementation can introduce serious accessibility concerns, including keyboard traps (focusable elements that prevent users from “escaping" with standard keyboard commands).

Ask questions before using aria-keyshortcuts:

• Does my content really need site-specific shortcuts? 
• Does my website have application-like functionality that justifies shortcuts? 
• How will I choose shortcut attributes, and how will I prevent conflicts with existing shortcuts? 
• Am I willing to test my website with a screen reader to make sure that my markup works as expected? 

By thinking about the experiences of real users, you can prioritize accessibility — and avoid unnecessary complexity. For additional guidance, read: ARIA Keyboard Shortcuts: What to Know.

If you’ve got a specific question about ARIA or web accessibility, we’re here to help. Send us a message to connect with an expert.