I’ve been at Instructure for the last six and a half years, and Global Accessibility Awareness Day seemed like the best opportunity to take a moment to help showcase some of the things that most often go unseen, but have a significant impact when it comes to making software accessible.
When working in the education and employee development space for a company like Instructure, keeping focused on accessibility is paramount to making sure that our tools genuinely work for everyone “from their first day of school to their last day at work.” While at the surface that requires meeting all of the necessary WCAG requirements before we release a feature, there is a lot happening just below that surface. Especially when delivering software as a service, there is a veritable cornucopia of continually moving pieces to both initially achieving as well as sustaining software’s accessibility over time, such as:
- How early on in design or development can we accurately test for each particular thing?
- What documentation and communication processes enable that to work best for each phase?
- What type of a11y training & how often makes the most lasting improvements on which roles?
- Where can we streamline and where do we need more granularity to improve efficiency?
- When should we be reusing what already works well vs. trying to make something better?
- Which tools work most efficiently with current workflows and which ones are redundant?
Those sorts of things are invisible externally so long as they’re working well enough to meet the requirements. Even if it works, continuing to proactively work on improving the scope, efficiency, and quality of our accessibility within the development processes by understanding those requirements makes a huge difference in the long term. There isn’t really a way to call those sorts of things out on a Voluntary Product Accessibility Template or explicitly cover it in a sales demo, beyond just communicating that we do genuinely care and are always striving to improve. This is why it’s beneficial to have trustworthy and well-informed individuals as representatives to the community who can embody all of that collective accessibility passion as a part of their voice.
As many in the accessibility space connected to Instructure may be aware, we unexpectedly lost an accessibility champion when our colleague Dana suddenly passed away in early February this year. She was unbelievably passionate when it came to advocating for accessibility, and had also been the face of all things a11y here at Instructure for the last seven years. While we will never be able to replace our colleague and oftentimes outspoken friend, there is a dedicated team that continues to focus on accessibility here at Instructure. While we will never fill Dana’s often spiked and/or sparkly shoes, we have still continued the important work, driven by the same passion that she projected to the community.
I love being a part of a team that is always striving to push the quality of accessibility forward, so that even when we’ve met accessibility requirements, we don’t just see that as a box that’s been checked that we can move on from. It takes a dedicated group effort by everyone involved in each part of the end-to-end development. It’s a push to find more ways to make something that manages to be greater than the sum of its component required parts—so that we can keep becoming just a little bit better at it, and let those last little improvements slowly just become the new normal for everyone.
Accessibility QA Engineer