Keyboard Navigation Deep Dive | Webinar Video

Hello everyone. Good afternoon. So today going to talk you through a deep dive of keyboard navigation.

To start, what exactly does keyboard navigation refer to? There’s a couple different components of it, primarily navigating through interactive components using your keyboard only, so no use of the mouse, and not only navigating through them, but interacting with those components. So for example, activating a button, filling out form fields, etc. And then the last part of this is going to be the logical and predictable focus order. So as you’re navigating through you want to make sure that the focus order for the keyboard is matching not just a logical and predictable focus order, but what you have presented on the screen.

Who benefits from this, primarily users with disabilities. So if they have a disability that affects mobility, or if they’re a blind or low vision user, they may be using a screen reader or an external keyboard that is really critical for keyboard focus and navigation is really critical for those users to ensure that they can interact with all of your components and user flows on your website. And then beyond that, everyone benefits from this.

Some people may prefer keyboard shortcuts or keyboard navigation. Imagine you’re navigating through a field or a lot of form fields, and you don’t want to keep clicking with your mouse tab right through it makes it a lot quicker to go through your form. So there’s benefits for everyone around.

Beyond just the navigation, keyboard focus is a huge part of this. As you’re navigating through with your keyboard, you need to make sure that there’s a visible indication of focus. This makes sure that people can tell where the focus is visually on the page, and then which one is going to be activated when you use enter or spacebar. So for example, we have an image here of a form field for a page URL, and there’s a blue focus state that indicates that that’s the component that’s going to be interacted with if you use more keys than just tab on your keyboard. So you can fill it out, you can hit enter, you can tab to the next one, etc.

And then more, beyond just navigation, is touching back on this focus order. So as I mentioned before, it should be logical and predictable in sequence, which is usually the same order as it’s visually presented. So here we have an example of three components. They’re vertically oriented. And as you see, our keyboard helper is showing that they go, 123, right in the order left to right as visually presented. So I’ll get into that more. What you can use from our helper tools to help you test manually for keyboard navigation.

And then keyboard traps. This is really important, barring one exception, which I’ll get into, you should never have a keyboard trap on your website. If keyboard focus is trapped, then a user can’t explore any other area or complete the task at hand. The one exception is modals. So when you open up a modal, not only should keyboard focus move directly into that modal content, as it should be blocking most of the page and usually is, but it should be trapped in that modal. So imagine you have a modal that appears, if keyboard focus isn’t trapped, you could end up in sub menus or content on the main page, and make it really difficult to interact with the components within the modal, which is what’s of focus at the moment. And then when you close out a modal, keyboard focus should no longer be trapped, and it should return directly to the component that exposed that content.

Testing for keyboard navigation. This is one where you have to manually test for it. So like I mentioned before, we do have a tool in our guided manual WCAG audit tool that helps you visualize this focus order. And this can be really helpful, especially if you’re running into focus order issues where components that are not visible are receiving keyboard focus. For example, a collapsed submenu, it may be receiving keyboard focus as you tap through, but there’s no way to visualize that. Using our helper tool, it’ll visualize that focus order for you, and you’ll see it jumping around one, two, and then maybe 345, to visually hidden components so that can help you identify the areas where things that aren’t supposed to be receiving focus are, and then also if the visible components are receiving them in the correct and logical sequence.

How can we help. We have several solutions that can help you out with this. Our web accessibility software tools will help you automate this process. But like I said, keyboard nav is mainly manual, so you definitely would want to use our tool and focus on our accessibility audits and our consulting. So from there, a specialist could help support you in testing for this, or you could use our helper. And then we also offer a VPAT, so if everything on your page is keyboard accessible, you’d have a supports right in that row, and it would reflect that you’ve resolved all keyboard navigation issues on your website.