Nested Interactive Elements: An Nightmare in Accessibility

Well, welcome everyone. Welcome to my talk today. We're going to be talking about nested interactive elements and an accessibility nightmare.

My name is Catherine Johnson, and thank you for joining me today. So, as I mentioned, my name is Cat Johnson. I'm a software engineer. I work at Microsoft, and I focus a lot of my work on front-end web components, specifically React components, and I specialize in accessibility.

Here, for instance, is one of the websites I work on a lot in my day-to-day job. This is the Your Info page on account.Microsoft.com. Today, I'm going to start us off with a little bit of a story about my work and my interaction with Nesta Interactive components.

So my day-to-day job, I'll be working and coding as one does, and one day I was working, and I got an accessibility bug on our site. I was talking to the tester, and they were explaining to me that there was an issue with a section of code on our page. This was sort of the area of our UX I was having a problem. So this whole container right here is a list component that we built in React. Right here, you can see that it has the HTML role of list. And inside of it, we have a list row inside that list, and it has the role of a button. We made it a role of button because that whole list row is clickable and it's very interactive. But the accessibility bug told us that, hey, the role of list, like the role of button, it needs to be a list now. It's not accessible. So, got that feedback. I was like, cool, perfect. We're going to remove it, we're going to change it, we're going to change it into a role of list item. So I get back to my workstation, I type away, I fix it. I push out the code, leave my brain, and I continue my work.

A few months go by, I'm working again, I get another accessibility bug. This time the tester is explaining to me that it's very similar or it's in the same experience. So, we can see it's the same list, the whole thing's a role of list. And that row that we change it to a list item, the accessibility tester said, hey, no, we can't do a role of list item, this whole thing is a button and it's clickable and has user interaction. So, for screen reader users, we needed to have a role of button to explain that to users. At first, I was a little confused on this feedback because it was previously a button, but now it's a role of list item, like, which one should it be? But you know what? Sometimes accessibility guidance changes.

So, I was like, all right, no problem. I'll change it to a button. That's fine. No problem. I continue on with my work, fix it, and then totally lose my mind until some time later. And again, working my desktop, I get an accessibility bug, and this accessibility bug is slightly different.

So, it's the same list, the row is a role of button, and inside of that whole row, there is a button that we have for users, and the accessibility bug stated that when screen reader users were navigating to this internal button right here in the green area, it was starting to get all garbled, and it wasn't reading out properly. And then, on top of that, the accessibility tester said that whole row should be a list of properties.

So, at this point, I'm just blown away. I'm so frustrated. I don't know what's causing the screen reader issue that's making this internal button read out all strangely, but there's a lot of miscommunication issues around what these roles and what these properties should be set for them to work with screen readers and assistive tools. So, at this point, I decided I'm not going to fix this thing right away. I need to dig into what is happening in this experience so that I can really ascertain what is the best solution for our site.

So, I start doing some research. I start digging into it, and I've blocked out the problem into two sort of bullet points. First, I need to fix the screen reader issue because right now as my experience exists, it is causing issues and users who are using screen readers or other tools cannot navigate to this internal button and they can't activate the experience that they're wanting to use. Then the second problem I need to fix is I need to figure out what is happening with this list item or button or whatever role, like miscommunication. Why is it not clear what role it should be? And I need to figure out what it actually needs to be.

So I start doing some research. I start digging online, looking into what is the screen reader issue? What is happening right there? And it's during this process that I've realized and discovered that the screen reader issues that I'm experiencing are all related to issues around nested interactive elements. So let's dig into what are nested interactive elements and why they might be causing problems for our site. So as a brief side note, nested interactive elements are very clear, like nested interactive elements are essentially interactive elements that are nested within other interactive elements.

So here's a really simple, brief slice of code that is a really great example of a lot of cases of nested interactive elements. We have an element that is a role button and inside it we have a link that has a specific click target. Now this example, when we think about basic HTML, a lot of basic HTML does not recommend we put buttons inside of links. So if you look back to early 90s web, it never really made sense to put links inside of buttons. It caused click target issues. But most notably there really wasn't a lot of good examples around users wanting an experience like that. And it didn't translate well to HTML. So a lot of early sites didn't really have links inside of buttons and you either used a link or used a button.

