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

The "Testing an ARIA Solution" 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 the importance of testing ARIA (Accessible Rich Internet Applications) solutions and provides tips on how to prioritize and test different ARIA attributes. They suggest gathering site analytics to determine which browsers and screen readers to focus on, using resources like to check the support of specific ARIA attributes, and exploring issue trackers and community forums for additional information and solutions.


Transcript from the "Testing an ARIA Solution" Lesson

>> Let's talk about testing ARIA Solutions because it is so easy to get wrong that we want to make this easier if possible. We don't wanna have to rely on QA to catch everything. They might not be specialized in accessibility either. You might know more than QA for a while.

So we wanna look out for each other and try and catch things while we have the opportunity to fix them, even if you have QA, because that feedback cycle can just grow and grow. So we wanna catch it right in the moment if we can. So testing early and often.

Here are some tips. So when you're trying to choose, can I use an ARIA attribute? One tip I have after you've exhausted every default HTML option available, [LAUGH] start there. But if you're like, well, we really wanna try and make this more interactive. It seems like there's a great aria-attribute for this.

See if you can gather any of your site analytics to see which browsers you need to look out for, and then you can cross-reference the WebAIM screen reader surveys. WebAIM is a group from Utah, they're amazing. And they put out these surveys every few years on the commonly used screen readers and combinations.

So if you have a lot of Windows traffic and Chrome or Firefox, you can go down this list and see, well, what are the popular combinations for that browser. And that can at least send you in the right direction for which things do we need to prioritize, cuz you're not gonna be able to do all of them so we have to rank somehow.

And you can use your site's traffic to pick the browser and then you can kind of learn which screen readers, do users commonly pair with that by looking at this. So then, I mean, we also wanna talk to people who use screen readers, just kind of putting that out there.

We don't wanna like go all the way through this process and assume we know, cuz we're doing our best, but most of us are not daily screen reader users. Just saying. But another tool, so we've gathered our analytics, accessibility support I/O or a11y support.i/o is a community driven effort to, it's basically like a can I use for ARIA attributes.

They're not all on here, but let's say we wanted to use aria-pressed for something and I'd go check the aria spec make sure I'm like understanding how it works. The aria spec isn't gonna tell me how well supported it is though. So I can look here and see that it only has partial support but if I drill down into that it's actually for the plain true false cases, it's green and supported all the way across the board.

So maybe it's pretty reliable for more base use cases so I could look I kind of skipped this step, but we're gonna look at aria-pressed. So I this is how I open it. I open up ARIA. This is, Way ARIA 1.2. I tend to just search [LAUGH] in the page for the attribute I want, find the first linked version, and click it.

And that'll get me there. That's kind of my way of finding my way around ARIA. So this will tell me that this is only for button roles. So if I'm doing something that's not a button role, maybe aria-pressed isn't the right choice. Maybe I need aria-checked or aria-selected.

So aria-selected I could use on grid cell, option, row, or tab. So if I'm doing a tab switcher, maybe aria-selected is what I need. Aria-checked is one for check boxes, radios, options, and switches, switch buttons. So if I'm doing one of those, maybe aria-checked is what I need and I can use that information with this accessibility support IO.

So maybe aria-selected. That one, just kind of mixed support, but I could go test it. This kind of helps me narrow it down. This and my own analytics is like how I can at least start to see a shape to how I might prioritize, how I might figure out how things are supported.

Cuz I could probably fire it up in voiceover and test it with Safari, what are people using? How do I know where else to look? How do I know what else to test? So this is how I kind of figure out what the priorities are. You could check out the ARIA Authoring Practices Guide.

We saw that a little earlier. It had some patterns on it. They might have some suggestions of like how to execute some of these patterns. You could snoop around the issue trackers for all the major accessibility repositories like the MVDA screen reader has an excellent issue tracker. It's open source.

And some of the trickiest issues I've found are on Windows, Windows and mobile voiceover interestingly, have been kind of tricky. The ARIA spec is also developed in the Open AI GitHub. And so there's tons of info on there. What CAG the actual standard for our guidelines, those are open source on GitHub, and then WebKit and Safari, they have their own bug tracker that it's a little bit hard to search through, but it is open.

And then lastly, there's the WebAIM. They have an email discussion list that has years of archives. So, and a lot of people on there either work on browsers or screen readers. I mean, they are like very influential people who like answering questions, and there's a great community around it.

So go search their archives. In these repos, I found solutions to things maybe that I thought were problems but then I learned how the screen readers were designed around how blind people actually navigate. And I could learn that I actually misunderstood how that was supposed to work. Now, I get it.

And that was free information that I found in these repos. So these are some of the more like tactical steps that you could take to figure out how to deal with ARIA Support, cuz it's not perfect across the board. And remember that screen readers are not the only thing in accessibility.

So ARIA mostly targets screen readers and assistive technologies. But this is one piece of it. So, yeah, we kind of just have to remember that when we're juggling all these priorities. And so some things are just so clearly blockers that they're so severe that we have to fix them.

I just think, yeah, we have a lot of balls in the air that we're trying to balance everything and sometimes we have to remember that people can still see the screen sometimes, but they can only use the keyboard or they have motion sensitivity or there's all these different use cases.

So we try to hit like all of them somewhat. Try to get the basics in general and then we go into some of these more obscure issues on certain browsers and certain screen readers.

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