Nested Interactive Elements: A Nightmare in Accessibility

Welcome, everyone. Thank you for joining me here today.

Today I'm going to be talking about Nested Interactive Elements in Nightmare Accessibility. We only have so much time for this talk, so we're going to jump in really quick and get started.

But before we really get started, let me just tell you about myself. My name is Kat Johnson. I'm a senior front-end engineer at Khan Academy and I love talking about accessibility and how to create accessible websites.

So let's dive right in. But before we get into sort of the meat of how to fix this issue, let's talk about what are Nested Interactive Elements? Because you might not have heard about them.

Nested Interactive Elements in very simplistic terms is just interactive elements nested within each other. So, for instance, it's having a link within a link or a button within a button.

Here's a little slice of code that kind of shows this. The reason this structure is really problematic is because it's incorrect HTML.

In the really early days of websites and the web, it didn't really make sense to nest buttons inside of buttons or links inside of links. There really wasn't a use case for this. But as the web has evolved, we are seeing this more and more in a lot of our user experiences around the web, from Google to this website that I really like using called The Mountaineers.

You'll find a lot of buttons or links inside of links and some of these little button menus.

But you might be asking the question, what's the big deal? It might be semantically incorrect HTML, but me as a user, I never had any issues using this experience. I'm able to click and navigate and use a lot of these nested buttons. So it doesn't seem to really be a big problem.

The bigger problem is because it's incorrect HTML, it really messes with a lot of screen readers and other assistive tooling. Because it's incorrect HTML, a lot of screen readers and other assistive tools, when they read your HTML, it doesn't know how to read out that information and how to convey it to the user.

Usually this will cause a lot of errors and a lot of miscommunication for a lot of assistive tooling, making it really difficult for users to interact with your website.

So now you must be thinking, well, I could probably fix this. I'll just remove the role equals button or I'll use a generic HTML div and leave on click functionality. That should fix this accessibility issue, right? Well, wrong. Do not do this.

You might be fixing the issue of nested interactive elements, but now you're hiding interactive elements from other screen readers and other assistive tools.

So when a user navigates your website with narrator or NVDA, they'll go over this element within your HTML, and it won't announce that it's a button that they need to click on. They'll hide that information and really degrade the experience for your website and cause more accessibility issues.

So if your website does have buttons and links, please ensure that they are denoted as buttons and links in your HTML. So we're going to really have to find another way to fix this issue. But it's okay, because I have experienced this issue. On a previous website I work on, after building out a lot of the functionality in the R component library, we realized that we had this issue all over the place from our card components to different lists to other form fields inside our website. There was nested interactive elements all over the place causing issues with all our assistive tools.

The big question is, how do we mitigate this issue? How do we solve this? How do we make this better for our users? Well, there are several ways we can approach this problem. First, if you haven't started your website or haven't developed your component library, there's a lot of things you can do before you start. First thing you can do is, if it's at all possible, unnest these interactive elements. Really make sure they're not inside each other. Really move it outside of the nested interactive elements and make it a separate interactive element on its own.

And if you own a component library, something I'd recommend is if you're first starting out, please ensure that you're limiting developer configurations for your component library. Like setting strong typing and role properties so that if someone passes in some functionality, you're really limiting the scope and ensuring that they're not going to create a lot of accessibility issues. But you're probably asking the question, what if I've already written my whole website? What if I've already written my whole website or my whole component library and it's all over the place and I don't know how to fix this for my company without it being very costly?

Well, there's some other things we can do here. Let's look at the example with Google. Let's say your designer say that this layout has to look exactly like this, that we really need to have this interactive button card experience with a button inside of it for a drop down menu and we can't really change the user experience for that. Well, one thing you can try is you first are going to unnest those elements and then you can use CSS properties to really overlay that button on top of each other. It will create the visual effect of them being nested but semantic wise, it's not nested and they're separated out in the DOM structure. So that will reduce the issue of creating accessibility bugs on your website.

But let's say you can't unnest them for whatever reason. Well, and I encourage you to be very careful here, you can try modifying some of the roles. Now this I want you to be very careful about because you could accidentally hide a lot of clickable functionality on your website. But with this example, what we were able to do is within that drop down menu, there was already a click target to activate the whole card. So for us, we were able to set the whole outside div to something, a generic role of group or we could even like remove the whole role entirely and make it that click target, a very generic type. But knowing that users who use screen readers or other assistive tools can use that drop down button to click on the action for the whole button. So there's some things you can play around there. But whenever you're playing around with roles, I encourage you to be very careful about it.

But overall, if you're trying any of this functionality, whatever option you go with, I encourage you to host some focus groups with users who use various different assistive tools. They'll give you feedback on whether it's really clear, whether it's really concise, whether it works with your tool or functionality, and they can really easily navigate your website without any issues. And overall, no matter what option you pick, I encourage you to share your learning about what approach you took. Write documentation within your company, share your learnings online because overall, accessible solutions are constantly evolving. I know when I encountered this issue years ago, there was no documentation online about how to navigate this problem. So whatever option you go with for your company or for your website, please document it and share it online so we can constantly create better and more accessible solutions. And if you've really enjoyed my presentation here and want to see more, my name is Kat Johnson, and I hope you reach out and follow me on my website, katinamachines.com, or my LinkedIn, and thank you so much for joining me for this presentation, and I hope you have a great rest of your time at the React Summit. Thank you.