Keyboard Accessibility
Keyboard accessibility is an essential aspect of inclusive web design and web accessibility. Our goal is to ensure that all users can fully access and control our web app via their keyboards.
Recently we’ve put our effort into designing the focus style and implementing a logical and more comfortable navigation flow. A lot of other improvements have been done to enhance the user’s experience with keyboard navigation and we will share them all down below.
What is keyboard accessibility?
First of all, let me explain what keyboard accessibility is. Keyboard navigation is a typical way to interact with a web application, where the keyboard is a main or single source of input. If a web application supports keyboard accessibility, the user can use the tab key to navigate through interactive elements on a web page such as links, buttons, input fields, etc. When an item is tabbed into, it has keyboard focus and can be activated or manipulated with the keyboard.
Target users
People that benefit the most from a keyboard-accessible website are physically or visually impaired people, screen-reader users, and power users. However, keyboard accessibility isn’t a feature for these specific groups of users. Keyboard accessibility benefits everyone. Developing a keyboard-accessible website means that we’re ensuring an inclusive and equal experience for all our users.
“Everyone is a keyboard user when eating with their mouse hand.”
— Adrian Roselli —
Web accessibility on the market
The requirements for web accessibility are very different from country to country. In the U.S., web accessibility is a must and has been stated in the Web Accessibility Law since 1973. In Europe, since 2019, the European Accessibility Act has been in effect. It requires all public websites to follow specific accessibility guidelines. Member states need to pass related laws by June 28, 2022, and ensure these accessibility measures are in place by June 28, 2025.
Therefore, we need to take accessibility, usability, inclusion, and user experience seriously and build a professional, user-friendly website that is approachable to everyone. We’re proud to join a club of products supporting keyboard accessibility.
What has been improved in our app?
Focus style
As people always say, the look is not everything, but it is important. Our old focus style wasn’t bad, but it was not always as clear as possible.
New focus style
We designed and implemented a brand new color style with better contrast that is noticeable on any background. The example below shows what we had before and how it has been improved.
On the left side, the play button has focus, but it’s really hard to notice because the focus style and the button have the same color. On the right side, we can see the focus colors work effectively with the background and the focused element’s color, and it’s clearer that the play button is currently focused.
Move focus to inner boundaries
Previously with our old focus style, we had many problems with cut edges because we used CSS box-shadow that grows outside of the element.
Once we changed our style to use box-shadow inset, those problems were completely solved, and the focused element looks clear as it should be.
Rounded buttons
We also changed the shape of our focus style from square to round for control buttons for better recognition. Those rounded-corner buttons look more attractive and appear easier on the eyes than a square with sharp edges like other regular UI.
Focus-trap in modal and dropdown menu
Focus trapping is important in web accessibility. When a modal shows up, or a dropdown menu is opened, the user should be able to navigate through all interactive elements only inside this modal.
Example of focus trap on modal:
Users can open the modal, but without focus-trap, keyboard navigation cannot reach the interactive elements inside the modal. So it just gets lost in the background.
Now with the focus trap, once the modal is opened, keyboard navigation will be trapped inside the modal as it should be.
Example of focus trap on dropdown menu:
Without focus-trap, keyboard navigation goes straight to other control buttons and completely ignores the opened dropdown menu.
Now with the focus trap, it’s easy to reach the dropdown menu for further interaction.
Skip navigation
The main content is normally not the first element of a website. To navigate to the content, users usually go through many other elements such as nav links, menu, etc., before they get there. In our case, they would have to press the tab key approximately 10 ~ 30 times to get to the main content.
We introduced skip links to help users navigate to certain main sections of our website. Skip links are the very first elements on our website, so once the user opens the website and starts keyboard navigation the first element they’ll tab into are our skip links, and from there they can jump straight to the main features without going through all the other links and buttons. We also did something special here, you might have noticed that I mentioned “skip links” in the plural form… Yes, we introduced not just one skip link like almost every other app, but we have four skip links in total, and we believe that makes the navigation experience way better than before. The following demo videos will show how users navigate using our skip links.
Skip to search
Skip to page navigation
Skip to main content
Skip to player
On-screen display controls and top panel unveiling on focus
When we implemented our skip links, we also considered the case that the section user wants to jump into is currently not visible, and we have to unveil them if the user wants to interact with them. For example:
The top panel (including search bar and cluster) is not always visible. Once the user scrolls down on a page, the top panel will be scrolled up and disappear. But if the user wants to navigate to search or page navigation, it should be visible again.
On-screen display controls are another good example. They’re not persistent while the player is playing and they’re supposed to stay dimmed if there’s no mouse interaction. But if the user jumps to the player by keyboard, the controls should all appear and persist until the user makes a choice or leaves the player.
Carousel & Marquee keyboard navigation
Many video content applications represent teaser collections as marquees and carousels.
Our carousel usually has a long list of teasers in a row. Therefore, to go from one category to another without any special rules for navigation implemented, users would have to press the tab key forever.
In Marquee, we have a shorter list, but the user still needs a lot of keypresses to go through it all. Besides, the focused teaser wasn’t always in the middle of the screen, and even though it is focused, it could not position itself in the middle for the user to see it fully.
So what we’ve done to improve this situation is that we allow the user to navigate through all teasers that are fully visible on screen. If they hit the edge, they can press the control button to see more or simply ignore it and immediately go to the next collection.
Teaser focus flow
As you might have noticed in the example for the previous state of keyboard navigation on the carousel above, our teaser’s focus flow was complicated. It took two to three unnecessary presses of the tab key to get to the next teaser.
Each of these three focusable elements on the teaser can do certain things, such as opening program details or playing the show, but we would rather keep it simple for users while still providing them with all functions that they expect to do. So they’re now able to go through each teaser card with just one tab press, if they press enter/return on the teaser, the program detail will be opened, and if the show is playable, the play button is always there and is reachable in a couple of tabs.
Disable focus interaction on the active element
When the user goes through the menu links or the page navigation, they might press Enter to make a choice. Once that item is chosen, it should not be focused on anymore because it is already chosen. Any further interaction with that active element will lead to the misunderstanding that we could still do something with it while we cannot. To avoid this confusion, we have disabled the ability to focus any active element in menus and navigation items.
Keyboard usage
Since we’re supporting keyboard accessibility, it would be great to know how often a user uses the keyboard to navigate the site. We developed our own product analytics tool that helps us understand whether the user uses a mouse or keyboard for further prioritization and development.
Summary
Web accessibility is essential for some and useful for all. This effort has brought our web application closer to every user and given them a more joyful experience with keyboard navigation.
These changes are just the beginning of a long journey of building an inclusive, impactful, and sustainable application. As the next steps, we plan to continue testing accessibility in our application, research more and continue to develop our product to be more accessible for everyone.
