Nested Interactive Elements: An Nightmare in Accessibility

Rate this content
Bookmark

There have been numerous remarkable new UX experiences developed over the years, such as cards displaying an array of products and clickable list items with dynamic menu options, among others. However, only a few are aware of the challenges involved in building these structures with accessibility in mind, and unfortunately, some of them are completely inaccessible. 


In today's talk, we will explore some of these prevalent web UX patterns and delve into the hidden challenges they present. While we may be able to mitigate some of these issues, others serve as cautionary tales in accessibility.

Cat Johnson
Cat Johnson
23 min
23 Oct, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Nested interactive elements can cause accessibility issues on websites, and the speaker shares a personal experience with an accessibility bug involving a list component. Mitigating nested interactive structures involves limiting these patterns during development and restructuring existing elements. The speaker provides recommendations for improving accessibility, such as adjusting role properties and gathering user feedback. The conclusion emphasizes the importance of accessible solutions and encourages sharing resources to build more inclusive experiences.

Available in Español

1. Introduction to Nested Interactive Elements

Short description:

Welcome to my talk today. We're going to be talking about nested interactive elements and an accessibility nightmare. My name is Catherine Johnson, a software engineer at Microsoft specializing in accessibility. Let me share a story about my interaction with Nesta Interactive components. I encountered an accessibility bug on our site involving a list component. Initially, the list row had a role of a button, but it needed to be a list item. However, later, we received feedback that it should be a button again. Sometimes accessibility guidance changes.

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.

2. Nested Interactive Elements and Accessibility Bugs

Short description:

I encountered an accessibility bug on our site involving a list component. The accessibility bug stated that when screen reader users were navigating to this internal button, it was starting to get all garbled, and it wasn't reading out properly. 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. I've realized and discovered that the screen reader issues that I'm experiencing are all related to issues around nested interactive elements. Nested interactive elements are essentially interactive elements that are nested within other interactive elements.

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.

3. Mitigating Nested Interactive Structures

Short description:

Nested interactive elements are causing accessibility issues on websites. They are commonly used to create beautiful UX experiences but don't translate well to HTML and can break screen reader functionality. This problem is pervasive on our website, with clickable cards and lists containing nested interactive elements. Unnesting these elements is not easy, so a new approach is needed. Mitigating nested interactive structures involves limiting these patterns during development and pulling apart existing nested elements. It is also recommended to restrict developer configurations to prevent conflicts between interactive features.

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.

4. Restructuring Nested Interactive Elements

Short description:

To improve accessibility, limit specific role configurations and restructure the experience to translate well to screen readers and assistive tools. Use CSS to overlay elements and stack them for nested interactive effects. Adjust role properties to enhance accessibility. Engage with users and gather feedback to create a cohesive experience. Share your learnings and document solutions. Restructuring nested interactive elements proved challenging due to the complexity and widespread use of components. Instead, focus on conveying meaning and improving accessibility within the current DOM structure. Ensure list elements have the role of list items. Restrict properties for buttons within lists. Use a generic role of group for containers with inner click targets.

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.

5. Conclusion and Call to Action

Short description:

