⮐ Back to Case Studies

How we launched accessibility process that works

Overview

When we decided to get serious about accessibility, all eyes were on UX. When we all finally got serious about accessibility, things changed quickly, and for the better.

Organization

The Church of Jesus Christ of Latter-day Saints

Impact

60+
point lift in Axe Monitor score
QA
took ownership of the score

Project Details

We started with a scan

The company purchased deQue Axe Monitoring and set up a weekly scan and set it to run on a weekly cadence. And the reports started showing up every Monday morning.

Spoiler: the results weren't great. They weren't even good. We were looking up at bad. How bad you ask? worse than this description of bad, bad. And then they got worse. Out of desired 80-100 points, we scored .04. Which is basically ZERO if we're trying to round up. So yah. Bad.

Where to begin

Our organization, like many, viewed accessibility as a UX function. So I did what any good designer does and I asked the guy who set up the monitoring service what to do. He set me up with an account on Axe Monitor and gave me a tour. It quickly became apparent that our accessibility problems were not just contrast ratios, we were going to need to fix some code.

Slide into my brown bag presentation

After taking a few days to get more familiar with the reports, I mapped out a high level process to address the thousands of issues in our scans. I then volunteered to give a 1 hour presentation on WCAG basics, and turned the corner into one of our reports. I shared a self contained HTML version of the report as part of the agenda for the presentation, so participants were able to follow along. As I was recommending a plan of attack for taking on our many thousand issues, one of the developers chimed in and said, "I think I just fixed this one we're looking at right now. I just submitted a pull request."

One merge and deploy later, 2000+ instances of that issue dropped off of the scan and our score jumped 40 points. Everyone got excited. Our QA declared the report and monitoring to be her responsibility. I did that blinking man gif meme thing and said, "let me get you an account set up" and the process fell right into place.

  • Design was responsible for visual contrast, legibility, and content related issues
  • Dev was responsible for writing clean accessible code and validating with browser tools
  • QA was responsible for monitoring and filing creating tickets dev and design

And there was much rejoicing.

Lessons Learned

Accessibility is the responsibility of human centered design

Accessibility is the responsibility of developement

Accessibility is the responsibility of QA

Often times our responsibility as designers, is to advocate for better process.