Clear content: writing for screen readers

It’s all systems go here as we’re currently designing and building a new app. I’m the Senior Content Designer making sure our content is clear, consistent and has a bit of Virgin sparkle.

Creating accessible content is at the heart of my work. I was recently part of an exploratory project looking at how we make sure our new app works for screen readers.

Let’s start with a bit of context. There are over 16 million disabled people in the UK, over 2 million of which live with sight loss (figures from the Family Resource Survey 2022 to 2023 and the NHS). Most people with sight loss use screen readers on their phones and laptops. If a website or app doesn’t work well with a screen reader, it risks excluding people from using that product or service.

One step at a time

I worked closely with two fantastic engineering colleagues. We first looked at our ‘Make a payment’ journey, a standard set of screens in most banking apps. We wanted to understand how a screen reader navigates the existing journey. This proved to be a difficult experience, often ending up stuck on screens but we learnt a lot.

We’re building our app using Flutter, an open-source app development kit. Flutter has several accessibility widgets, which means we can customise the experience for screen readers.

Push the button

We found that often buttons caused the most issues on our screens. Anything that is tappable is considered a button. But without adding a label, a screen reader won’t tell the user that it’s an active component.

Our design patterns mean we often have buttons that aren’t enabled, this is when the button is greyed out and you can’t tap it. It means we don’t have multiple error messages for every page. But this isn’t helpful for someone using a screen reader. To make this a better experience I added hint text to explain the button wasn’t enabled and what the user needed to do to progress on in the journey. I created a consistent approach across all screens to describe this.

Making it logical

We also found that when something looks good it doesn’t always work so well for a screen reader. When a user enters the amount they want to pay, their account balance comes after where they enter the amount. A sighted user wouldn’t think twice about this, in fact it’s very useful to have your balance as a reminder when you’re transferring money. But someone using a screen reader won’t have the balance read out to them until after they swipe beyond the input area. Meaning they’ll choose how much money they want to send and then they’ll hear their existing balance.

Luckily, Flutter lets us decide the order that things are read out on a screen. We switched this around for screen readers so all the useful info was read out before a user inputs the payment amount.

Number crunching

We have a lot of numbers on our screens, it’s a banking app after all. I learnt you must always define the type of number. Is it a sort code that should be read out as individual digits? Or is it a balance that needs to include the currency? Before we defined this in Flutter the account number was read out as a number in the millions!

I also had to add in extra content for screen readers when there was a list on the screen. Visually you can see if you have 3 accounts to choose from, but we had to make sure screen reader users got the same experience. We wanted to save them time and give them that information upfront. So for any list on a screen, I added in a count to be read out. A simple ‘account number 1 of 2’ did the trick.

What's next?

We’re working to test and iterate as much as possible. I’m working with a colleague who uses a screen reader. Their feedback and insight has been, and continues to be, essential for this work.

I’ve also developed a process for screen reader annotations which the developers use. These annotations describe the order and what will and won’t be audible on the screen. We're introducing this to all our squads’ build cycles.

We hope to continue to learn and refine this work and make sure that our app works for everyone, no matter how they access it.