A story of keys, focus and no mouse

01‑02‑2018 Daniël van Leeuwen 6 min.

Have you ever had that moment when you want to 'tab' to the next item on a webpage and nothing happens? The page doesn’t have a focus indicator, so you sigh, grab your mouse, and move the cursor; a minor annoyance you forget in the next microsecond. Now imagine you experience this about a thousand times a day for a living. Your minor annoyance has quickly accumulated a compound interest of epic proportions that makes you surrender all reason and sanity. That or you are a little irritated that your work is slowed down by this seemingly minor design issue.

Whether you relate more with former or the latter (I hope the latter), it’s an issue we don’t allow at Moxio. To ensure this stays that way yours truly has worked on a few improvements to Moxio’s accessibility. The user expects more options to navigate besides the mouse and during my internship at Moxio that’s exactly what I delivered. In this blog I will convey the what, how and why of these improvements. 

Research – finding the magic

My first step was researching the possible alternatives for mouse navigation. These alternatives also had to fit with Moxio and its users so an analysis of Moxio and its users were made. To start I made a list of all possibilities with the only benchmarks that they can perform the duties of a mouse. This provided a list of some unlikely candidates who would be quickly eliminated. Candidates like:

  • Voice control
  • Touchscreen
  • Eye tracking
  • Keyboard
  • Smartphone wireless mouse
  • Joystick

Some of these sound ridiculous to consider for an office environment and, truth be told, they are. Can you imagine your colleagues talking to their computer all day? However, researching these different alternatives gave me more insight in the needs and possible solutions of navigation. After that I started to filter the list with help of three parameters Moxio had set for the alternative to adhere to:

  • It’s a solution upon which can be expanded.
  • It doesn’t require new hardware or software.
  • It doesn’t take away functions of the existing navigation (the mouse)

After extensive research and considering the set criteria I came to the conclusion that the keyboard was the best option. It met all of Moxio’s criteria and most of the criteria I drafted to score the solution. An added benefit is that keyboard navigiation is well known by the user and, in the case of Moxio, had a lot of unused potential.

Since many users use many different aspects of the Moxio’s applications I decided that my solution had to apply to the whole navigation and not just to a specific few. Where there is smoke there is fire and no doubt users in different roles experience similar problems in different locations.

Prototyping - four cases of keyboard navigation

I designed and built four features to improve the navigation with a keyboard. Two are more custom and would contribute little improvement to other applications. The other two are industry standards when it comes to keyboard navigation. So without further ado the features are:

  • Tab indicator - This way the user knows where the current focus is on the page.
  • Panel navigation (custom) - Navigating the panels in the application more quickly.
  • "Skip to" menu (custom) - A menu of anchor links that transfers focus to different places on the page.
  • Hotkeys - Key bindings that execute specific functions to make navigation more efficient.

These four features combined provide the user all the tools required to navigate with a keyboard wherever they are in the application. To test these features I built small prototypes or MVP’s (minimal viable products). The MVP’s are divided between low-fidelity and high-fidelity. The low variant tests the functionality of a feature for which I used paper prototyping. The high-fi variant tests the technical side of things and is built with HTML and JS. I used the development method of LEAN-UX to ensure no subconscious design decisions were made in the building of the MVP. The LEAN-UX also ensured that I could build a MVP with minimal effort, and was able to test and improve it in short iterating cycles.

Tab indicator – showing focus

First step was giving the HTML elements an indicator that was missing in the current version of the application. Users could use the tab key with the absence of an indicator, but to minimal effect . Since a lot of my other ideas depended on it this was my first implementation. For the indicator I made several distinctions of how it was visualized. The focus was either indicated with a change of background color or with a border. Larger elements received a border and smaller elements like links and buttons received a change of background color. Elements like custom radio buttons and checkboxes needed new SVG files dedicated for the focus. Now the application is navigable with the tab and focus indicator.

Panel navigation - a thousand and one elements

With the tab indicator implemented, the second problem presented itself: the enormity of elements present on a page. Moxio divides its contents in panels that each contain dozens of elements. Tabbing through these elements is somewhat discouraging if you need to be on the other end of a page.

In my solution I divided groups of elements in div’s where all its element children received a tab index of minus 1.This way a div’s children elements cannot be focused. The div however can and as soon as a div receives focus it receives a dotted border as an indicator. With the enter key the user can move the focus inside the div and reach the elements inside it. To leave a div the user has to use the Escape button. This way a user can reach locations in the page more quickly and lessen the use of the mouse. 

“Skip to” menu – Press here to skip

Even with the panel navigation there is still a lot to navigate through and therefore the “skip to” menu was called into life. It’s a hidden menu in the left corner of the page that only appears when it receives tab focus. The menu has links that move the focus to points in the page. These links are different depending on the page the user is on, but an example of the links you could come across are:

  • Go to panels
  • Go to main menu
  • Go to header
  • Go to map
  • Go to toolbar

You need to quickly go to the end section of a page? You can use the “skip to” menu to quickly go there.

Hotkeys – a key for everybody

My fourth and final addition were hotkeys. During my preparations I conducted some research in the use of the application to determine user behavior. This way I identified regularly used functions in the application. I bound these functions to a hotkey to facilitate a function more quickly. Depending on the function it either opens a link, moves the focus or executes a function.

Help inform the user – explaining the magic

These features are all very nice, but how do I inform the user of these new features? This was my last and final addition (disregarding all the paperwork for my internship). I decided to inform the user in two ways: tooltips and a help menu. The tooltips serve to make the user aware of and remind the user of the fact that there is an alternative to the mouse. While a user does their regular work and hovers over a button a tooltip will appear with info about a hotkey. This way they are regularly reminded and if they forget the information they can quickly look it up. The help menu goes in more details and explains the somewhat more advanced features like the panel navigation or the “skip to” menu.

Some of the challenges I faced

This assignment offered challenges too numerous to write down, some formed out of inexperience, some out of changes in the situation. I however learned from them all and managed to adjust my trajectory accordingly to safely continue on my way. 

Mouse interference – those pesky mice

The panel solution worked great when people stuck to the keyboard but when they switched to mouse the “exit” or “enter” of a panel was not registered. This way a panel stayed open or closed when a user switched to the mouse. Adjustments had to be made in the code so that users could seamlessly switch between appliances.  This was a hurdle that required a lot of changes to accommodate every eventuality and was a true learning experience for me.

Tooltip – no room? No problem!

The problem with the tooltip solution is that it assumes that there is no tooltip present at the moment.
In many cases however there is. This issue is one of the assumptions made for which Lean-UX has guarded me. Without Lean-UX the realization that tooltips were already present would have come at a much later timing, which could have led to a lot of wasted time and work. The solution was quite simple. A separate area is created that contains the information regarding the navigation. A colleague at Moxio (Hannah Heemskerk) designed an addition to the regular tooltip that can be implemented in a later stage.

“A function too many, a key too few”

Certain functions like the “comment” button are rendered multiple times, which makes it difficult to assign a key binding. You don’t know beforehand how many there are rendered. My solution was to integrate the hotkey in the panel navigation. Only when a panel was selected you could for example leave a comment with a hotkey. This way we know which of the X number of comment functions the user wants to use with a hotkey.

The end – for now

In the end I presented my solution to Moxio as a possibility to improve accessibility in their application. It’s now up to Moxio to determine how and what they want to implement.  It was an interesting assignment with a combination of disciplines that usually aren't combined in one single assignment.  A challenge I thoroughly enjoyed and would recommend to any aspiring intern!

Moxio Stage

Deel deze blog