Testing Accessibility with the Keyboard

What does it mean for a web app to be accessible?

An accessible app is one that can be used and operated by everyone, regardless of their abilities. This includes able-bodied users and those who interact with web apps in non-traditional ways, such as through assistive technologies like keyboards, screen readers (e.g., NVDA, VoiceOver), screen magnifiers, head trackers and other Assistive Technologies (AT).

As web engineers, it's important to understand that accessibility isn't just a nice-to-have—it’s essential for a wide range of users. Accessibility is also a legal requirement in the United States, Canada, the United Kingdom and the European Union.

Yet, accessibility needs are often overlooked, with some companies mistakenly assuming that their user base doesn't have accessibility needs. The reality is stark: 61 million adults in the U.S. live with a disability, which includes mobility, cognitive, auditory, and visual impairments.

When we fail to design with accessibility in mind, we unintentionally exclude 1 in 4 users from fully accessing our applications.

Therefore, it is important to build with accessibility in mind in order to create an inclusive experience for all.

In this article, we'll dive into what keyboard accessibility means and how you can test for it effectively.

Who Benefits from Keyboard Accessibility?

Keyboard accessibility enhances the experience for everyone, including those with disabilities and able-bodied people. Here's a breakdown of who benefits:

• Users with Motor Disabilities: Individuals with conditions affecting fine motor control, such as muscular dystrophy, cerebral palsy, Parkinson’s or spinal cord injuries, often depend on keyboard navigation as their primary mode of interaction.
• Temporary Disabilities: Users with temporary injuries, like a broken arm, or those recovering from surgery may find it difficult to use a mouse, making keyboard navigation essential. Even in every day life, parents holding a child in one arm can benefit from keyboard accessibility.
• Screen Reader Users: Blind or visually impaired users who navigate using screen readers rely on keyboard shortcuts and commands to move through content.
• Power Users: Even able-bodied users who prefer keyboard shortcuts for efficiency, such as using CMD + F to search a page or Alt + Tab to switch between apps, benefit from keyboard accessibility shortcuts.

When we build for accessibility, we build an inclusive experience for people of various abilities.

Assistive Technologies

People use web apps in different ways. Some people may use specialized software and customized settings to increase the efficiency of typing, writing and navigating. For instance, an avid screen reader user often relies on personalized shortcut keys that they find easy to remember and use regularly. Others might utilize text-to-speech tools and word prediction software to assist in completing words and sentences, while some depend on tools that allow them to click, select text, and scroll with minimal physical movement.

Therefore, web apps need to be designed to support these different types of approaches. For example, forms, links, and widgets need to be usable by keyboard.

Watch how Ade, a person with limited motor mobility skills experiences digital technology -

https://youtu.be/Z5dMdJzUy7w

Alternative keyboards offer many advantages over the traditional keyboard for individuals with motor, cognitive or visual disabilities. Since these are specifically designed to provide a simplified and more visible experience, it can reduce complexity. Some examples of alternative keyboards are -

1. Ergonomic keyboards
2. Keyboards with larger keys
3. Specialist keyboards - braille, chording and expanded devices
4. High-contrast keyboards
5. One Hand keyboards
6. Large print keyboards

Here is a great list of alternative keyboards.

What does it mean to be keyboard accessible?

Keyboard accessibility is a fundamental aspect of web accessibility. It ensures that all interactive elements—buttons, links, form fields, and interactive components—are operable via the keyboard alone. In simple terms, all parts of your app or web page should be navigable via keyboard.

To test this, try disconnecting your mouse or trackpad and navigate your app using only the keyboard. If you encounter any areas that are difficult to reach or navigate, take note—your users, especially those relying on assistive technology (AT), are likely facing the same or even harder challenges.

For React developers, making a web app accessible means more than just ensuring elements are focusable; it involves managing focus states, keyboard event handlers, and ARIA roles effectively. It also means providing alternate means of navigating features when applicable. Here are some examples of making elements accessible -

1. A media player widget that allows a mouse user to drag through the timeline to advance time also allows users to advance through the timeline using arrow keys.
2. A page with images that open popovers when a user hovers over the image using mouse also provides the same functionality when the user tabs to it.
3. A scrollbar that allows user to navigate to the bottom of the page also provides the same functionality with arrow keys.

Keyboard Functionality

