Enterprise Web App Accessibility (feat. React)

Managing Focus in Interactive Components

Marcy Sutton Todd

Marcy Sutton Todd

Principle Studios
Enterprise Web App Accessibility (feat. React)

Check out a free preview of the full Enterprise Web App Accessibility (feat. React) course

The "Managing Focus in Interactive Components" Lesson is part of the full, Enterprise Web App Accessibility (feat. React) course featured in this preview video. Here's what you'd learn in this lesson:

Marcy discusses managing focus in interactive components, particularly in client-rendered applications. They mention the importance of keyboard support and suggest trying to use the keyboard instead of the mouse for a day each week to identify accessibility issues. The lesson also covers common patterns for focus management, such as modals, view changes, focus scopes, and focus trapping. The instructor also introduces the concept of FocusVisible, a pseudo class that helps differentiate between keyboard and mouse focus.


Transcript from the "Managing Focus in Interactive Components" Lesson

>> All right, let's talk about managing focus in interactive components, coz that's a lot of what we're building in these client-rendered applications. And a lot of these need attention for the keyboard. It's so cool when there is support for the keyboard. So try ditching your mouse for a day each week as a regular workflow step.

And see if you can highlight accessibility problems. I bet you'll find all kinds of issues just by having the team regularly ditch your mouse for a week. Have no mouse Mondays or something. Could be very effective. So some common patterns to look out for. We talked about some of these in the HTML context of things, but in terms of focus management, modals and view changes are a big one.

When those layers open, we have to move focus into them and put it back when they close. We also have to prevent interaction in the background using things like focus scopes and focus trapping, that we use very intentionally and not by accident, tab switchers and date pickers. We talked a little bit about roving tab index, that's when you manage tab index so that only one element in a group is flexible at a time.

And you use scripting to move it around. I have a link in here for that. We covered it in the web app workshop a little bit more. But those are common patterns, and sometimes those, when you do create that one focusable control with roving tab index, that's when the arrow keys come in.

And we saw how to target the arrow keys with the event object in our events. When you're adding and deleting items, that's one, and we saw a widget that, I think multiple widgets today, that when the node goes away, because that state condition isn't met in JSX anymore and react.

If you're focused on that element, it just kind of goes poof. When you delete an item, it's basically doing the same thing, so we have to manage focus to send it back somewhere. I've got a question.
>> What is focus trapping?
>> Focus trapping, let me think of the best example to show.

Maybe the one from the other workshop. Yeah. I didn't think about that. Let's look at our source slides, look very familiar, don't they? Let's go to focus management, keyboard trapping. So I have an example here in, using the focus scope I mentioned, it's from a library called React ARIA.

So we'll see a very stripped down example here. So I've got, and I'll actually, let's open this a little bit bigger. So on StackBlitz, I've got this focus scope. So on this page, it has a button. And when I click that button, it shows and hides, or at least shows, another set of components.

So it's pretty basic. This could be an immortal. Maybe these new elements would be on top of everything, and there would be a grayed-out background. But when I tab in here, my focus cycle is between. So I'm being trapped. And we don't wanna do this by accident, [LAUGH] Where I've seen that happen is, I mean, maybe even here on StackBlitz.

If I try to tab, well, first of all, I'm trapped because the focus scope is that good at what it does. I can't even get out. [LAUGH] But if I tab through StackBlitz, let's see what happens when I get to the text editor portion. This is a focus trap right here.

This is an unintentional focus trap. So, I finally got out. Maybe it wasn't quite a focus trap, it was close. Let's see. Here we go. Here's a focus strap. I'm hitting tab. See how it just keeps moving the content? I can't get out of it. I can't get past it.

So there's intentional and unintentional. The unintentional ones are the ones that are WCAG violations, because you can't do anything. So what they need to do for StackBlitz, or CodePen, or anything like that is give me an edit mode and a button. Let me tab onto that button, go into edit mode, then do this, hit Escape or something to get back out.

Whereas over here, this example, I can skip by the stuff when it's not active, say it's in a modal, and I can trap it at the right time, and then turn it off when I'm done. So that's kind of how we do it on purpose. [LAUGH] Is put it in something.

So in my react here, I have this only happening when the is open state variable is truthy. And so, yeah, it's a great question.
>> Another question. How would you manage focus in and out of an iframe?
>> I know, iframes are my nemesis.
>> [LAUGH]
>> They are hard.

So iframes, when you have third party content that loads into an iframe, you are responsible for it. Even though you can't do anything about it. So, the accessibility issues that get iframed in, yeah, guess who's, if you get sued for something, that's in scope. So, that's troubling. But, I think you should be able to just seamlessly tab into the iframe, I believe.

Honestly, I try to do everything I can to avoid iframes, [LAUGH] Cuz they're very hard, but I think, yeah, it's part of the overall what gets rendered. So think about the user experience is that it's part of the page, it's part of what they're gonna tap into. It's kind of they don't care if it's in an iframe or not.

It's on the page and if I can get into it, yeah, I think what I would do kind of, since I'm just sort of spitballing here about iframes, the steps I would take to test that, I would with anything. Make a little sandbox, on StackBlitz or CodePen or whatever, put an iframe in it with some focusable elements, and go test it.

That's always the way to get a true answer, is to go test it yourself, and so that's what I would do. I'm not gonna do it right the second, but that's how you can answer that question whenever you have something like that. It's like put it in a plain HTML page with no other dependencies, no other styles to get in the way.

And then just see what it does. Cool. So when to show a focus outline, I have an example here. Because I have had issues opened on component libraries of mouse users who are very mad about focus styles. And this could be when you're talking about convincing leadership and stakeholders, and they're like, why is this blue outline on everything?

You're like, well, that's the keyboard focus. Yeah, people don't love that. [LAUGH] It's really hard to make everyone happy. So fortunately, we have a really great pseudo class now called Focus Visible. And it will discern, it uses heuristics to discern between keyboard focus and mouse focus, which when you click it does actually focus things.

So like I clicked on this div, it has a tab index of negative 1 on it, and a focus style. When I click it, either by clicking on a button and sending focus to it with the mouse, or if I click directly on, say this is a wrapper element, my client routing target.

I'm sending focus to the heading or to a wrapper element. It has tab index of -1 on it. And I saw the sun and I have these issues getting filed that like, why is this focus style showing? Well, it's because your style is matching on CSS focus. Now, these days we have a more modern pseudo class we can use called Focus Visible.

When I click, it will not show that outline on tab index of negative 1. When I use the keyboard, it will, that's what we want. We want it to work for keyboards. And mouse users, probably not. I mean, some, the kind of the caveat here is for voice navigation, it acts like mouse clicking, but users might still want a focus style.

So, kind of what I say to that is, if you can make it configurable, if you're a big web app and you have accessibility settings, let users tell you that they really want focus outlines all the time. That would be the coolest thing ever if you really needed it.

And you're using voice navigation. But otherwise, focus visible is pretty great. And it could allow you to style with more specific pseudo-classes. And they're really synonymous, it's :focus versus :focus-visible. So it's really easy to use kinda in place of regular focus styles. And I have a link to the MDM docs on it if you wanna read about it.

But really the difference here is what happens when you click versus use the keyboard. There's a slight difference that when you're really being selective with how you style for these different inputs. It can save you. You can keep your stakeholders happy and make it accessible. There's also a JavaScript library called, What Input, that does something similar, but it's nice to use the standard CSS, now that it's there.

Any questions about focus visible? It's awesome. I love it. Gets us out of what I used to call button focus hell. That was when I was working on a component library and fielding the why is this having this blue outline questions on Github. It was not my favorite time.


Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now