Join Natalie and Natalie for the eighth episode of the AAArdvark Accessibility Podcast, where they discuss the accessibility remediation process in detail and what happens after you get your audit back.
Natalie Garza: Hello, everybody, and welcome to the eighth episode of the AAArdvark Accessibility Podcast. I’m your co-host, Natalie G., an accessibility novice, and here with me today is…
Natalie MacLees: Natalie MacLees, accessibility expert.
Natalie Garza: And in today’s episode, we’re going to be talking about the remediation process. Um, as a quick side note, this is a re-recording because last week we messed up the audio.
Natalie MacLees: Technical difficulties.
Natalie Garza: Yes, technical difficulties. We’re going to try to do it right this time. We’re going to go through the questions again. All right, Natalie, do you want to kick us off? What happens after you get your audit back?
Natalie MacLees: Yeah, so typically you’ll get back the results of an accessibility audit, which are usually a big, giant spreadsheet full of all the accessibility issues that were found on your website. And now you need to sift through those, prioritize them, and figure out what to do next.
Natalie Garza: Right, and last time you mentioned it could be hundreds, if not thousands of issues, right?
Natalie MacLees: Easily, yeah. It’ll probably be at least hundreds. And if your site has more than 20 or 30 pages, it’s probably thousands, especially if the site wasn’t built with accessibility in mind from the beginning and this is your first attempt at accessibility.
Natalie Garza: So if you have thousands of issues, how do you tackle them?
Natalie MacLees: Yeah, so you need to prioritize them because there are going to be issues that have a bigger impact than others. You want to figure out what those are.
Most of the time, when you get the list of issues back for your accessibility audit, they will have a severity of some kind associated with them. There’s not a standard for that severity, so exactly what that looks like might be different depending on who did your audit, but there would be something saying, you know, a serious issue, a medium issue, or a low issue at the very least.
That’s a good guideline. However, that’s not necessarily a match for the priority for fixing those things.
For example, if I have a medium severity issue that’s happening on every single page, I would probably consider that a higher priority to fix than a really high severity issue that’s only happening on one page.
One of them—everybody is going to be encountering it constantly, and it’s going to be a real barrier and a real problem. The other one might be on a page that doesn’t even get much traffic, so only a few people are actually running into it.
You definitely want to think about how often it’s happening and how popular the pages where the issues are happening are. You can look at your traffic data, Google Analytics, and similar tools to figure out which pages are high-priority pages.
You also want to think about the severity because often, the higher-severity issues are complete blockers for someone. At least one group is going to be completely unable to use that functionality.
So that comes into the prioritization. And you also want to think about important content on the site.
For example, your homepage is always really important because probably, if your website is like most websites, about half of your traffic comes in through the homepage. Even the people who don’t come in through the homepage are likely to visit it at some point. So most of your site visitors are going to see your homepage.
Other important pages include pages with settings or preferences. If a user can set light mode or dark mode, pick a color scheme, or other accessibility-related settings, that page is really important.
Legal pages, like your terms of service, privacy policy, or accessibility statement, should also be high-priority.
For an e-commerce site, the cart functionality is a priority because you want to make sure people can buy something if they’ve put it in their cart.
And any forms—contact forms, comment forms, or anything else allowing user interaction—are also a high priority for accessibility.
Natalie Garza: So go through the long list of issues, prioritize them either based on how important the page is, the severity, the functionality. But then, how do you actually make a plan?
Natalie MacLees: You have to know who your team is, who’s going to be tackling the remediation, and what their strengths are. Then you can figure out who’s going to do what.
Pages that are really popular or have important functionality are going to be at the top of the list. A lot of times, you can tackle similar issues all at once.
For example, if your links don’t have enough contrast, probably all the links across your website are the same color, and there’s just one little line of CSS setting that color. So, you could potentially fix a thousand accessibility issues with one line of CSS and be done with it.
You want to look for those quick wins where you can make a big impact across the website with minimal code changes.
Natalie Garza: And for the developers, do they get access to the spreadsheet? Is it a matter of just checking off each row on the spreadsheet for them?
Natalie MacLees: Yeah, basically. You might want to use a task management tool like Jira or Asana and import the spreadsheet as individual issues so they can be assigned, tracked, and kept in order.
Or you could use a tool like AAArdvark, which lets you assign issues to developers and keep everything all in one platform. You can track the status of each issue, who it’s assigned to, and any comment thread that happens on that particular issue.
Natalie Garza: Mhm. And AAArdvark has a lot of other cool remediation features. Do you want to go over those?
Natalie MacLees: Yeah, sure. AAArdvark has a visual mode where it’s really easy to see exactly where accessibility issues are happening on the site. You can see a view of your site with little map markers showing where issues exist. You can click on those markers to get more information about each issue.
Also, you can never trust a developer to actually fix an accessibility issue on the first try. So, if an issue was found automatically in a scan, the developer can mark it as fixed, and AAArdvark will automatically verify that fix the next time it runs a scan.
If it’s not fixed, it will bounce the issue back to the developer.
If the issue was found manually, when the developer marks it fixed, the accessibility tester can go back, retest the issue, and confirm it was fixed. If it is, they can close it.
Natalie MacLees: Sometimes what happens is a developer fixes the accessibility issue that was found but accidentally introduces a new accessibility issue.
Other times, one accessibility issue is hiding another one behind it, and you can’t see that second one until the first one is fixed. So, by going through the remediation process, new issues might surface.
This is why it’s important to have someone checking these things, and AAArdvark can help manage that process.
Natalie Garza: I think AAArdvark is also really neat for just seeing the amount of issues you have left and filtering them.
Natalie MacLees: Yeah, tracking your progress over time and seeing the number of issues going down can be very satisfying.
Natalie Garza: Yeah, because with a spreadsheet, you just see the list every time you open it up. At least with AAArdvark, you can watch the list shrink.
Natalie MacLees: Exactly. And spreadsheets can get really messy for tracking the status of things as they progress. It can be challenging to manage that way.
Natalie Garza: Right. And even for people who prefer to work page by page, I’ve seen them just say, “Show me all the issues on the homepage.” And AAArdvark filters it really quickly.
Natalie MacLees: Yeah, that’s super handy and would be really hard to do with a spreadsheet. You also have to try and describe in a spreadsheet where the issue is happening, and that can sometimes be unclear.
Natalie Garza: Right. And on top of that, developers don’t have to waste time searching Google for something like WCAG Success Criterion 2.4.1 and sorting through hundreds of results to figure out what it means.
Natalie MacLees: Exactly. AAArdvark links directly to the WCAG success criteria as well as the recommended techniques for fixing the issue.
Natalie Garza: Right. So, all of this to say, AAArdvark is a great place to start when creating or remediating a site.
Natalie MacLees: Absolutely. It’s a big time saver. It’s the tool I always wished I had in all my years working in accessibility.
Natalie Garza: So after you’re done with remediation, what’s next?
Natalie MacLees: Well, it can be easy to think that accessibility is “done” at this point, right? You’ve checked every page, everything is accessible, and every issue has been fixed.
However, your website is probably not going to stay the exact same today as it was a week ago or a month ago.
Websites are living things. They’re constantly changing—you’re adding new content, publishing blog posts, adding products to e-commerce stores, updating news or events. There are always updates and changes happening.
As these updates happen, you might accidentally introduce new accessibility issues.
So accessibility isn’t a “one-and-done” type of project. It’s an ongoing commitment.
You’ll want to ensure continual monitoring of your website’s accessibility. Automated scans can help check for any new issues being introduced.
We’ve talked about automated scans before—they’re not perfect and will only catch a subset of issues. However, they’re a good way to monitor whether things are generally going right or wrong on the site.
If you’re not seeing a lot of new issues popping up in the automated scans, that’s a good sign you’re doing well. But if you’re seeing lots of new issues, it’s a signal that you might need to address how you’re adding new content.
You’ll also want to schedule manual testing and regular audits. How often depends on how frequently you’re updating your website.
For a site that’s updated all the time, you might want an audit every six months or annually. For less frequently updated sites, every two years might work.
But you should never treat accessibility as a “one-time” project. As long as your website is live, you need to think about maintaining accessibility.
If you find lots of new issues being introduced, consider providing training for the people adding content. These might not be developers—they could be content managers, marketers, or social media staff—and they need to learn how to add content without introducing accessibility issues.
Natalie Garza: And is this just for content updates? I feel like it’s especially important if you’re making structural changes, like adding new nav bars or forms.
Natalie MacLees: Yes, absolutely. If you’re doing bigger changes like redesigning the site or adding new functionality, you need to make sure you’re building it accessibly from the start.
You should check those changes as you build to ensure accessibility. But, yes, any change—big or small—can potentially introduce new issues, so it’s important to stay vigilant.
Natalie Garza: Thank you, Natalie. I appreciate you going over the entire remediation process and the ongoing maintenance that comes after.
With that, we’ll wrap up AAArdvark episode eight—re-record.
Natalie MacLees: Second time.
Natalie Garza: Second time!
We want to invite everyone watching to try AAArdvark for free. Test your homepage, use the automated scan, try out the remediation features, invite your developer friends, assign issues to them, and see what you can get done.
