How We’re Making Loopio A More Accessible Product
Accessibility is such an important initiative. People with disabilities should be able to have the same level of access to digital products as those without. This initiative eliminates barriers that restrict people with disabilities from accessing our product. But, where do we start? Having never worked on accessible products before, this was the question I thought about many times when trying to kick this project off:
- Do we do an audit first?
- Or do we train everyone first?
- If we do an audit, should we at least fix the known accessibility issues with our shared components first?
In the past, members of the design team implemented some things we knew how to fix, such as colour contrast, text sizing, etc. but we needed to expand our knowledge of how to implement accessibility best practices to improve the usability of Loopio for all users. In October 2019, we attended the a11yTO conference in hope of sharpening these skills, but we knew there was still more information to gain and knowledge to learn.
Getting Started → Setting Priorities Through an External Audit
When we kicked this project off, we thought we’d start with an audit, to at least get an understanding of how Loopio complies with Web Content Accessibility Guidelines (WCAG) 2.0 guidelines. We met with many vendors to make sure we would walk away knowing how Loopio complies against WCAG 2.0 and with the right tools to fix any accessibility issues so we could make Loopio accessible by everyone. We ended up narrowing it down to a final two that best provided us with what we were looking for.
These were the most important aspects of our evaluation criteria:
- Are support hours offered after the audit and training?
- How do you support us with getting buy-in from stakeholders?
- How have companies in the past successfully planned their accessibility initiatives?
Focus on Training to Empower Designers and Developers
With the addition of a few members to the design team, we decided to look at our collective past experience implementing accessibility into digital products at other organizations. We came to the conclusion that an audit alone can typically lead to a big document of issues that need to be changed, but the document ends up sitting there because teams often don’t have the proper skills or knowledge to actually fix the issues. This insight made us pivot our approach and focus heavily on ensuring training was a part of the initiative. We went back to our vendors and discussed training options. Based on this, we decided to partner with Level Access. They were able to first provide us with an audit, then tailor our training curriculum around the common issues they found in the audit.
Creating Training Curriculum Suitable for Both Developers and Designers
We wanted to ensure that all Loopers had a common understanding of accessibility and the efforts required to implement it into our platform. We kept two main goals in mind when developing our training curriculum:
- It needed to be suitable for both software developers and designers
- The training sessions needed to be relevant to our product specifically
Over the last few years, we have done a few Introduction to Accessibility workshops to explain why accessibility is important. We decided to include these in the training sessions to ensure even our newest hires had this important foundation as well as some of our other internal stakeholders.
After our intro sessions, Product Designers and Developers broke out into separate sessions to dive deeper into our distinct responsibilities: Designers learned how to best annotate our Figma documents, while Developers learned how to implement things like alt text and proper labeling. We then came back together to learn the many ways we could test for accessibility in our product.
Testing is a crucial part of developing an accessible product because it ensures that the end user is able to navigate the product in a perceivable and useful way. The main ways we can test for accessibility are manually through:
- Visual analysis
- Keyboard navigation
- Screen Reader navigation
In addition to this, we’re using Chrome Extensions to run against our product and developing automated accessibility tests in our code to non-compliant code before it’s released.
Creating Space for Experimenting, to Perfect Our Practice
Though these sessions were invaluable and provided us with many learnings, we craved a space to experiment and test what we learned. Designers decided to jam on annotating our Figma files to include accessibility, which allowed us to debate and research the best ways of implementation. Developers on the other hand, had a workshop where they were divided into teams to tackle some of the top accessibility issues reported in the audit (and even pushed some to production after the workshop!).
Future Plans for Continuity
As we continue to make our product more accessible, we’re creating a program plan to make accessibility part of our definition of done, pairing with new team members to teach them what we’ve learned, and creating automated tests to catch any accessibility bugs.
Accessibility truly is an ongoing work in progress. At Loopio, we have the goal of creating a company and product that is inclusive of everyone and that will be the continuing factor that motivates us to push forward.
Interested in joining the team and being a part of our accessibility initiative? Check out the career opportunities available across Loopio’s Engineering, Product, and Design teams.
