HTMLElement.click()method simulates a mouse click on an element.
click()is used with supported elements (such as an <a style="text-decoration: none; color: #3f87a6; margin: 0; padding: 0; border: 0;" title="The HTML element is used to create interactive controls for web-based forms in order to accept data from the user.” href=”https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input”>
), it fires the element’s click event. This event then bubbles up to elements higher in the document tree (or event chain) and fires their click events.
The most important thing for you to remember when trying to make your site’s interactions work with a keyboard is that when navigating with a keyboard, “hover” is not a thing. When keyboard users want to interact with an element they expect to be able to hit enter/return to activate an element. Luckily, the keyboard return event syncs with the mouse “click” event.
Hence, if you know how to make something activate on a mouse click, then you should already be able to make it work with a keyboard. However, unlike the mouse where user navigation is more implicit, you will need to think about how the user navigates to the “clickable” element and whether or not they can visually see that they have arrived at the “clickable” element.
This is where visible focus states become especially important and I have an entire article dedicated to this topic.
Navigation and Interaction
This is where the keyboard interaction can get a little bit dicey. You may have carefully and cautiously made every interactive element on your site activate via keyboard, but this will not matter if the keyboard user cannot navigate to those elements, or are not able to see that they are on the interactive element when they want to activate it.
With a mouse, we don’t have to worry as much about how that navigation occurs. We can safely assume that the mouse user has some kind of arrow or cursor with which to see where they are on the site and to indicate which elements they are interacting with. In addition, most sites use changes on hover to give further visual cues to the mouse user that they are on an interactive element.
Unfortunately, it is not uncommon for some interactive elements to be completely in-accessible to keyboard users because they cannot navigate to them.
It is helpful to think through how your keyboard users navigate to, and interact with an element, in order to fully test whether or not your interactive elements are actually keyboard accessible.
Steps for keyboard interaction
For the sake of this example, we will pretend that we have an accordion element – a series of collapsible elements that expand or collapse by clicking on a bar or button.
Imagine that the keyboard user wants to navigate to and open the first item of an accordion element in order to view the content inside of it.
- Step one – The user navigates to the element using their keyboard.
- This is typically done by clicking on the “tab” key.
- The tab key will immediately move keyboard focus to the next focusable element on the page.
- The user will see the visible focus outline on that element and will continue clicking “tab” until they successfully arrive at the element that they want to access.
- Step two – The user arrives at the element they want to interact with
- The user knows they are on the correct place because the element with keyboard focus is clearly visible – this is typically shown via a blue outline or dotted line.
- Step three – The user clicks “enter/return” to activate the element.
- When a button element is used the user should also be able to use the spacebar key to activate it.
- Step four – The element activates.
- The accordion panel expands and the user should be able to navigate into the new expanded element if there are focusable items inside of it, or if they are using a screen reader.
Step 4 isn’t really a step – it is the outcome, but it is important to think about what we expect the user to be able to do once that element has been activated. Frequently, the element being activated is a menu or navigation list with links to additional content.
Activating the element, is often only part of the process. It is also important to verify that the user can interact in the expected way with whatever has changed on the page. In this case, it was a an accordion panel that expands. If that panel contained interactive content then it would also be important for the keyboard user to be able to navigate into the new panel and interact with the content inside of it.
A Process for Verifying Keyboard Usability of an Element
Here is a basic list of items that you can check to see if your keyboard interaction is working well. Please note: I am not listing techniques for accomplishing these items here as that would be a much longer article.
Before element activation
- The keyboard user can navigate to the element.
- The keyboard user can see that the element that they want to interact with has focus.
- The keyboard user can activate the element via a click of “enter/return” on the keyboard or with a spacebar click when a button element is used.
After element activation
- The keyboard user can immediately navigate into the activated element.
- This is especially important for pop-up windows and drop down panels.
- For example, the user should not have to navigate through the remainder of the page to get to a popup window or panel that just activated.
- In the case of a pop-up window/modal that is sitting in front of the other content, you should immediately move the keyboard focus to the new element.
- The keyboard user can interact with the content inside of the activated element if there is interactive content. A screen reader should also be able to be aware of and read any content that has been displayed.
- The keyboard user can close or deactivate the content.
- Deactivating the interactive elements is especially important when those elements block other content on the page. This is a common issue for dropdown menus and popup/modal content.
- “Re-clicking” the focused interactive element that is open or active, is generally expected to close it again.
- Connecting a “close” or “deactivating” event to the “Escape” key is also a common practice.
- The keyboard user can navigate away from the deactivated element.
- In cases where the activated element is overlaying or blocking other content, the activated element should close or deactivate if the user navigates away from it.
Consider User Expectations and Unplanned Behavior
Generally, the keyboard users expect to be able to re-click an element in order to deactivate it. However, it is not uncommon for developers to build in other shortcuts like closing an item on an “Escape” key press. It is a good practice to have a backup way to close a panel and “Escape” is the most common, however do not assume that your user knows that the backup or shortcut method is there. If your users expect to be able to re-click an element to deactivate it, and you do not have a good reason to not have that functionality, then you should probably build that in.
Also, think about what happens if the user fails to close the element.
Suppose you have a large video popup that takes over most of the screen. You would not want the user navigating behind this element, and trying to interact with elements behind the popup that are not visible when the video panel is open. In this case, and in cases where an activated element covers part or all of the content underneath, you should force the content to close or deactivate when the user navigates away from it. That way, content that is blocked does not continue to be obscured once the user is no longer interacting with the overlaying element.