Keyboard functionality

- One of the most important requirements for accessibility is keyboard usage, why? Because this actually affects people with many different types of disabilities. When you make things accessible to use with a keyboard, you make it work for anyone who can't use a mouse. Some people like Maxine have mobility challenges or issues with dexterity. And some people like Mary can't see the screen and need to use a keyboard. You also make it accessible to people that use other assistive technologies like voice recognition software, switches or other devices. Remember, we don't have those technologies or disabilities represented in our personas, and that's okay. As you learn more, you'll create new personas that represent these functional needs in different ways. Here's the key principle to remember. You must be able to complete all tasks using a keyboard. Must, this is not optional. And it's the very first thing I test when I'm looking at a client site to see how accessible it is, and it should be the very first thing you look at too. The simplest way to understand it is to look at some examples. We've got an example here where I'll start to Tab through the page using the keyboard and you can see that I can access the things in the navigation. You can see that they're changing as I Tab through them. But when I make it to the next part or the main part of the page, you can see that the keyboard skipped over every block of content that's here. I can click on each one of these to select them with the mouse, but it requires the mouse. There's no keyboard mechanism for me to be able to do this. So as I Tab through, you can see the Tab focus goes straight from the navigation, down to the Request a Quote button at the bottom. In this version of the page, we've actually enabled all the keyboard navigation that we need. So as I Tab through, I Tab through the navigation, and I get to the main content. And I can use my arrow keys to move between these blocks of content. And I can Tab off of that block and onto the Request a Quote button. This was a simple case of not using the right element. When the site was built, it was built using divs with JavaScript attached to them. You can't Tab to a div by default. Sure, the JavaScript made the click actions happen, but only for a mouse user. The solution was to use something that was focusable in the first place, a simple link. And then attaching the JavaScript to the link instead of to a div. From a design perspective, the why behind it doesn't matter so much, but you as a designer are in charge of making sure that you take inventory of all functionality available to a mouse user, and then ensuring there's an equivalent keyboard mechanism. Let's look at a more complex example. The main functionality on this page is a map. And there's a lot of different controls on it that I can click. I can pan up, pan down, pan left, pan right multiple times. I can recenter the map. I can zoom in, zoom out, and I even have little flags available that tell me some data about each pin on the map when I click on it. So in order to make sure that we're providing equal functionality for all different users, we need to make sure that all of that functionality is available for somebody using a keyboard. We can do that quite easily by making sure that each one of the controls that we clicked on with the mouse is a simple button. So as I Tab through the interface, we'll take the focus down into the map. You can see as I use the keyboard, each control inside the map takes the focus. Right now, you can see that it's on pan up. And if I hit the Enter key, it pans up. If I hit Tab, I move to pan left. The Enter key will pan left, hit Tab to center, to pan right, to pan down, all of those work with the keyboard. If I continue on, I should get to the zoom in control which I can activate using the keyboard. I can also zoom out using the keyboard. All of that functionality was equivalent to what is provided for a mouse user. But we've actually gone to the point of making this even a little bit better for a keyboard user. A mouse user has the ability to drag the map and move it fairly easily within the interface. It's not quite that simple to do drag and drop for a keyboard user. But what we have done, is enabled some really simple navigation techniques. So if I Tab through the interface, you'll see that the map as a whole takes the focus. And you can tell by that big, blue focus outline around it. We've also set this up so that when the map takes the focus, I can use the arrow keys to pan left, pan right, pan up, pan down, and I can use the plus key to zoom in and the minus key to zoom out. So as you can see, we've created the exact same functionality for a keyboard user that a mouse user has. The final piece of the puzzle was all of these little pins within the map that have a mouse click on them that show some data about that pin. Unfortunately, with Google Maps, there's no way to use the keyboard to get at each of those pins. If I Tab through the interface, you'll see that I can go through all of the other components that are there, but the focus never gets to those pins themselves. So in order to make sure that people have access to that data that's in those little call-outs, that show when we click on the pins, we've replicated all of that information down below the map so that somebody that's a keyboard user can get at it and not have to rely on the mouse. One thing to keep in mind. Making sure that we can do everything with the keyboard doesn't mean that we need to be able to Tab to all of the content. Some people often misinterpret. You need to be able to do everything with the keyboard and make every single paragraph of text on the page tabbable, that's not the case. Just focus on the function of the interface, and carefully think through how you'll accomplish every task with a keyboard. Links, buttons and form fields are your friends here. They've got all the keyboard access you need built right in. So use those elements and you'll be in good shape. And if you have to create a custom element, try to base it off of those simple elements that are already keyboard-accessible. The map controls are just button elements. The thumb on the podcast player is just an anchor element. There's rarely a case where you need to use a div. So stick with simple elements and you'll make things keyboard-accessible by default.