But as time has evolved with a lot of UX experiences, and I'm sure a lot of you have probably noticed this around the web, is we have a lot of UX these days that has a lot of overlaying of click targets. One great example I found, which was on Google, is they have some Nest Interactive issues here as well. Below if you're ever on Google Page there's always a bunch of links at the bottom of pages you go to very frequently and one of my links, the whole thing, is a link to direct you to that page but nested inside of it, inside the HTML DOM, you have a button there, which will cause screen reader issues. This is another site I frequent very often. You can see another Nest Interactive element issue where we have this dropdown menu with a bunch of links and inside of that link we have another button that would expand and show more navigation panes. So at this point in my research, I'm starting to see that nested interactive elements aren't supported in HTML but we're seeing them all over the place around the web. And they're mostly there to create these beautiful UX experiences but it doesn't translate well to HTML and has the potential problem of causing screen reader issues because screen readers, they build off of basic HTML and when their elements nested inside of interactive elements, screen readers don't really know how to read out that content so it breaks. So seeing this all over the web, I'm starting to realize this is all over our website. It's all over our website. We have our own clickable card experiences on Microsoft, account on Microsoft.com. Here is an example of a clickable card with the outside is a click target and there is also an inner click target, both the same click props. You'll see this all around our list experience, which explains why I was seeing so many accessibility bugs around our list saying, showing that like the whole row is a clickable element but we also have clickable elements inside of that list. Or we even have whole list items that the entire container is just meant to be like a button but it's in package in a container of a list. So at this point, I'm starting to get really confused. I'm seeing this all over our website. I don't know what to do. I also don't know what roles these elements should be. Is there a way we can use a different role or a role property to change it so it's not a nested interactive element? How do I tease it apart? I'm feeling at a loss because when I'm researching this information at the time, there's not really any good mitigations to the nested interactive element issue beyond fixing it and not nesting them. But looking at our old site, seeing how pervasive this problem was, unnesting it wasn't as easy as it is documented. So I needed to try a new approach to fix this for our website. So now let's talk about ways we can mitigate nested interactive structures in a multi-step process so we can get this resolved for our websites and not deal with a lot of pain. So the first thing you need to do if you're experiencing nested interactive issues is you need to try and limit these patterns from the get-go before you even develop. If you can, before you develop, just don't do nested interactive elements. But if you already have a lot of code that has nested interactive elements, please try to pull apart that nested interactive experience. So here you can do that simply as taking that inner element and just moving it outside. I know probably in practice that is not going to be as straightforward, but in general, if you can, try un-nesting them and working with the code to see how it might work. Another thing we can try that I would recommend is we limit developer configurations on these experiences. If you own a React component library or create other React components, if you're allowing users and other consumers of your components to pass in click targets or interactive features, please restrict them to not passing any properties that might conflict with one another. The whole container is clickable. Maybe restrict whether they can pass in buttons or links depending on the situation to limit NIST interactive elements cropping up.

Also additionally, please limit specific role configurations that might become problematic for the experience. If you have a certain component, say you allow users to modify the role property in HTML, maybe instead of making it open-ended try and restrict it to properties that will still preserve the accessible experience of your component.

So now once you've tried all of those things, trying to limit the exposure of these NIST interactive experiences, the next step is to try to preserve and restructure your experience to translate well to screen readers and other assistive tools.

So let's go back to the example of the Google page and what we can try here. So say you try to unnest the experience and you were able to move these elements apart, but you still want to create that UX experience of the buttons overlaying one another, similar to other patterns around the web. One thing we can do to create that experience is using CSS to overlay the elements and get them to stack on top of each other. That's giving you the effect of nested interactive elements without all the negative effects on accessibility and screen reader users.

Another strategy you can try here to again preserve the UX experience, but still make it accessible, is you can play around with the role properties of different elements to make them work a lot more effectively. In this example, let's say the click target inside of this area is the same as the outer target. In that case, a recommendation would be to change the role of the container to something generic that doesn't really surface to screen reader users, but preserving the inner buttons so then screen reader users can hover over that experience and hear that click target so they know to activate if they want to follow that link.

