Focus Trapping & Keyboard Shortcuts

[00:00:00]
>> So for some parts of user interfaces, we wanna keep the users focus in a certain area, and this is called a keyboard trap. And we don't wanna do it unintentionally, LAUGH] we wanna do this for certain components. Like if you're in a modal, that's a good use case.

[00:00:20]
Any kind of like new layer that comes over the top, like I've seen entire apps where it's all layers upon layers, upon layers. We wanna definitely keep users from going outside of that layer. And so that's what's called a keyboard trap. But it's sometimes it's unintentional, like have you ever tried to navigate code pen with a keyboard and you get into the text area, and you hit the Tab key, and it just keeps, you're in a text editor, you can't get out.

[00:00:46]
That's a tab trap. And you have to be kind of creative in how you set that up to not have that be a problem. So one thing you could do, just as like an authoring tool developer, would be to wire up the Escape key, or some way to get in and out of that edit mode so that keyboard users have a way to skip by it and they have a way to get in and out.

[00:01:08]
So keyboard traps. And there is a criterion in WCAG, it's Level A called no keyboard Traps. It has some great information on like what's acceptable and what's not. We just don't wanna do this unintentionally. So here is an example of what a keyboard trap looks, an intentional one.

[00:01:31]
So this stack blitz, I'm gonna open in a new window. So I've got a library in here called react-aria. Pretty awesome. It's a little bit of an advanced tool, I would say, but I can create what's called a FocusScope. So that's like the easiest focus trap I've ever seen.

[00:01:52]
It just it's a component that I can pull in, wrap it around the code that I want to contain at the right time. And I didn't even have to write the actual focus trap, but let's see how that works cuz we should know. So if I open this layer, there are some focus level items in here, there's a two inputs on a closed button.

[00:02:12]
So it's not styled really at all, but my focus just cycles between these controls. So between the inputs and the buttons. So you can imagine if this was in a new layer, it would be pretty effective at keeping my focus in that content. Let's see what it actually put into the page cuz that's pretty magical.

[00:02:37]
There's content next to it, though. That's really what I wanna look is there is an Open button and sure my keyboard focus was trapped, but can I get behind there somehow if it was a modal layer? If I was a screen reader user is the rest of the stuff all still reachable?

[00:02:56]
It probably is. So this element, that input is a div with all of our stuff in it, and I think it just has some JavaScript to cycle you around. So in our previous example, we got pretty nerdy with the inert attribute. This is another case where if you had a modal layer and you were creating a FocusScope, you could use inert on any background content to keep screen reader users from being able to reach back there, cuz right now, all we're doing is the JavaScript part.

[00:03:32]
But we're talking about focus, so it's relevant. But that's what a focus trap does, is it keeps you kinda in that set of components. And that's pretty easy to do, at least if you can use the react-aria FocusScope. There's probably other libraries, too, other utilities that you could pull in.

[00:03:53]
It looked like kind of observing their approach is that, they have elements before and after what we've inserted. And so that gives us some signposts for that. The code underneath this that makes that work, is whenever focus gets out of the items that you inserted, it just loops it around again.

[00:04:13]
They just kind of control where your focus goes and send it back. Question?
>> Actually, they shared a very cool tip in chat, if you open up Chrome DevTools and you hit the I, and then put in document.activeElement, that's a live expression, and you can see what element is actually active.

[00:04:40]
>> Cool. That's awesome.
>> So now as you move around, it'll just live update right there.
>> Sweet, that's cool. Yeah, I have seen that before, and I forgot about it. So thank you. Chrome DevTools is amazing. Cool, so focus traps. And yeah, it kind of gives us techniques that we can use to keep people from getting stuck behind those layers.

[00:05:15]
So do you need inert backgrounds? I think it really a good answer to this question is just a like how easy would it be to implement. It works best when you have a sibling. So say I have modal content, if it's buried in my content like it in the DOM somewhere, it's gonna be really hard to use a nerd because it's the modal content is amongst everything else.

[00:05:39]
Whereas if the the modal and say, main are siblings and there's some separation, I could put a nerd on the main element and that will keep that in the background, and then my modal will live separately. You just have to pay attention to where your content that needs to stay on top that should be reachable and accessible and trapped.

[00:06:01]
That should be not inert, [LAUGH] that's the stuff we wanna navigate with. So I think sometimes the keyboard trap can be enough. I think you really wanna test it in a screen reader. Yeah, it's like part of the story, but a worthy technique. Keyboard shortcuts. So let's talk briefly about keyboard shortcuts.

[00:06:34]
They can be helpful, so if you have UI actions, especially if the shortcut takes a lot more work than one a mouse user could do, like the accessible say you can do the same task, but it takes a bit more effort, a keyboard shortcut could be a good use case.

[00:06:51]
And we have quite a few built-in, like Cmd+F for finding, Cmd+P for print. Those are keyboard shortcuts that are built into the platform. Or Ctrl+ P on a Windows machine. But custom keyboard shortcuts can be useful in web apps. And so there are a couple of libraries that could make this easier.

[00:07:11]
There's one from Arthur Beaulieu and Jon Kuperman. And so you can check those out. They're both named shortcut.js, [LAUGH] popular name for that type of tool, but what that can help you do is manage meta keys. So if I have like combinations of keys, it takes a little bit of trickery to match that combination.

[00:07:36]
It's not impossible, but sometimes using a little utility makes it easier. And so, we can create those shortcuts. So there's two things that I want you to be aware of. One is that shortcuts need to be discoverable. If we put all this effort and, dev work into creating shortcuts that nobody knows about, it might be a little bit of a waste.

[00:08:00]
So, put them in your help documentation. I think Facebook had a cool approach at one point where they had an accessibility nav bar that would pop up at the top of the page when you started to use the keyboard. I don't know if it's still there, but some way to tell users that you have these keyboard shortcuts.

[00:08:22]
Like if there's a little help icon on the page or just like make them easy to find, cuz they're gonna be really niche and maybe not use that much otherwise, put them on your accessibility docs or on an accessibility statement. And then the other thing I want you to know about, keyboard shortcuts is watch out for conflicts with screen readers commands.

[00:08:41]
So especially on Windows, there are common key commands already in place, like the H key that will cycle through headings. So you don't wanna just use plain letters for your shortcuts, they need to be kind of unique. So yeah, just something to be aware of that they're like screen reader commands need to still work.