No-Mouse Practice

Overview

Many users across the globe use only the keyboard to navigate the computer. This is for many reasons, including disability, but also far beyond it. In this lesson, you will learn how navigation works when you use only the keyboard. You will learn how keyboard shortcuts can help, what tab order is, and about the dreaded keyboard trap.

Goals

You have the following goals for this lesson:

• Learn about tab order
• Practice navigating a website using only the keyboard
• Learn about focus and keyboard traps
• Understand the WCAG guidelines regarding focus and navigation

Warm up

Have you ever watched someone navigate their computer without ever touching the mouse? When you are used to following the cursor, it is easy to track what they are doing. But for a keyboard user, there is not always a visible pointer to guide you visually. Imagine trying to use many of the applications you know if your mouse was unplugged.

Vocabulary

You will be learning about the following vocabulary words:

Web Content Accessibility Standards

This lesson covers the following standards:

• WCAG 2.2 - 2.1.1 Keyboard
• WCAG 2.2 - 2.1.2 No Keyboard Trap
• WCAG 2.2 - 2.4.3 Focus Order
• WCAG 2.2 - 2.4.7 Focus Visible

Explore

The keyboard is a device almost everyone who has used a desktop is familiar with using, and it is almost always paired with a mouse or trackpad. However, not everyone uses the mouse and even those that do are not using it the same way. For example, while many users with physical disabilities have many kinds of pointing devices. Others might use the mouse, but sparingly, and rely on keyboard input for speed. As a clear example, a virtual keyboard on screen, using a mouse, is arguably far slower than using a physical keyboard if one is able.

Needless to say, getting the keyboard working with an application is a crucial first step for accessibility. In fact, if you, dear reader, know nothing about accessibility and are not sure where to start, beginning with high quality keyboard support is a solid first step. Part of the reason for this is that while the mouse offers a point-and-click interaction model that many people are used to, it is not a good user interface for everything.

Now compare and contrast the affordances of the mouse versus the keyboard. With the mouse, you have to look at the screen, see where the mouse pointer is, and make physical gestures. With the keyboard, you move through content in a much more sequential and structured way. This puts your navigation at the mercy of the underlying structure and design of the application and content.

This combination, structure and keyboard support, is fundamentally critical to accessibility. Again, if you do not know where to start, structure and keyboard support is a good place. This does not fix everything related to accessibility, but it is a good place to start in part because it impacts many kinds of people in many ways.

Tab Order

To understand keyboard navigation you must understand keyboard focus. Consider a typical mouse interaction, you click on a text field, it changes color, a cursor appears and now you can start typing into it. The moment when you can type into the text field, the field is said to have keyboard focus. At this point, the text field is the primary element waiting to receive keyboard interaction. Each item typically, but not always, has a next and a previous element that can be focused.

When you use a mouse you can visually find an element, click on it, and interact with it. When you have only the keyboard you lose direct and spatial interactions. A primary tool keyboard users have to navigate is the Tab key. In most applications, every time you press the Tab key, the focus moves to the next interactive element in a pre-defined order. The order of these interactive elements is known as the tab order. A well-structured tab order flows logically and typically matches how content is visually presented. Typically, tab order is reversible with Shift + Tab.

By default, web browsers assign tab order based on the order in which elements appear in the HTML source code. This is because in most cases that order aligns with the natural reading order of the page. However, if needed, this can be internally altered on a web page with the tabindex attribute. The tabindex attribute allows for elements to be skipped completely or focused in a different sequence order. In some cases, this can enhance navigation, but not always. Keep in mind that a good tab order should be predictable, logical and consistent. In most cases, there is no need to alter the default order. Further, not all applications are so lucky as to be obvious what the tab order should be. Good examples of such applications are anything graphical (e.g., block languages, 3D modeling applications, game design toolkits).

Keyboard Traps

Tab orders can be changed dynamically, and there are times when navigating with just a keyboard can stop a user from continuing. When you are unable to move keyboard focus away from a specific element or section this is known as a keyboard trap. Another kind of trap is a focus trap and understanding the difference is important.

A focus trap is often related to a particular user interface component where the user is constrained, on purpose. A common focus trap example is a modal dialog. A modal dialog is a special dialog used when you want the user to expliciting interact with the dialog only for a short time. An example could be a yes or no prompt when trying to delete a file. A correctly programmed modal dialog might allow you to navigate between yes and no buttons with the keyboard or press escape to get out of it entirely.

Keyboard traps are different from focus traps. Using the same example of a modal dialog, imagine that once the user navigates to the yes button, pressing tab or shift tab does nothing. They are forever stuck on yes. This example, which is hardly hypothetical given how easy it is to accidentally make a keyboard trap, and would be especially pernicious for something like a legal agreement.