When navigating with keyboard, certain keys provide a better experience of navigating through the elements. These interactions are standard across various assistive technologies. Therefore, when testing with keyboard, it is important to ensure the elements support interacting with certain keys. Here are the functionalities of keys and what you should be able to achieve with keys -

1. Tab key - navigate through every interactive element on the page such as button, links (anchor tag), form controls, such as input text, radio buttons, select menu, etc.
2. Shift + Tab - navigate backward through interactive elements
3. Enter - Selecting items, activating buttons, opening links, and activating interactive elements. You should be able to use the enter key to perform the actions that are associated with onClick functionality.
4. Space - Toggle checkboxes, control media such as play, pause, resume
5. Arrow Keys: Navigating within menus, adjusting sliders, and exploring dropdowns and lists.
6. Escape: Closing modals, pop-ups, and exiting dropdowns.

Expectations While Testing with Keyboard - WCAG 2.2

Web Content Accessibility Guidelines (WCAG) explain how to make web content accessible. The following guidelines in WCAG 2.2 are particularly relevant for keyboard accessibility:

1. All functionality is navigable via keyboard

Any functionality that is available to a user via a mouse action must be available via keyboard. If certain interactions are only available via mouse, such as hover interactions, an alternative must be provided for keyboard users. For example, a submenu that opens on hover should also open when a user hits the Enter key.

To test:

1. Identify all functionality of the content.
2. Navigate to all elements of the page using the keyboard.
3. Ensure that all content can be navigated using keyboard alone.

2. No keyboard trap

This guideline ensures that keyboard users can navigate through and exit any section of content without being trapped inside the content. A common place where this issue arises is in modals or widgets.

A modal is a pop-up or dialog that navigates the user away from the main window. When developing such elements, it is important to ensure that the user has the ability to tab into, or out of the modal.

In order to test that focus is not trapped within a part of the page:

1. Navigate through the content of the page from top to bottom using the keyboard.
2. When reaching a modal or widget, ensure that users can exit the modal and return to the main content. Esc key, or a designated keyboard shortcut can be used to exit out of a modal.

3. Correct tab order

It is crucial to ensure that the content flow of the page follows a logical order when navigated using the keyboard**.** Keyboard navigation should mirror the natural progression of content, avoiding focus from jumping around erratically.

For example, when navigating through a form, pressing the Tab key should move the user sequentially through each form fields without skipping any items. Additionally, ensure that every interactive element can be accessed via the keyboard.

To test this:

1. Navigate through the content of the page using the keyboard.
2. Confirm that the focus moves in a logical order that matches the visual and functional layout of the content.
3. Ensure that each interactive element is accessible in sequence without any unexpected jumps or omissions.

4. Focus remains visible

Providing visual feedback to users about which item is currently focused is essential when users are navigating with keyboard. This guideline ensures that focus outlines remain visible while navigating with the keyboard, allowing users to easily identify the focused element.

Avoid adding styles to hide the focus-outlines of elements, since this makes it hard for users using assistive technologies (AT) devices to determine which item is currently focussed.

To test this:

1. Navigate through the content of the page using the keyboard.
2. Verify that the focus outline is clearly visible on each focused element.
3. Ensure that no interactive element has its focus outline removed or hidden.

5. Event handlers are keyboard accessible

If a functionality is provided via a mouse, ensure that it is also accessible via a keyboard. This guideline is important for features that are predominantly mouse-dependent, such as drag-and-drop functionality. For example, if a user can drag and drop an item using a mouse, keyboard alternatives should be provided.

A possible implementation includes enabling users to select an item with the Enter key, use the arrow keys to drag it, and then drop the item with Enter again.

To test keyboard accessibility for event handlers:

1. Identify all functionalities on the page that rely on mouse interactions.
2. Attempt to navigate and interact with these functionalities using the keyboard.
3. Ensure that each functionality can be fully executed using keyboard controls, such as Enter and arrow keys for drag-and-drop actions.

Conclusion

Keyboard accessibility is essential for creating inclusive web experiences that work for everyone, including users with disabilities and those who prefer keyboard navigation. Testing your application regularly with a keyboard ensures that all interactive elements are usable without a mouse.

This proactive approach not only meets accessibility standards set by WCAG but also enhances the overall user experience for everyone. Remember, accessibility is an ongoing effort—every improvement you make brings us closer to a web that is inclusive to all.