Join Natalie Garza and Natalie MacLees on the AAArdvark Accessibility Podcast as they discuss the importance of keyboard accessibility in web design. The episode highlights why some users rely on keyboards instead of mice or touchscreens and provides key insights and practical tips for ensuring websites are fully navigable via keyboard. Topics covered include the importance of using semantic HTML, testing custom components thoroughly, and understanding native keyboard interactions.
Natalie Garza: Hello everybody, and welcome to the AAArdvark Accessibility Podcast. I’m Natalie Garza, I’m one of the co-hosts, and with me today is,
Natalie MacLees: Natalie MacLees, the other co-host.
Natalie Garza: and she is a digital accessibility expert here to answer our questions on today’s topic, which is keyboard accessibility 101, the basics you can’t ignore.
So we’re gonna talk about why keyboard accessibility is important and some key notes on when you’re testing for keyboard navigation on your website.
Why Keyboard Accessibility Matters
So why doesn’t everyone just use a mouse or tap on their phones to navigate a website? Why keyboards?
Natalie MacLees: Well, not everybody can do that. Not everybody has hands. Not everybody has hands that they can move. So we have lots of different cases where people aren’t able to use a mouse or a touchscreen reliably.
So sometimes it’s limited mobility. Sometimes it can be cognitive disorders or fine motor control issues. Like you can move your hand, but you don’t have a lot of control over exactly where it goes.
If you have no vision or limited vision, you can’t see where a mouse cursor is on a screen and you can’t tell where to tap on a touch screen so you don’t have any other option other than to use a keyboard to navigate around the screen, and also sometimes just power users don’t wanna move their hand off the keyboard.
They’re going too fast. They’re setting their keyboard on fire, just going through too fast. No time to move your hand over to the mouse.
Natalie Garza: Yeah. Even everyday users like you use Control-C, Control-V to copy/paste. I’m sure a lot of people do. That’s a form of keyboard navigation too.
Natalie MacLees: Yeah, which, you know, you could do that with your mouse. You could right-click with your mouse and say copy and paste, but you could also do it with your keyboard. So anything you can do with a mouse, you can do with a keyboard.
Natalie Garza: And a lot of assistive devices, although they don’t look like keyboards, they fall under the same category as keyboards.
Natalie MacLees: They get treated as a keyboard by the computer. Yeah. As far as the computer is concerned, it’s a keyboard that’s attached. The computer can’t tell the difference.
Natalie Garza: Exactly. Alright, so that’s why keyboard and navigation are so important.
Ensuring Keyboard Accessibility on Your Website
So how do we translate that into our website? How can we make sure that people using only keyboards can access everything on a site?
Natalie MacLees: Yeah, we have to make sure that we’re not building anything that only works with a mouse. And where that usually happens is when we’re building custom components and not using semantic HTML. So the easiest fix is to just always use semantic HTML.
Whenever you can, you wanna try to do that, and HTML has gotten to be a lot more robust, a lot more powerful than it used to be. So we have a lot more options. Like you can build now native date pickers and time pickers, for example. You do not have to code that all up in JavaScript.
And there’s lots of other options. There’s range sliders and different things like that that are built in to HTML and do not have to be built custom.
You may still run into cases where you have a complex interaction or something that needs to be really custom to what you’re doing, you might find a case where you do have to build a completely custom component. In that case, you do wanna make sure that you are testing extensively with the keyboard and ensuring that you are adding in all of the interactions that the native HTML element would support.
It’s really easy to forget one, and then it just ruins it for everybody. So you wanna be really careful that you’re thorough about your testing and that you’re covering all of that functionality. And that people can close things and open things, and toggle things on or off, and switch between different selections, and I think where a lot of developers run into trouble is they don’t even actually know what all of the native keyboard functionality is of a native HTML control.
And then if you don’t know what all of the native keyboard functionality is, you can’t rebuild it. So do some research and make sure that you’re aware of all the keyboard interactions that users are gonna expect to be able to do, and make sure that you’re handling all of those with your custom JavaScript and CSS.
Natalie Garza: Does that mean like going back, going forward, selecting? Is that what you mean?
Natalie MacLees: Yeah, all of the different things that users can do. Like a lot of people don’t realize that when you open a select dropdown, for example, you can hit the Escape key to close it out and just move on to the next thing. And so that gets forgotten a lot of the time.
That Escape key gets forgotten a lot. And the Escape key is supported on several different native things. So you wanna just make sure that you’re aware of what all those interactions are, and when users would use the Tab key, when they would use the arrow keys, when they would use a Space Bar, and when they would use an Enter key.
So those are the main keys that you would generally use to interact with a component, and you need to understand how all of those work with the different components and how users are going to expect them to work.
Testing and Best Practices for Keyboard Navigation
Natalie Garza: Okay. So that was a very developer-y technical answer. Do you have a simplified, high-level answer for maybe the website owner or maybe a designer?
Natalie MacLees: Yeah, I think anybody could test something for keyboard. It’s just the same thing, like you just have to become aware of how would I do this?
(WCAG 2.1.1 Keyboard: All functionality must be operable using a keyboard alone, with some exceptions)
Because if you are able to use a mouse, you might not even realize that you could fill out a form on a website without touching your mouse. You may not even know that that’s a possibility.
So I think just to learn how you would do that, which it’s pretty straightforward, right? It’s Tab to move forward. Shift-Tab to move back, usually arrow keys to move between choices. So for example, a set of radio buttons you would use, the arrow keys you can use either left and right or up and down to move between choices.
Usually, you use the Space Bar to activate or push a button, and usually you use the Enter key to submit a form and sometimes also to activate a link or to activate a button.
So once you kind of know all those things, and then if there’s anything that opens, like a dropdown, you should be able to hit the Escape key to close it. If a modal, a dropdown, or something like that opens, you should be able to hit Escape to get out and close that up so that you don’t have to look at it anymore.
And if you know those basic interactions, you should be able to test and go through and make sure all of that is working on whatever you’re working on.
Natalie Garza: Hmm. So, this is a summary, and correct me if I missed any:
- You should be able to get to all the important components like buttons, links, and forms.
- You can’t get trapped once you go down a certain path on the page, and
- you can see where the focus is.
Natalie MacLees: Yes, you should be able to see where the focus is. That’s a good thing that I didn’t mention. As you’re tabbing through a page, you should be able to tell where you are.
Natalie Garza: Okay, so we have keyboard navigation and input, and we have a few little details that you need to keep in mind whenever you’re testing with a keyboard. So what are some things that we should keep in mind?
Natalie MacLees: Sure. So, like we already touched on, you should be able to get to everything with the keyboard. So there shouldn’t be anything on the page that you can’t Tab to, to interact with.
You should make sure that your focus never gets trapped anywhere. Sometimes that happens with things like media players, where once you kind of Tab into it, you cannot get back out. Just make sure that you don’t have anything like that happening as you Tab through the page.
The Tabs should move you through the page in a predictable way, so you shouldn’t be suddenly surprised, right? You shouldn’t go from the header down to the footer and then back up, and then over to the sidebar, and then back to the main. It should be very predictable, right? Like if you’re in a left-to-right language, it should start at the top and roughly move left to right, left to right, left to right down the page in a way that makes sense.
It can be really helpful to have skip links to skip over things that might be tedious. So if you have a huge navigation with a hundred links in it, have a link before that to skip over it so that if I don’t actually wanna use the navigation, I don’t have to hit Tab a hundred times to get past it.
And then we also wanna be thoughtful that I can get to all of the functionality. So anything that a mouse user can do, there’s a way for me to do it with a keyboard and ideally in the ways that I would expect that interaction to happen. So like we said, with the Space Bar, the arrow keys, the Tab keys, the Enter key, Escape key should all work the way that I expect them to.
Visual Feedback and Focus Styles
Natalie Garza: Yeah, so that’s the main details when navigating the keyboard. But then, whenever you use a keyboard alone, there’s also the visual feedback that you have to have. Otherwise, you don’t know where you are on the page.
Natalie MacLees: Yes, and designers love to put CSS that says “outline: none” because they don’t like it to look, they don’t like to have a dotted outline around a button or a link. After they click it with their mouse, you can adjust the CSS so that you don’t get the mouse dotted line, but you still get the dotted line when you’re using the Tab with keyboard.
So make sure that it is there. You need to be able to see as you’re tabbing down the page, where are you? So that if I hit Enter, if I hit the Space Bar, I know what control I’m activating.
Natalie Garza: Yeah, and they, I think it looks pretty nice if you can make it match your design, like there’s CSS for helping you match, like the brand colors for if you wanna do like a dotted line or a little fine line, at least just showing where you are. That’s the most important part.
Natalie MacLees: Yeah, you can get pretty creative with your focus styles. You don’t wanna get too creative so that people don’t understand what it is.
But there’s all different kinds of things you can do, like by default browsers use an outline, but you can also use shadows and glow, and style that outline as dots or dashes or rounded corners, or not rounded corners like any color you want.
Like there’s lots of stuff you can do make sure that your focused style is on brand with the rest of your design.
Natalie Garza: Yeah, just like you can go crazy with the hover styles for a mouse. You can go crazy with the keyboard focus styles and actually make them look pretty nice and cool.
Natalie MacLees: Yeah. Yeah. And they can fit right in and not be something that you’re trying to hide.
Resources and Tools for Keyboard Accessibility
Natalie Garza: Exactly. So that is keyboard accessibility 101. You guys make sure you can navigate to everything and use everything the same way you would with a mouse or your touchscreen, with a keyboard alone. So. Where can people learn more about keyboard accessibility, specifically the criterion around them?
Natalie MacLees: Yeah, so on the AAArdvark website we have a resource called WCAG in Plain English or W-C-A-G in Plain English, depending on how you like to pronounce that. That’s the Web Content Accessibility Guidelines spelled out in plain English.
So if you’re a beginner and you’ve taken a look at the official documentation and found it to be kind of confusing, a little dense, a little hard to understand, WCAG in Plain English is a nice place to get started to kind of get those basics under your belt, in a nice user-friendly way with lots of examples.
So you can come on over and try that out at AAArdvarkAccessibility.com.
Natalie Garza: Yeah, and you can also sort by the theme of keyboards, which gives you 16 criteria that all affect keyboard navigation and how they look and so on. So go check out WCAG in Plain English. And where can people check their websites for keyboard navigation accessibility?
Natalie MacLees: Yeah, if you wanna also come to AAArdvarkAccessibility.com, you can sign up for an account and for free you can test your homepage. You can find all of the issues that we can find automatically on your homepage. Learn how to get those fixed, and you can also conduct your manual testing and find any issues that we can’t find automatically.
Natalie Garza: Exactly. ’cause anybody can really test keyboard accessibility. It’s pretty straightforward.
Natalie MacLees: It’s pretty straightforward. Yeah. You just have to learn the few little keys that you gotta keep track of.
Natalie Garza: Mm-hmm. All right, so go check out AAArdvark. And with that we’re gonna wrap up episode 33 of the AAArdvark Accessibility Podcast. Thank you guys for joining us, and we will talk to y’all next time.
