To really set the scene for this article, I need to go back in time. March 2020 to be precise. Ring any bells? The pandemic had just started and we were seeing a massive surge in customers turning to online grocery shopping rather than in-store. Our slots were filling up fast, customers were finding it more and more tricky to secure one. It wasn’t long before complaints started to pour in regarding the lack of slots!

On top of this, many areas of the app were not meeting accessibility guidelines — essentially a significant number of elderly and vulnerable customers were struggling to navigate and interact with us.

So how did we know we were inaccessible?

Due to our increased amount of traffic during the pandemic, we prioritised our vulnerable customers. In turn, this meant we were receiving regular feedback from this group of customers regarding poor contrast levels and trouble using their screen readers. We decided to ask RNIB to run an audit of the app too, the audit covered the whole app but it became apparent that the slot booking screens needed the most immediate attention.

“From Grey to Black. Please, please give all of us old people and others with poor eyesight the option to make the faint light grey font black and possibly bolder. My screen reader (voice over) doesn’t work well with this app, for instance with the slot booking calendar.”

“My screen reader doesn’t work well with this app, for instance with the slot booking calendar.”

“The time slots in the table are inaccessible with VoiceOver meaning a speech user will not be able to use the table to select their delivery slot.”

So, we knew something needed to change, the app design and product team set upon an action plan. We essentially broke this work down in to 2 phases. Phase 1 was to look at the visual design improvements, for example, the font sizes and contrast levels. Phase 2 would be to define the accessibility requirements for booking a slot, i.e screen reader functionality.

Phase 1 — Visual Design Improvements

It was clear we needed to make some design changes to the slot booking screen following the audit and regular customer feedback.

Below is a list of design changes we set out to make to the slot booking screen. There was of course investigatory work involved in this too so the list below probably doesn’t do justice to the amount of changes required.

To fix:

• Explore font weights used on the Book A Slot screen, particularly paying attention to dates and times

• Explore font sizes used on book a slot screen

• How can we improve the contrast and readability of an available slot cell

• How can we improve the contrast and readability of an unavailable slot cell

• How can we improve the contrast and readability of a confirmed slot cell

• Define spacing between cells, cells feel too close to each other and hard to navigate between

• Define colours of iconography

• When a customer scrolls across the grid to find a slot, how can we emphasise the date and times rather than it all merging in to one

Below I have highlighted the next 2 design iterations we made on the book a slot screen. The last image is the most up to date version of the screen and we can see that the issues mentioned above have all been addressed.

Now that we had made visual improvements, we could move to phase 2 of the improvements.

Phase 2 — Screen Reader Improvements

The idea of the second phase was to define the screen reader labels. The Waitrose app is available in both iOS and Android, so we had to consider there would be differences in screen reader behaviours.

Generally speaking, if you use an iOS device, the screen reader software you can use is called VoiceOver. If you are an Android user, the most commonly used software is TalkBack. They both work in similar ways but there are subtle differences, we made sure to highlight these in our documentation.

The book a slot screen was probably one of the first screens we designed on our app, so this meant we had to go back over our design files and retro fit accessibility documentation in to it. However, going forward, we are building accessibility in to our definition of done for all our design work, this will save us revisiting screens to fix the accessibility in the future. This is also the right thing to do, accessibility becomes embedded in our day to day work.

Here is our definition of done for accessibility:

• Create accessibility guidelines (for Android, iPhone and iPad)

• Define voice over labels for all elements of the designs (including headers, components, etc.) — Review copy with UX Writer

• Define reading order of all the elements (component wise and screen wise)

• Document all of the above mentioned and anything else you find necessary in our Features Accessibility Overflow documentation or (if it’s only a component) add it to the existing component’s documentation in it’s library

So, let’s take a look at the documentation in more detail then. The documentation is made in OverFlow, allowing us to share easily between designers, developers, product owners and other stakeholders interested. The first page is a “read me” file to help understand how VoiceOver and TalkBack work in apps.

We then have a page with all the accessibility components we use to label the screens, defined by different colours for different behaviours.

We broke the book a slot screen in to sections (A, B, C). We then defined the order of how elements should be read out. We also noted down where we wanted the voice over to say something different to what is on screen. For example, at the top of the screen, the customer has the option to switch between delivery and collection slots. If the screen reader was to read this exactly as it is on screen, it would just read “Delivery Slots”, and the customer would not know they can change to collection slots. For visual users the chevron helps them understand its a drop down menu. For this reason, we changed the screenreader to say “Delivery Slots: Double tap to change shopping method”.

We noted down if icons should be read out, in our view, we felt that icons were decoration most of the time so it felt unnecessary for screen readers to read them out. We also highlighted if any hints are required, a hint gives an iOS user more context to something that is read out. For example, in the image below we can see the calendar button reads out “<Button> Selected 4th October 2020” and then there is a hint — “<Hint> Double tap to change”.

So with all this documentation complete, here comes the exciting part, where we see it in practice. Let‘s take a look at out how the screen behaved before we made any improvements.

I’d like to point your attention to the calendar at 1:16 in the video, this is a really bad example of accessibility, there is no context as to where the user is on the screen once they start tabbing through days and the screen reader even reads “PNG attachment” for the icon! As the video continues, we notice that days of the week are read out as letters “S, M, T…”, and the dates are read out as numbers. How would a visually impaired person know which day of the week they are on? It would be very hard to memorise the columns and rows.

Here is the same screen but with our improvements made. You can hear the calendar has been clearly defined now, the days are easy to understand and you know where you are on the screen.

Of course, we know this isn’t the end of our journey on accessibility. We will continue to make improvements. The designers have ongoing discussions with the developers and product owners on how to iterate and improve on the experience. We regularly watch out for any specific customer feedback around accessibility, and we were particularly proud of this one lately.

Your app is perfect for partially sighted people 👏

We also now have accessibility built in to our Definition of Ready and Definition of Done in all our design tickets. Every designer in the team is familiar with the accessibility documentation process and for any new designer joining the team — accessibility is part of the onboarding process.