Accessibility
Our company's mission is to make data available to all. That includes everyone, regardless of ability or disability. Everyone should be able to use data.world. As our user base grows, gaps in accessibility become more prevalent. A few team members and I pushed for and planned for an accessibility initiative that increased our rating from 73.72 to 80.72 (with Lighthouse’s desktop rating tool.)
Company
data [dot] world
Role
Leading the initiative from the design side
Challenges
Understanding and applying Web Content Accessibility Guideline (WCAG) criteria
What excites me
Learning about what actually goes into web accessibility beyond surface-level assumptions
My presentation slides on accessibility and our mission.
THE NEED
Everyone was onboard to make accessibility improvements, but the question was “how?”
Accessibility is an expansive topic that affects visual design, development, and even copy. To make long-lasting improvements, we needed to first understand where we currently stand before identifying where we needed to go. As much as we’d like to dedicate all our time to accessibility, our small team is constantly pulled in different directions. Accessibility improvements needed to be scoped to actionable tickets, clearly divided amongst teams, and heavily prioritized for maximum impact.
THE INITIATIVE
Start small and slowly catch wind in your sails
A few developers and I first started this initiative by identifying areas where we could make clear improvements without any scope creep. These improvements were scoped to small tickets that clearly defined action items such as, “make sure this tab is navigable by keyboard.”
Luckily, our accessibility initiative eventually coincided with needs from other teams. They needed a clear answer to whether our platform was accessibility compliant or not, and the national standard for that is the Voluntary Product Accessibility Template (VPAT). Put simply, the VPAT is a list of criteria that evaluates how accessible a specific product is. A completed VPAT was a helpful benchmark for us internally, and a useful external-facing document.
Cover page of our VPAT, finalized with help from our advisor, John Morkes.
Strict prioritization
The design team’s main responsibility was conducting the accessibility audit, producing a completed VPAT, and translating it into improvements we could make. Once we completed the VPAT, we created a list of specific changes that needed to be prioritized. Our main targets were platform “deal breakers”, or issues that completely prevent users from interacting with the platform. These included keyboard navigation, missing focus states, and screen reader issues.
Every few quarters, the product/engineering team schedules one week of “bug squashing.” Usually, this means addressing small bugs or tiny design polish. This time, the theme was accessibility. The design team presented the VPAT results and a curated JIRA board full of bite-sized tickets for everyone to tackle.
An ongoing effort!
At the end of Bug Squash, we were able to increase our accessibility score from 73.72 to 80.72, based on Lighthouse’s desktop accessibility rating tool. We’ve eliminated major accessibility deal breakers, added a checklist for design QA, and set up the ESLint plugin for accessibility auditing. As the team continues to introduce new features to data.world, we will continue learning about and building a more accessible platform.
Our VPAT and platform specifics are confidential, but if you are interested in the details of this project, please reach out!