WCAG describes this in 2.1.2 No Keyboard Trap. Here is how they describe it:

If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

Essentially this requirement is that if something can get keyboard focus, there must be a mechanism to move the focus away. If focus becomes intentionally trapped there must be a clear and keyboard accessible mechanism to leave the trap. For a model dialog, the Escape key or a Close button are common.

Keyboard Navigation

When using only the keyboard to navigate, it can be difficult at first to learn how to navigate a new page or application. There are a select few common keys used by a majority of applications to navigate and these are some of the most essential to learn when navigating with the keyboard.

Tab and Shift Tab are going to be the most essential keys to use when trying to navigate a page at first. To find the tab order of a page, go to the page and keep pressing Tab and see where it takes you. Tabbing through a page is also typically cyclical, meaning that if you reach the last element and try to move forward you will go back to the first. Tab is hardly efficient, but the point is that it is a place to start.

When you arrive at an element you can typically try the Enter key or Spacebar to interact with it. Links and buttons can be interacted with with the enter key just as if you clicked on them. Both keys or one can work depending on the context but both are essential for engaging with interactive content.

Some controls need more fine grained navigation where using the tab key becomes bothersome or impractical. In those cases the Arrow keys come into play and this is especially true with a keyboard selection. Unlike the focus, a keyboard selection, which typically uses arrows, controls certain types of user interfaces. Common examples include trees, lists, and radio buttons. In each case, instead of using Tab to move between elements, you use the arrow keys to mouse around. Under the hood, accessibility systems treat selection differently from focus and the distinction can get in the weeds pretty quickly.

Consider an example of a listbox. It is an example where you can Tab to the list but use the arrow keys to interact with individual list items. In the context of Tab order the listbox is considered the tab stop and the listbox has its own selection where you can navigate to a specific item. Again, the listbox has the focus and the item inside the listbox has a selection. Such a detail may seem like it does not matter, but the distinction is important because this is often what is reported in accessibility checkers.

Keyboard Shortcuts

Keyboard shortcuts are powerful tools that let users perform actions quickly without the mouse. They can enhance efficiency for all users, but for people who cannot use a mouse, shortcuts are essential for navigating and interacting with an application.

The browser itself has many standard shortcuts keyboard users rely on. Ctrl + T (Cmd + T on Mac) opens a new tab while Ctrl + W closes the tab. Some shortcuts might even move keyboard focus like Ctrl + L which moves focus to the address bar. Learning these shortcuts allow for a smoother experience for keyboard users and sighted users alike. Keep in mind that no one knows all the keyboard shortcuts immediately. Every user has to learn so if you choose to add keyboard shortcuts, there should be a way for users to find out they exist.

There is also a priority when it comes to keyboard shortcuts. The browser, the operating system, and screen readers have their own shortcuts and these can take precedence over your application. For example on a browser it is not a good idea to try to use the Ctrl+W shortcut because either the browser might not pass the keys to your application and do their own function instead. Even if you get the browser to do it, this could confuse users because the behavior they expected has changed unknowingly.

Engage

In this lesson, you are going to spend some time navigating without the mouse. For this exercise, the following items cannot be used unless you have no choice:

• The mouse
• The trackpad
• Any other pointing device

If you have a physical mouse, unplug it for this exercise. If you use a trackpad that cannot be unplugged, you are on the honor system not to touch it. It is crucial you do not cheat. It is far easier to find keyboard traps in your application if you eat your own dog food without a mouse.

Directions

Do the following for this exercise:

• Pick a group: Split up into groups and choose a site or tool to represent your group. This may be a homepage for your product or a template for using it.
• Pick a website and a goal: As a group, come up with a goal for a typical user. Imagine what a user might do when they first reach your site or tool.
• Swap websites and goals with another group: Now groups will swap and give their site or tool to another group and also share the goal the group has.
• Navigate with the keyboard: Using only the keyboard, try to accomplish the goal set by the other group. If at any point you have to use the mouse to interact with a certain part of the site or tool consider the goal failed.

After your attempts as a group, share what you found difficult when using only the keyboard. If there were keyboard shortcuts, share how you were able to find them and if you found them helpful. If you found yourself in a spot where you were forced to use the mouse, share that as well.

Consider as well why you are swapping websites here. It is tempting to try and use your own content, which you may already know well. However, by swapping with another group, where they may not know the content well, it can give you a rough gut check for how easily explorable the keyboard commands are.

Next Tutorial

In the next tutorial, we will discuss Web Accessibility Checkers, which describes how to inspect and evaluate websites for accessibility using built-in tools.