Incremental a11y
I work for a large grocery chain in the Netherlands. We do ecommerce on a national scale: facilitating the ordering and delivery of groceries in the Netherlands. With a large organisation, it any change is not without effort and extensive investment.
During 2021, an investigation conducted by level-level.com signalled that they were only able to complete 55% of steps from their use case using keyboard and/or screen reader. This meant they were unable to place an order!
A blind spot
In alarmed response to this, we needed to investigate what has led to this. Looking in the mirror, we noticed that the people working on our software are (mostly) not impaired. Sure, we have the situational disabilities, colour blindness and whatnot, but those challenges were not impacting the user experience at an alarming rate. We have broadband connections and top of the line Macbooks to work with.
We want to provide a top notch, service orientated shopping experience
This way of working creates a blind spot! Which we believe has very much led to our bad rating. We needed to address this, because it is very contrary to our beliefs that we want to provide a top notch, service orientated shopping experience to our customers.
Establishing the baseline
Once we realised that we needed to work on this, we needed to get our bearings first. We teamed up between designers and developers to get started. So we analysed our website and apps and created an extensive report.
This resulted in two topics:
Getting better (and automated) measurements in our development flow;
Improving our existing websites and apps.
The measurements would help with establishing better monitoring and making sure to keep up a certain level of a11y in general. Of course, we also needed to address the existing issues!
The way our company is organised, we have approximately a day every week to spend on things that improve our companies goals but are not related to your teams' work (I'll do an article on this concept at some point). We didn't have to claim time to work on our topics, we could just start distributing by splitting the topics up into stories.
Getting the work done
Having the stories in place, we found out more about the size and amount of things we needed to address. In order to enlist help, we communicated about the nature of the issues and why they matter (especially to business). This onboarded more people to our cause. From frontend development perspective, we started to prioritise the topic in each frontend chapter meeting to keep awareness high and share progress.
Automated analysis
We build our software using a component library. In order to help with integrating a11y in our way of working, we added an a11y plugin for our Storybook instance to help us in automated signalling of potential issues for future and present components.
Doing this automated is key when adopting or introducing a new element in your existing processes, since it reduces the cognitive overhead.
Component by Component
To gradually improve the components we adopted a strategy that was very similar to upgrading our Vue.js 2 components to be compatible with Vue.js 3: we agreed that every component that you need to update as part of your daily work, you put in some extra effort in fixing the a11y issues that are now visible via the Storybook plugin.
This approach allowed us to slowly get up to speed with adopting a11y as a part of components, while also allowing everybody to be confronted with this. So while it took longer to upgrade every component, the benefit of spreading more awareness outweighs the delay, because it better anchors the responsibilities we have.
Leftover days
After a while, some components were simply not being touched because either they were stable in development or just not used as much. Since the list of components is a lot more manageable at this stage, we could now put in some extra effort in updating them in our 30% time. We were now clearing the backlog for our initial a11y topics.
Improving the applications
With only components updated and a11y compatible, this doesn't guarantee that the website is accessible. So during the final stages of updating the components, together with product owners we could, with relative ease, start to make the required changes to our website and apps.
Getting results
The whole process took a couple of months. This may seem long, but for an organisation with distributed teams, it's actually a pretty realistic scenario and only made possible because we didn't need to put in a request for time to work in the topic.
The period of working and communicating extensively on this topic paid off in multiple ways:
We have founded a dedicated guild to focus on and address a11y challenges
Basic a11y guidelines are part of our development flow
Our blind spot has become much smaller, which affects our new features
And it has paid off for customers as well. In the test results after our efforts, we've been able to move from 12th place to a shared 3rd place, with on of the top improvements on a11y.
Figure 1: Results of the 2021 and 2022 a11y scan by level-level.com
Where customers prior to this were simply unable to place an order, we can now provide the ordering proces for visitors relying on keyboard and/or screen reader.
Our iterative approach really helped in creating awareness within the organisation which lead to an impressive result (based on that ranking).
We realise that there's still room for improvement and from the guilds' perspective we're actively looking into more learnings and resources to share within the organisation.
We have our eyes set on the number one spot! 🏆