Screen reader users can navigate the content as normal, but will hear a button at the bottom. The container allows mouse clicks for visual users. Documentation was created and shared to address nested interactive elements. Limited documentation exists on nested interactive elements and their challenges with assistive tools. Restructuring experiences for better accessibility is the goal. Accessible solutions are constantly evolving. Share accessible resources and help build more inclusive solutions. Contact me at catinthemachines.com for more. Thank you for joining me today.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Accessibility at Discord
React Advanced Conference 2021React Advanced Conference 2021
22 min
Accessibility at Discord
Configuring Axe Accessibility Tests
TestJS Summit 2021TestJS Summit 2021
30 min
Configuring Axe Accessibility Tests
Top Content
Axe-core is a popular accessibility testing engine that is used Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations.
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
JSNation 2023JSNation 2023
10 min
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
Our design systems commonly feature components that show on top of other content: tooltips, date pickers, menus and teaching UI, to name just a few. Proposed updates to the web platform are about to make building these a whole lot easier. You might not even need JavaScript. In this talk, you’ll learn all about the upcoming ‘popover’ attribute, modality and the top layer.
a11y and TDD: A Perfect Match
JSNation 2022JSNation 2022
24 min
a11y and TDD: A Perfect Match
Accessibility has been web development's ugly duckling for quite some time now. I often get asked, "when should you test for a11y in your apps?" My answer is simple, "right from the start!". Regardless of the framework considered - React, Svelte, Vue, YourOwn™️ - as developers we are in a privileged position to help the ugly duckling grow into a beautiful swan. How? By diving deep into the pond and harnessing the power of Javascript APIs to build the right components for your web apps. And how can do you know you are building them right? By pairing Test Driven Development with the Testing Library family. Ready to grow your web apps into swans?
How to do Good Without Doing Anything
React Advanced Conference 2021React Advanced Conference 2021
32 min
How to do Good Without Doing Anything
There’s no arguing that building accessible websites is a force for good. But ensuring that our React websites and apps work for everyone can be time-consuming and isn’t always easy to get right. Luckily, investing a little bit of time on your accessibility workflow and setting up a series of automated tools will end up saving you tons of time and energy in the long run.In this talk I will demonstrate how you can leverage automated tools, clearly documented code standards and a well-defined development process in order to make building and testing accessible React apps a breeze. I will discuss the ways that I automate certain aspects of my development workflows to catch accessibility errors, define and set up tests and go through the entire lifecycle of accessibility feature development using a real-world example.
Accessible Component System Through Customization
JSNation 2023JSNation 2023
30 min
Accessible Component System Through Customization
Most current UI libraries provide great user experience with a vast of components. But when it comes to heavy customization, and non-standard scenarios, especially for E-Commerce, they become hard to manage, scale or even slow down performance.
How to create a UI library that provides users the most possible freedom in customizing components, while keeping our performance and scalability to the fullest? How much accessible we can provide out of the box to our users? How much customization freedom is enough?
That's what my talk's about.

Workshops on related topic

Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
React Summit 2023React Summit 2023
109 min
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
Workshop
Asaf Shochet Avida
Eitan Noy
2 authors
In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.
We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.
By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!
Automated accessibility testing with jest-axe and Lighthouse CI
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Bonnie Schulkin
Bonnie Schulkin
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.
Web Accessibility in JavaScript Apps
React Summit 2022React Summit 2022
161 min
Web Accessibility in JavaScript Apps
Workshop
Sandrina Pereira
Sandrina Pereira
Often we see JavaScript damaging the accessibility of a website. In this workshop, you’ll learn how to avoid common mistakes and how to use JS in your favor to actually enhance the accessibility of your web apps!
In this workshop we’ll explore multiple real-world examples with accessibility no-nos, and you'll learn how to make them work for people using a mouse or a keyboard. You’ll also learn how screen readers are used, and I'll show you that there's no reason to be afraid of using one!
Join me and let me show you how accessibility doesn't limit your solutions or skills. On the contrary, it will make them more inclusive!
By the end, you will:- Understand WCAG principles and how they're organized- Know common cases where JavaScript is essential to accessibility- Create inclusive links, buttons and toggleble elements- Use live regions for errors and loading states- Integrate accessibility into your team workflow right away- Realize that creating accessible websites isn’t as hard as it sounds ;)
Creating Accessible React Native Apps
React Summit Remote Edition 2021React Summit Remote Edition 2021
91 min
Creating Accessible React Native Apps
Workshop
Scott Vinkle
Scott Vinkle
React Native is a framework used to create native iOS and Android apps in a way web developers may already be familiar with. But how do you ensure your React Native apps are inclusive and usable everyone? Scott will share tips on how to test and build React Native apps with accessibility baked-in!