AODA 2021 -- A Roadmap and Tools for Accessibility Compliance

Yo, man, there’s a lot of (organizations) out there flakin’ and perpetratin’ but scared to kick (accessibility) reality.  

“Jay, you’ve been doin’ all this dope (providing historical AODA context), but ain’t had a chance to show ‘em what time it is.”

So what you want me to do? Allow me to express myself…

If you’ve been following our blog posts of the past couple of weeks (and if you haven’t, I’ll provide you the links), first I shared my frustration with the lack of authority around AODA legislation -- both in terms of how organizations were approaching it, and how the powers-that-be have been less-than-transparent about what the AODA compliance deadline actually means. Then I provided a no-nonsense look at what the AODA deadline means, along with common errors and risks for non-compliance.

But you may be asking what about next steps? What if you’re ready to make changes, but are at a loss for where to start? Today, we’ll talk about tactics and tools you can use immediately to improve accessibility. And next week, I’ll share some systemic changes you can make to ensure accessibility is at the heart of everything you do.

Complete an Accessibility Scan, but remember context

To know where you’re going, it’s always important to understand where you are right now. And that’s where automated testing tools can help. 

However, there are limitations. As we’ve written before, automated tools can help, but they take a very black-and-white approach to evaluation, which means that some of the nuance of WCAG 2.0 compliance can get lost.

For example, automated checkers can tell if something’s an image and they can tell if that image has associated alt text. However, what it can’t tell is if that image is strictly decorative or if it’s a logo, factors which exempt those images from requiring alt text. So your automated scanner will flag those as errors and you’ll require human verification to understand the context.

Some scanners will allow you to flag those “errors” or contextualize them, so they won’t show up in future scans. But that doesn’t help you if your manager runs their own scan on another tool and is shocked by the number of errors.

Document, document, document, and provide context.

Which is the right accessibility tool for the job?

I reached out to my colleagues here at Echidna for some advice as to the right tools for the job. Dylan Rieder and Fran Wyllie (whom you may remember from this post on Accessible PDFs), are my day-to-day resources for accessible tech and development. Dylan and Fran have forgotten more about technical accessibility and development than I’ll ever learn, so I’m happy to defer to their expertise!

They offered a few free tools and extensions that have proven invaluable to their day-to-day work:

• aXe -- this Chrome plugin is great for general, single-page accessibility testing that offers some good tips on how to solve violations;
• WebAIM -- this is a contrast checker that tests for AA and AAA compliance for normal and large text, objects (like icons), and link colour contrast.
• WebAIM WAVE -- this Chrome/Firefox plugin offers general, single-page accessibility testing. It provides easy-to-understand visualizations of where issues are found on a page, and what elements are causing the issues.
• headingsMap -- this Chrome extension allows you to view and audit your headings structure to ensure compliance.

We also have a few recommendations for more comprehensive tools that include accessibility within their offerings. These are paid services, but are often worth the investment -- especially if you have large sites and want to maintain compliance.

• Siteimprove -- full disclosure, Echidna is a Siteimprove partner. But that’s because we know the value this technology brings to our clients. Siteimprove is an all-in-one platform for SEO, analytics, data privacy, and content quality, which includes a robust accessibility evaluation and monitoring tool;
• UsableNet -- this tool aligns with US-based Americans with Disabilities Act (ADA) regulations, but the foundations of the ADA are the same as AODA and most, if not all, accessibility standards -- WCAG 2.0 Level AA;
• DynoMapper -- Another all-in-one tool that includes accessibility testing amongst its suite of tools.

It’s important to note that none of these tools can be stand-alone. All of the results and reports require human analysis and validation. As we’ve mentioned before, sometimes an error is not an error, so you’re going to want to dedicate resources to interpreting and validating the results.

Gain first-hand knowledge

Have you ever experienced what it’s like to be a visually impaired user of your site? Have you ever used a screen reader? Try it. 

It can be overwhelming. It can be frustrating. And it gives you a new appreciation for the barriers that people using adaptive technology face when interacting with content in general. So why would you want to additional unintentional barriers through inaccessible content?

Here are three resources that can help you gain that experience:

• JAWS -- Job Access with Speech provides speech and Braille output on your PC;
• NVDA -- NonVisual Desktop Access is a free, open-source screen reader for Windows; and
• all Apple products nowadays ship with Apple VoiceOver that can be activated for testing.

As Dylan says, “it takes some time to learn to use but being able to go through a site with a real assistive device helps you find technical/content/page flow flaws.”

Get lived experience, if you can

As much as education and empathy can help your efforts, it’s even better if you can benefit from someone with lived experience. Realistically, it’s fairly simple to dot the “i”s and cross the “t”s of WCAG requirements (which inform AODA and ADA compliance). But that’s just the baseline. Just because something’s compliant, doesn’t mean it provides an equitable and quality experience.

For example, we were working on a site and, according to accessibility, everything was hunky-dory. But when we had our visually impaired accessibility specialist go through the site, she noticed that in one chart, the screen reader read the name of the company three times before it got to relevant content. Why? Because there was a logo, a separate name, and a contextual link. 

Sure, by the letter of the law, everything was compliant. But from an end-user perspective, it was pretty darn annoying. Now multiply that by 10 company references and you could see how the user experience would be less than favourable. 

What’s next?

Hopefully, these tools and tips can help you resolve some of the accessibility issues that you may be facing. But that’s only half the battle. How do you make sure those issues don’t keep cropping up? That involves systemic changes to your content management process. Next week, I’ll share some thoughts about how you can make accessibility foundational to your content development.

Learn more about accessible design or get help with an accessibility audit.

Go back to read Part 1

Go back to read Part 2