In early 2014, large companies in Ontario such as Metroland were preparing for AODA. In the backlash of CASL legislation which was a real pain to deal with if you get caught, there was a real need to comply with any new laws as they applied to digital sites and tools.
At the time, no one internally knew how to deal with accessibility. This was also not something that was budgeted for, so there was no chance of outsourcing this initiative.
How I got involved
My boss asked me, “How long will it take for you to do an accessibility audit?”
“I’m not sure, I’ve never done one before.” I replied.
“You’ve got a month to figure this out.”
With that, I became their first accessibility specialist. What now?
The design process teaches us:
- Understand the problem
- Start somewhere
- Iterate
Understanding the problem
I did some quick research online and learned the accessibility challenge included 3 different perspectives:
1. Understanding People
This included learning about the challenges of those who rely on assistive technology to access information on the web and seeing how to apply these solutions for all.
2. Legal Requirements
Compliance was the name of the game. No organization wanted to get sued. From the corporate perspective, this included the minimum effort required.
3. Technology Challenge
Learning about WCAG and figuring out how to implement changes to ensure compliance. There was no easy method to do this. Reading WCAG was as dry as the sahara desert, and did not include any onboarding. Also as challenging, figuring out how to advise developers on what changes need to be done.
Start somewhere
Before moving forward, the existing level of compliance needed to be assessed. The first version of my accessibility audit was a huge mess in excel. Each guideline was checked on with each component. Since we had many
13 guidelines
X 5-6 average sub guidelines
X 20+ components
= waste of time
Not all of the guidelines applied to every element therefore not everything needed to be logged. I needed to work smarter not harder.
Iterating on the process
The second attempt involved starting with each guideline and assessing roughly what parts were impacted overall. This was met with confusion from the developers as they had to go all over the place to make these fixes. They were my primary audience for this audit, and it was not efficient for them.
Third time’s a charm!
The audit document was resorted by component, as well as advisement on how each problem needed to be fixed.
Additionally, I was manually checking with Chromevox to see if things made sense, such as capitalized words being spelled out.
Learnings
- Being ready to roll up my sleeves on vague challenges.
- Understanding the audience for the audit really helped those were implementing the solutions.
- There is no replacement for manually checking the site with a screen reader, even if it’s a basic one.
Results
While anyone in the digital accessibility community can attest, there’s no defined benchmark percentage to track improvement. The most important thing is that the organization is making an effort, regardless of it being just for legal compliance.
Main areas of improvement
- Save.ca was a flyer tool where users can click on products from store flyers to save them to their list. At the time of this audit, we had made this keyboard accessible, and screen-reader friendly.
- Content was cleaned up to reduce the use of capitalizations.
- The toolbar in Tripcentral.ca, including the calendar tool, was made keyboard accessible.
Fun Fact
In fall of 2014, I was given the opportunity to deliver a lecture on my accessibility audit. You can view my slides here:
Be the first to leave a comment