And then finally, this is sort of an all encompassing suggestion is, I encourage you though, if you're trying to restructure these experiences, you've unmested them and you're trying to recreate this feel in the UX for screen reader users, to create focus groups, talk to customers, talk with people who use assistive tools and get their feedback on the existing interaction, recommendations for how to improve the experience, or even working with your PMs and designers on how you can use other engineering tools to create a cohesive experience for screen reader users and users using other assistive tools.

And then once you've done all this, now that you've fixed your nested interactive elements issue and it's well behind you, I encourage you to share your learnings. I encourage you to write documentation, share them online on Stack Overflow, at conferences if that's your jam, and share them online because these issues with nested interactive elements, when I was looking into it, there wasn't any documentation and a few nuggets of information was what helped me really solve and create a solution that worked for our website.

So given that, let's talk about what we decided to do with our website. First thing we tried to do was limit these patterns. And I tried really hard. I tried to un-nest these interactive elements for our site, but it was nightmarish. The problem with our website is a lot of these components were built as part of our internal component library and they were very well, one, they were very well nested, and two, they were used very widely throughout our website.

So to un-nest these elements and restructure it in a way that would work with screen readers in an HTML DOM structure, it would have changed our props very wildly and require a lot of refactoring around not only our component library, but around all of our partner sites. So we decided that, well maybe we could explore that in the future, for the time being we wanted to hold off on making that substantial change because it requires so much refactoring.

So instead what we decided to do was really focus on given the DOM structure of our components, what can we do to restructure it in a way that would convey the meaning to our customers and make it easier for screen reader users? So looking back on that initial bug, back in my story, I have this list experience, that whole row is a role button, and there's a button inside of it and we're experiencing screen reader users. The first step we realized was 1, that role needed to be a list item. Yes, there is a clickable element and that's why we were getting accessibility bugs. But to make it accessible and to convey it to screen reader users, you need to ensure that all elements of a list are of role list items so that it works well with screen readers.

And then, that really helped and fixed the accessibility bug we were experiencing on this button area right over here because now it's not nested inside of a button and causing all this garbled mess for screen reader users. We also restrict the properties for this list experience, we started going around to our partners and recommending and adding in our documentation stating that if you have a button inside of your experience that is already a click target, it's not recommended to make the entire region clickable, that way you don't cause all these issues.

But we also had list items, we have a very complex component library, we also had lists where the whole row was meant to be a button. For those situations what we decided to do was to make sure that the outer container for that whole row was of roll list item, but we added an additional roll of a button inside of it. So then when screen reader users are navigating this experience they can hear and hear that this whole container is a list with list items and then inside the list item there is a click target that they can navigate to.

And then for our whole cart experiences, for this situation we realized that throughout our site the whole container of that cart is the same as the inner click target, so we decided to change the roll of the outer container to a generic roll of group which basically is just a generic term that says that this whole area is a collection of things.

So screen reader users can navigate this content treating it as normal image, paragraph, content, text, but when they navigate to the bottom they'll hear that there is a button that they can click on and it will activate the same.

We also made sure that for the entire container to leave the on click properties, so then visual users who are using their mouse can still click the whole region just like any other website.

So once I was done redesigning everything, we went with the strategy for a website, I wrote a lot of documentation, I shared around my organization, notifying several engineers about this issue of nested interactive elements, and documenting it in our component library to make sure that we wouldn't recreate the same issues that we had found so embedded into our code base.

And then, I'm not talking about here. One of the big issues when I was looking into this is that there was very little documentation on nested interactive elements and how challenging they are for assistive tools.

And my hope here in sharing here at this conference today, will help you all know how we can restructure our experiences in our UX to be much more accessible experiences for everyone who's navigating it.

And as I'm drawing this presentation to close, I again want to encourage everyone that accessible solutions are constantly evolving.

The solutions that we went for experiences on our website work for today, but we're constantly evolving them and rebuilding them to be much more accessible.

I encourage you to read resources and for accessible solutions that you apply into your websites to share them online and help us all build and develop more accessible solutions that we can all share from each other's learnings.

And if you really enjoyed this presentation and you want to see more from me, you can reach out to me on catinthemachines.com.

I love talking about accessibility and web architecture and React components.

Reach out to me there if you have any questions, or you just want to say hi.

Thank you so much for joining me today for this presentation.

I hope you enjoy the rest of your time at React Advance.