Keyboard Accessibility Learning Takeaways

January 27, 2022

The pretty design of your app will for sure have a good impression on a user. However, it is its usability that they will decide whether to use it again or not. In other words, your application should be fully accessible no matter the tools that are used. Several people are keyboard-only users, and their digital experience depends on it. A person might choose to use a keyboard due to a disability that limits them from using a mouse, or simply because keyboard shortcuts offer higher efficiency.

This post points out some of my learning and takeaways from testing components for accessibility. Common errors for keyboards arise from these areas:

  • Order and navigation
  • Focus indications
  • Custom components

1. The order of HTML elements matters

Users navigate using the tab key of the keyboard, and the order of the interactive components is important. Sighted users will expect that the focus indicator will move in the order of the elements they see on the page. The navigation order should go from left-to-right and top-to-bottom. Thus:

  • The underlying structure of your HTML is important
  • The order of DOM should be logical and intuitive
  • Only the interactive controls should be focusable

Avoid using the float property of CSS to style your pages. This property moves elements to look as needed visually, but the order of the focus indicator will remain the same, meaning based on the HTML elements order. The example below shows that the button floated right will still get focused second, even though visually it looks like the fourth button.

4 buttons with broken focus order because the second button is floated to the right

2. Focus indicator should always be visible

It used to be common that applications would add outline: none to their global stylings. However, this must be avoided because it will make your app unusable for users that prefer using the keyboard or it is the only way they can access your application. The outline is an indication that shows the element that is currently focused on. Although not everything in your application should be focusable, elements such as

, ,

etc. are not focusable. Controls such as buttons, links, and form controls are the primary elements that must be focusable.

Additionally, each browser has a different style of showing the outline (focus indicator), some of them show it as blue, black, etc. It is easy and preferable to customize the outline so it will match the design of your application. An example is:

*:focus {
  outline: 4px dotted #3aafb9;
  outline-offset: 4px;
}

The outline is drawn outside of the element’s border and it does not add other spacing, meaning that the layout of the page will not be broken.

3. Custom components need handling of keyboard navigation

There are situations where native HTML elements are not sufficient to present some part of your application. Thus, a custom component is needed for that and that is quite common, especially for widgets such as accordions, sliders, etc. In this case, these components must have the correct aria roles so that a keyboard user can interact with these components. The following attributes should be considered when creating such components:

  • Adding tabindex=“0” will make the elements focusable. The tabIndex must be now higher than 0 because it will break the order of elements being focused. The higher the number of tabIndex the sooner it will be focused, regardless of HTML structure.
  • Consider if any role attribute is appropriate for this component. You can find the types of roles in the W3C Aria documentation.
  • Review the Aria Authoring Practices to know how a component is expected to behave.

Conclusion

The order of the elements in HTML must always remain the same as they are ordered visually. Focus indicators must always be visible and it is important to also ensure high color contrast. Lastly, custom components need more considerations for keyboard accessibility.

Happy coding 👩‍💻


Profile picture

Hello World! I'm Tringa

I am a Software Engineer who spends most of the week writing code at Microsoft. I love creating usable and accessible UI that I try and share here as much as I can.