Throw Your Mouse Out the Window

Accessibility for people who are physically unable to use a mouse is just one of many web accessibility issues. But it is perhaps the easiest to test.

This year as in the past 17 years, ITSS has been having Accessibility 101 eClass participants throw their mouse out the window. Okay, we don't really do that, as participants might not be able to find their mouse again. But they do not use a mouse as part of an important exercise.

Purpose of the Exercise

The idea is to have class participants navigate websites with a only a keyboard. Keyboard accessibility is an important aspect of web accessibility. Many people with motor disabilities as well as people who are blind typically use a keyboard. People with low vision can also rely on use of a keyboard for navigation.

This exercise helps class participants understand what it feels like, and hopefully get them thinking about how problems can be overcome. The aim is to partially learn (please consult the note on simulations) what it's like to have access to the web restricted.

Instructions Are as Follows:

  1. Take your mouse/track ball/pointing device, unplug it, and throw it out the window. Okay, don't really do that, you might not be able to find it again. But don't use a mouse for the purpose of this exercise. Use only a keyboard.
  2. Look up the keyboard shortcuts for your browser in the help files or manual pages. Oops, we should have told you to do that before removing the mouse. Well, just remember that people with disabilities aren't magically born knowing how to run computers either, and if the help system is not accessible, they are in as much trouble as you are now!
  3. With your "disabled" browsing system, visit a website or an online course.
  4. Try to use the site as you normally would.

What Was Your Experience Like?

  • Could you access all features?
  • Could you operate all buttons, sliders, and other controls?
  • Could you easily tell where you are on the page?

Takeaways and Relevant WCAG Guidance

Web Content Accessibility Guidelines (WCAG) 2.1, level AA, serves as the web accessibility standards for the University of Minnesota. Following these guidelines will make content more accessible to a wide range of people with disabilities.

In sum for keyboard accessibility:

  1. All controls, links, and menus need to be operatible using only the keyboard.
  2. The user needs to be able to see what item has focus at all times.
  3. The visual focus order should normally match the tabbing order.
  4. A way to bypass blocks of content needs to be provided.

1. All controls, links, and menus need to be operatible using only the keyboard.

WCAG Success Criterion 2.1.1 is Keyboard Accessible:

Make all functionality available from a keyboard.

People who are blind or who have low vision often use screen readers to navigate web pages using only the keyboard. Keyboard operability is also essential for many people with motor impairments who use alternate keyboards, or input devices that act as keyboard emulators when accessing the web because they find mouse pointing to be cumbersome or impossible. Keyboard emulators include voice recognition software, sip-and-puff software, and on-screen keyboards.

2. The user needs to be able to see what item has focus at all times.

Defining focus on navigation elements is a requirement, as clearly stated in WCAG 2.4.7 Focus Visible:

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

A clear and visible keyboard focus indication is critical for people with low vision or who have motor control disabilities. Unlike mouse users who point directly to User Interface (UI) elements, these users need a clear and highly visible on-screen indication enabling them to know where they are on a web page as they navigate with the keyboard from UI element to UI element. Otherwise, they have limited ability to follow links.

3. The visual focus order should normally match the tabbing order.

WCAG Success Criterion 2.4.3 is Focus Order:

If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

This means keyboard navigation should follow the visual relationships in the content. For instance sighted keyboard users may become disoriented if the navigation jumps around.

Navigating with the keyboard can be just as efficient as with a mouse , as long as the tabbing order through content can be reliably predicted and that every active element included in a page can indeed be reached in an order that makes sense. Sighted keyboard need a predictable tabbing order through content, so they can reasonably apprehend navigation through the page.

4. A way to bypass blocks of content needs to be provided.

Long lists of navigation links can be tedious to wade through for keyboard users. WCAG addresses this with Success Criterion 2.4.1 Bypass Blocks:

A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

Sighted mouse users can ignore long lists of navigation links. Sighted keyboard-only users who are not using screen readers must experience the links one after another unless mechanisms are used. "Skip" links provide this important functionality. Landmarks help assistive technology users orientate themselves within a document, and provide a mechanism to navigate.

A Note on Simulations

Simulations do not provide a full view of barriers and limitations. Simulations such as this exercise can pale to the actual experience for someone with a disability. It does not simulate motor disabilities. It effects a loss of one type of motor functionality. Those are very different things. One is deprivation; the other is a lived experience. What makes that lived experience relevant is that it can entail exclusion.