Keyboard accessibility myths and WCAG

Posted on Monday, 27 November 2023 by Graeme Coleman in Design and development

Supporting keyboard-only interaction is one of the most important principles of web accessibility. However, the scope of the Web Content Accessibility Guidelines (WCAG) in relation to keyboard accessibility is often misunderstood.

Keyboard accessibility and WCAG

The main Success Criterion (SC) addressing keyboard accessibility within the Web Content Accessibility Guidelines (WCAG) is Success Criterion 2.1.1 Keyboard (Level A). This SC is often interpreted to mean that all content must be operable using the keyboard alone, without exception. However, if you consider how the SC is phrased, this is not the case:

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

There are two statements within the SC that often cause developers to misinterpret the scope of the SC:

All functionality of the content

and

except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Keyboard accessibility and functionality

Interacting with a website or application typically involves performing sets of tasks, such as purchasing an item, reading a document, playing a video, liking a post, and so on. People interact with multiple individual controls to perform these tasks, such as buttons, links, form fields, as well as custom widgets such as carousels. Developers will therefore often spend a significant amount of time and effort ensuring that each of these controls is fully operable using the keyboard alone.

A person's hands typing on a MacBook Pro keyboard — Using a keyboard to navigate the web

However, it's the functionality of the content that's important, not the extent to which individual controls are keyboard accessible. This means that the SC can be met even if individual controls aren't keyboard accessible, as long as there is also a way of achieving the same result using the keyboard alone.

For example, an application form on a website may require a person to provide their date of birth by selecting the date from a date picker. If this date picker can only be operated using the mouse, and there is no other way for a person to enter their date, the SC won't be met. This is because there is no way for anyone using a keyboard alone to provide their date of birth.

A date picker labeled 'Date of birth' without any form of manual entry — An example of a date picker that can only be operated using the mouse

However, if the form also includes a separate, keyboard accessible, method for a person to provide their date of birth, the SC will be met. This is because a date of birth can still be provided even if the date picker itself is not operable. For example, the form could also include a date field that would allow the person to enter their date of birth manually instead.

A date picker labeled 'Date of birth' with an extra date field allowing manual entry — An example of a date field that supports both direct manual text entry and a separate date picker widget

That said, it is good practice to ensure that all controls are keyboard accessible by design, even if it means going above and beyond what is required by the SC, as this means you won't need to provide an accessible equivalent.

Keyboard accessibility and paths

Like many other WCAG success criteria, SC 2.1.1 Keyboard (Level A) allows for certain exceptions. These exceptions relate to tasks that require people to trace a "path" using their input device. In some cases, it may be possible to achieve this using the keyboard alone or by providing an equivalent keyboard accessible method, and therefore the underlying functionality is subject to the requirements of the SC. In other cases, the very nature of the task means that it simply can't be completed using the keyboard alone, and no sensible keyboard accessible alternative exists – or at least no alternative that isn't extremely complex, time-consuming, or generally laborious. Here, the underlying functionality is exempt from the requirements of the SC.

Paths

Distinguishing between those tasks that are subject to the SC and those that aren't can be somewhat tricky. To help make the decision, it is worth defining what a "path" means in this context.

The path refers to the route a person follows using their input device in order to complete an interaction. The path can be core to what the person is trying to do, such as drawing a circle, or it can be a function of how a control is presented or implemented, such as requiring the person to drag an object from one place to another.

The extent to which the functionality must be operable using the keyboard alone depends on whether the interaction involves path-independent input or path-dependent input.

Path-independent input

Path-independent input refers to interactions where the route that a person traces between two points doesn't matter. For example, a media player might include a volume slider. For example, a person may want to adjust the volume level from 5 (the start point) to 11 (the end point). Here, the way that they move the toggle from the start point to the end point is irrelevant. They could move the toggle directly between the two values, or they could move it back down to 0, up to 12, and then back down to 11.

A vertical volume slider where the toggle is approximately halfway between the loudest and quietest points on the slider. There are plus and minus buttons at the top and bottom of the slider. — A volume slider that includes Volume Up and Volume Down buttons as keyboard accessible alternatives for changing the volume

Typically, interactions requiring path-independent input can be made keyboard accessible, and are therefore subject to the SC. In the above example, the toggle should be made focusable, and a person should be able to move it along the slider using the arrow keys. If that's not possible, a developer could implement focusable buttons either side of the slider that, when activated, reduce and increase the volume respectively. The key aspect is that there is nothing within the task that should prevent it from being completed using the keyboard alone.

Path-dependent input

Path-dependent input refers to interactions where the route that a person traces between two points does matter. For example, "steady hand" games require players to move an item along a narrow twisting path from one end to another without deviating away from the path.

A game with a Start point on the left, and an End point on the right. There is a squiggly line between these points, and a toggle on the line that a person must move from the start point to the end point without deviating away from the line. — A steady-hand game that requires a path-based gesture to operate

A second example is free-hand drawing in a graphics editor. Again, there is a start point (a blank slate) and an end point (the complete drawing) but getting to that endpoint is completely dependent on how a person uses their input device to draw a picture.

Interactions like these can typically only be completed using a pointing device – such as a mouse or stylus – rather than a keyboard. While it is theoretically possible to make the task keyboard accessible, such as assigning specific keys to individual directions of movement, the result is likely to be unintuitive and require an inordinate number of key presses, to such an extent that it is unrealistic to expect people to complete the operation in a timely manner.

Therefore, such activities are exempt from the success criterion.

Note on paths and Level AAA requirements

It is important to note that, while path-dependent interactions are exempt from Success Criterion 2.1.1 Keyboard, which is a Level A success criterion, they are not exempt from Success Criterion 2.1.3 Keyboard (No Exception), which is a Level AAA success criterion. The latter success criterion requires that all interactions must be operable using the keyboard, regardless of input method. However, this does not mean that path-dependent interactions must be made keyboard accessible; as indicated above, such interactions generally can't be completed using the keyboard alone. Rather, it means that such interactions won't conform to this success criterion and therefore won't meet Level AAA.

Note on paths and pointer gestures

It is important to note that this blog post is primarily concerned with keyboard interaction only. There are success criteria you should be aware of when supporting interaction using the mouse and other pointing devices, such as Success Criterion 2.5.1 Pointer Gestures (Level A), which covers path-dependent input, and Success Criterion 2.5.7 Dragging Movements (Level AA), which deals with path-independent input. For more details on this subject, refer to our Foundations blog post on pointer gestures.

Conclusion

Supporting keyboard interaction is a key aspect of web accessibility. However, WCAG itself doesn't require that each and every interactive control is keyboard accessible. Rather, WCAG only requires that the functionality associated with a task can be completed using the keyboard alone. In some cases, this may mean providing additional ways that will allow people who cannot use a mouse, touch, or a similar pointing device to complete the task.

More information

Next steps

For more information about the Web Content Accessibility Guidelines, read our WCAG Primer or learn how our Assessments and Agile user experience testing services can help you review the accessibility of your products and test them with people with disabilities.