DesignDesigning for keyboard accessibilityWritten by Emil Sjölander on 2020-02-29

By now I hope a lot of us developing apps know the reasons for, and benefits of, thinking of accessibility when designing the apps we build. To re-iterate two big ones. Firstly, making our applications accessible to a wider range of people is the right thing to do, otherwise we are shutting a portion of the population out of using our tools. Visly is all about making it easier to create apps, so in our case not being accessible would be the same thing as saying that some people should not be part of the creative process. Secondly, by designing with accessibility in mind we dramatically increase the market which our tools serve, there are a lot more people than you may think who benefit from accessible products, and there are an increasing amount of companies who refuse to purchase and mandate software which isn't accessible.

There have been a ton of great articles focusing on the above two points and I don't think I would be able to add a lot more value by discussing them further here. I want to be clear I think the above points are the most important and something we should all take into account when building apps, and we still have a ways to go to ensure Visly is fully accessible (please report a bug if it isn't!).

What I want to focus on in this article is a third reason for spending time on accessibility. Winning over the hearts and minds of "pro" users.

Pro users

I categorise a "pro" user as someone who is always looking to improve their output and performance. They constantly strive to make more efficient use of their tools. Most creatives, such as designers and developers, fall into this category as they want their tools to "disappear" so they can focus on their craft.

This category is nothing new and actually people have been designing software for this segment of users since the dawn of software. However, in the late 2000s and until recently, software design went through an era of simplification as the majority of the world population came online and started to interact with software every hour (minute?) of the day. This democratisation of software knowledge has been incredibly valuable, however some of the people who we classify as "pro" users weren't happy that their tools didn't allow them to move faster. We refer to this as a skill cap, a cap on how skilled a person can get using your tool.

This brings us into the renaissance of pro workflows happening right now, which the industry is calling the prosumer category. Essentially this means building tools with a much higher skill cap. Here we have tools such as LinearSuperhuman, and Cron which are betting that a lot more people then we originally thought are looking for ways to level up their productivity. I 100% agree and that's a bet we are making with Visly as well.

Here are some good things to think about, as well as design patterns to implement which serve this underserved market of people who are looking to become more productive with their tools.

Focus that looks good

Let's start with a simple one which is overlooked all too often. Focus. A first and very simple step to making your app keyboard accessible is to implement focus states for your elements. Some apps choose to re-implement focus management using custom application state, in very complex application this can be the right choice but for most apps out there you can just rely on the built in browser :focus state. If you're building a web-based application this makes styling focus states incredibly easy.

All too often we see people disabling focus states on elements because the default styling honestly doesn't look very good. Focus states aren't any different from other states in your app; they are something you have full control over styling yourself and can be made to fit into and enhance the experience of your application.

.dont_do_this:focus {
  outline: none; /* Removes ugly blue border. FIXME: accessibility */
}

A great first step is usually just to add a bright border to focused elements using plain css.

.className:focus {
   outline: none;
   border: 1px solid var(--color-focus);
}

or using something like styled-components.

const MyComponent = styled.div`
  :focus {
    outline: none;
    border: 1px solid var(--color-focus);
  }
`

Once you have focus in place just make sure all interactive elements have a tabIndexset and that tabbing around your app focuses things in the correct order. Once you have a visible focus state for elements, this part if usually pretty easy.

You will also want to make sure to handle keyboard input on the focused elements. For example using arrowleft and arrowright keyboard events to change the value of sliders and radio groups when they are focused. This isn't something you get for free. I usually like to disconnect my mouse and force myself to use our application with only the keyboard to ensure I didn't miss anything.

Enhance with animation

One huge benefit of mouse, as well as touch-based, interactions is that it is, or at least should be, super clear what is going on: I drag an item from one position to another. When doing the same using a keyboard-driven interface, what's happening sometimes gets confusing. This is because you are giving the software an instruction of what action to perform rather than showing the software exactly what you want to do, as you do with a drag-and-drop based interactions. This is made even more complicated when you have many similar keyboard shortcuts, as they can be easy to mix up. By introducing a tiny bit of animation to keyboard actions, we're able to show the user exactly what happened. And if they regret that action, they should, of course, be able to rely on cmd+z to undo the last command.

Quick actions

This is a design pattern previously popularised by tools such as Alfred, and more recently by Superhuman. The idea is to take the concept of a menu system and supercharge it with search functionality. Instead of hunting through menus and submenus, you can just start typing to get what you want. The most common actions will have associated keyboard shortcuts so you don't even need to open the quick action menu. Over time you'll learn more and more of these shortcuts and fly through tasks where previously you got stuck with click through menus.

Importantly, this quick actions menu should not be seen as an overflow menu where you can put things which don't fit in well visually within the UI. The quick action pattern should be seen as a way for the people using your app to level up their skill level by gradually moving from clicking UI elements with a mouse, to doing more things via the quick actions with their keyboard. The key word here is gradually. This means the UI and the quick actions menu should for the most part contain all the same actions and allow the user to both intuitively find what they want to do in the UI as well as quickly get to it from their keyboard.

Quick actions are not only great for keyboard accessibility, but they're also a fantastic way to add experimental features which aren't ready the be added to the UI just yet. At Visly we also add some hidden quick actions which don't even show up in the auto-complete dialog which we can use for debugging 🤫.

Help people level up

Lastly, it's important that you help the user along as they are trying to improve their usage of your tool. Give them hints in the UI letting them know about available keyboard shortcuts and other more advanced features. Something you do not want is to pop up a ten page tutorial which tries to teach the user every single feature and keyboard shortcut. The whole point of the work we have done up until this point is to enable the user to gradually move from being a first time user of your product to a "pro" user. By reminding the user in a non-intrusive way of keyboard shortcuts from time to time you can help them level up more quickly.

A keyboard culture

While building frameworks, creating designs, and writing tests are important aspects of keeping your application keyboard accessible. Your most impactful change is to make accessibility a core part of your company culture and product philosophy. At Visly, missing keyboard interactions aren't filed as features or enhancements to be done sometime in the future: they are filed as bugs and treated with urgency.

If you find any part of Visly which is not keyboard accessible or where the keyboard shortcuts just don't make sense, shoot me an email. This is a top priority for us to ensure you feel as productive as possible and so millions more can benefit from using Visly.

If you have any questions about Visly or comments on the article please reach out either over email or twitter. If you are excited to give Visly a try then please request access.

Using React to build a complex front-end? Visly is for you.

Request access now