Lack of accessibility across our product suite was impacting both our customers and their end users. We wanted to demonstrate how accessibility could be improved in our most used products, and develop a process for ongoing improvement across the business. 

Worked in collaboration with Accessibility consultants to evaluate our products WCAG compliance and identify areas for improvement

We recognized early on that our knowledge of accessible software design and development practices in-house were lower than they should be. This prompted us to engage with a local accessibility consulting group to work with us closely on understanding the scope of the problem, and where we could improve our product.

As scope was a factor in this work, we determined the best place to start was with our survey tool, Questions. Our consulting partners performed a full audit of our product against WCAG 2.1 guidelines, and user tested our tool with users that have accessibility needs.

This was a great opportunity for our wider team to see how things can look correct on the surface, but if something isn't built with accessibility in mind, things get missed.

There were a lot of great insights from the audit, and a tonne of learning opportunities for our whole team, as this was new territory for some of us. We set about making a plan to remediate issues that were critical to us achieving our goal of making our tools AA Accessible.

Created new design system components with a focus on accessibility

When it came time to get to work on making changes, we did alot of research on the best way to approach tackling the changes we needed to make. From our conversations with our consulting team, and other a11y experts in the tech sector, the consensus was that taking a component/design system lens on it was likely the best way.

We have had a design system for a few years, but there wasn't an explicit focus put on accessibility of the components. We evaluated whether or not we attempt to update the existing components, or write completely new ones that we could re-use in other parts of the tool later.

Our component library had some handy a11y features

We opted to start from scratch, and it was a great opportunity for us to look at how to structure components in an accessible way. Fortunately we had a lot of great resources to draw from, such as the UK Government design system and W3C Accessibility pattern library.

A couple of UI experiments to demonstrate functionality

Worked closely with front-end engineers to implement changes

It became clear as we started working, that this was going to be less about UI Design and more about supporting the devs to ensure things like tab order and aria-text were correct.

After our initial discovery phase, I shifted my working style to play a more supporting role in the work. This meant that I would work as closely with the devs on my team as possible, collaborating on the interaction design and testing it at every step with screen readers and keyboard navigation.

We made some small changes to the UI, but we decided to leave things as close to the component library design as possible. The most important part of this work was ensuring everything worked as it should, so visual changes were left alone unless they were contributing to an issue, like component states.

Developer diagrams to explain how our components would be structured

Conducted research with users with accessibility needs to validate our solutions were fit for purpose

Towards the end of the project, we felt we had things in a good enough place to test our changes out with users for the first time. We were fortunate enough to be able to meet with users from the Blind Low Vision NZ group, who were more than happy to put our work through it's paces!

In collaboration with our principal researcher, we put together some studies and a discussion guide to test out the survey tool.

We were really pleased to find that almost all of our question types were highly usable as a result of our work, and the ones that needed work had clear fixes!

Helped to set organization-wide policies around accessibility requirements and establish goals

Throughout this project, we worked on setting up new processes for how we design, test and build in an accessible way. It's a long journey for any organization to go on, but we feel more confident than ever that we can bring these new ways of working to other teams and parts of our product.

Upskilled wider teams of designers and developers in accessibility best practices

Using knowledge I had gained from the auditing process and my own research into a11y best practice, I worked in collaboration with the marketing team to find ways for them to improve our site accessibility rating.

This turned out to be a really great way to involve the wider team, so they could start to think about it in their own work. We ended up finding a lot of really straightforward ways to improve not only the site, but our process around testing and evaluating accessibility issues.