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.
Comments