We strive for having an accessible end user experience. Being inclusive is an important part of product ownership. As an example, in a recent case study for a large potential client, we scored “all green” for their race website and registration process using the Google Accessibility Tool.
We are achieving greater and greater levels of accessibility by striving to meet the principles and guidelines of WCAG and ADA.
WCAG is a W3C definition. While there are third parties who will “certify” software, this is not practical for us for two reasons. First, we have a massive amount of user interfaces. Second, each customer can customize their website and registration to their own needs which may not include the thought process of being accessible.
So, instead of paying a fortune to accessibility consultants to continually certify and re-certify us, we choose to Self-Certify with these four methods:
- Build things the right way
- Test with screen readers
- Listen to real users of our product, who are differently-abled
- Continue to learn
Build things the right way
All of our UI is built according to web standards, including the appropriate use of Aria semantics. Aria embeds additional information in our products to make it more usable by screen readers.
We test all new releases with the Google Lighthouse tool, built right into the Google Chrome browser. It provides us an accessibility score on a per-page basis. We require a score of 90% or above, or “in the green”
The tool lets us know if we are building things the right way, and tells us things we need to change to improve our score.
Test with screen readers
We test our new releases with a screen reader. While things may be built the right way, it doesn’t neccessarily mean things make sense to the screen reader user.
There are many details to consider for a screen reader user, when there are no visual cues. Does the label make sense? Do we need to provide additional information just for screen reader users? Are we handling focus properly? Are we handling state change properly?
These are questions that can only be answered by testing it with a screen reader. We’re not going to catch everything, but we’re going to try.
Listen to real users of our product, who are differently-abled
When someone is not able to use our product, we jump right right on it. It’s important to us.
Continue to learn
With every release, we learn more. We think about ways to scale up. We listen to feedback. We make incremental changes, and get better with every release.
Just like User Experience in general, accessibility is a goal that is continually evolving. And we are committed to becoming ever more accessible.