Over the past three years (and before) we have made gradual advances toward being more accessible for differently-abled users, adding small code updates to better accommodate assistive technologies, putting some thought into contrast, and making sure our form fields have labels.
These little things add up, and we thought we were doing well.
Then, we turned on the screen reader.
I’ll save you a few paragraphs: we were not doing well.
In Principle
In 2019, to rectify our accessibility deficiencies, we added accessibility into our UX Guiding Principles:
Be Inclusive
Continue to create accessible components and flows. Good design is inclusive design.
It’s easy to write that down. In practice, it was a bit more involved.
Practicing our Principles
We updated our frontend code review process to involve using Google Lighthouse to run an accessibility audit. Every new screen we created and any old screen we updated was subject to this audit. This new audit step taught us a lot about developing software that works with assistive technologies. It also slowed down our release cycle at first, as we had to ensure accessibility best practices on new UI, and retrofit existing UI with accessibility enhancements.
For each release, we were required to get a Lighthouse accessibility score that was “in the green” (at least 90 points out of 100).
What is the business rationale?
But why even do this? Why spend all this extra time? From a business perspective, there can’t be that many differently-abled athletes that are looking to run races.
There’s not a lot. But there are. There are people out there who need to use assistive technologies to sign up for a race. And they should be able to. And our customers – the race directors – shouldn’t have these athletes skip their events because the registration flow is unusable for them. We want more participants for our Race Directors, and we want to ensure users of different abilities can use our software so they can participate.
We don’t want to do this because it’s easy or because it will create a huge surge in registrations, but because it’s the right thing to do.
Quick Conversations
During my time at RunSignup, a few customers and potential customers have brought up accessibility. The conversation was usually very brief: I would be contacted by one of our salespeople working on an RFP that asked about our accessibility capabilities, and I would explain that we have deficiencies, but were working on it. That was usually enough to satisfy the salesperson’s requirements.
Finally, a meaningful conversation
The other day, we received a forwarded email from Jordan Desilets, one of longest tenured salespeople:
Hello, my name is Marco and I am a Blind Athlete. Trying to fill out the application and I am almost on the last step. It asked me to write down exactly as shown something that is underlined. This is unfair to blind people because we can’t see what is underlined and it doesn’t tell me, my screen reader doesn’t tell me, what is underlined. Need help. What do I do?
Here is a screenshot of the underlined text:
We quickly devised a solution, and RunSignup Developer Benny Chen pushed out a code update that would provide additional instructions to a screen reader user on how to proceed.
We could have left it at that, but we were hoping to learn a little more and asked Jordan if Marco would be willing to join us on a call and share his experience using RunSignup. He said yes, and we setup up a morning video call.
It turns out Marco goes by Tony, his middle name. And Tony was trying to sign up for the Ventura Marathon. Not the half, not the 5k, not 1 mile. The marathon. Oh, a month after Ventura, Tony is doing the IronMan in Arizona. Tony is a remarkable athlete.
Benny and I got on the phone with Tony at 9:30am EST, a mere 6:30am in LA, where Tony lives, pacific time. He told us early works well, as he’s already up and finished with his morning workout.
Tony suggested we do a Facetime call so he could point his phone at his iPad, and we could observe him use VoiceOver on his iPad with our software.
If you’ve never used a screen reader, you’d be surprised at how verbose it is. The amount of noise that a screen reader creates is overwhelming. If you’re curious, turn it on and go to a website – it is a wall of sound.
Low vision users filter out the noise effortlessly. Tony was able to almost subconsciously separate the signal from the noise, only hearing the useful information, and ignoring everything peripheral. Benny and I were struggling to keep up.
Tony’s approach to our conversation was almost teacher-like. He was very patient, and took time to explain interactions that were cumbersome to him. He explained things to us in the context of “we”, as if he was speaking for his community, not just himself.
Tony told us, that overall, our site was good for him to use, once Benny fixed the issue he was having yesterday. The funny thing is, if Tony had attempted to register just weeks ago, he would not have been able to progress past the first screen.
In the past few months, we made an effort to replace hundreds of inaccessible button elements in our UI with true html button elements, that had proper aria-labels where applicable. This was a large effort handled by RunSignup developer Benny Chen. This wasn’t a global find and replace – Benny researched the proper coding techniques, touched hundreds of files, and tested hundreds of screens.
Hearing Tony say that our site was “pretty good for him to use” made it all more than worth it.
When we were getting off our call with Tony, he took a moment to thank us. He seemed genuinely appreciative that we took the time to meet with him, and explained that he has sent emails like this for years and we were the first – the first, he re-emphasized – that responded to him. We were just grateful to have an opportunity to learn from Tony. We thanked him for his time, and explained that we (and RunSignup) are committed to being as inclusive as possible – and this conversation made our products better.
It’s a work in progress
We are getting better at this, and it was rewarding to have Tony validate that we are moving in the right direction and making good progress.
A proper and thoughtful accessibility implementation across our products won’t be easy. We provide technology to over 20,000 races with an unlimited amount of customizations and configurations, and that’s a lot to get correct. We will need to continue to research best practices, learn the needs of different user groups, and talk to users. Going through the process will expose our knowledge gaps and cause us to improve. And that’s what we do, with every release. We improve a little bit each time.
Let us know. Let anyone know.
I hope more users of assistive technologies take a few minutes to let someone know when their products just don’t work for them. Send that email and tell someone when their app or website just doesn’t work the way you need it to.
I’ve learned from Tony that doing this is often a futile effort – I was shocked when Tony said we were the first to respond to him. But do it anyway. Send that email, and someone will eventually listen. And it will make everyone better.
