Activating Interactive Element with Keyboard

element.click();

From Mozilla Developers Network

The HTMLElement.click() method simulates a mouse click on an element.

When 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”&gt;), 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Resources

 

 

 

 

 

Advertisements

Alt Text in Context

Using ‘alt text’ on images and icons

One of the common mistakes that web content creators and developers make when trying to make their sites accessible is related to “alt text.” We are told somewhere in the web development classes, boot camps, and tutorials that “alt text” is how you make an image accessible. This is not entirely true.

“Alt text” is the text you add to an “alt” attribute on an image. If you have ever seen a broken image on a site that shows a description of the image, it is the alt text that provides that description. In HTML, it looks like this: <img src="example.jpg" alt="image description" />

A little clarification is overdue. First, if you are using an image via an img tag (as opposed to as a background image) then you need an “alt” attribute. This does not necessarily mean that you need “alt text.” The “alt text” is the literal description that you put into your “alt” attribute. So when do you need one?

When Text Descriptions on Your Image are Essential

Text descriptions are absolutely essential in specific cases. Here are the circumstances in which alt text is not only necessary but crucial for your site’s accessibility.

  • The image is serving as an interactive element such as a link or button – screen readers will use the alt text to describe the link or button.
  • The image conveys information that is not otherwise available in a text form such as in an infographic.
  • The image includes text – please note – for accessibility purposes you should avoid using text in images whenever possible. However, in some cases such as for logos, text in an image is sometimes necessary. That text should be conveyed via the alt tag.

Also note, that if the same text is available near the image such as in a long text description or caption below the image, then the alt text may not be necessary.  The w3c has a nice decision tree for helping you determine when a text description is needed:

https://www.w3.org/WAI/tutorials/images/decision-tree/

When Not to Use Alternative Text

Imagine that you are a non-sighted user perusing the web site of a business that you are interested in and you here this: “Summer rates available for a limited time. Large yellow sunflower.”

That second sentence is the alternative text for the lovely sunflower image that the business uses across their site to accentuate their brand. The question for the business owner is: do you really need to tell your non-sighted users about the yellow sunflower –  everywhere that it occurs? More importantly, do you think that is what they want to know about?

For accessibility purposes, you should have an alt attribute on your images. However, in many cases you can use a null attribute. <img src="example.jpg" alt="" />

Notice the alt=”” in the code above. This is an empty or null alt attribute. Leaving the alt attribute empty tells screen readers that the image should be ignored.

Images that are only decorative in nature should get an empty alt attribute so that screen readers will know to ignore the image. You can still convey images that are intended to convey an emotional appeal by describing the image. Keep in mind that text descriptions of an image may have a bit of a different feel than the image itself.

Remember Cognitive Load

Before you fill your site with atmospheric images with descriptions like “Smiling happy couple,” and “Older couple, happily walking through a park,” think about what you really want to convey to your users. Too much information can negatively impact your intended message.

For screen reader users, cognitive overload from too much repeated information, or unneeded information is a frequent complaint. So make sure that that atmospheric image conveys useful information to your users before you add a text description to the alt attribute. Your users are generally on your site for a purpose, and unless you are a stock image site, they probably don’t want to know exactly how happy the images of the people you add to your product pages are. Instead, focus on the actual product, information, or message that you are hoping to convey.

Resources