Making mobile apps accessible

Breaking the rules

We designed the HMRC Mobile App Design System as an extension to the GOV.UK Design System to create greater consistency in the app and enable government mobile apps to be more scalable and accessible because they are unable to use the main GOV.UK Design System.

The GOV.UK Design System is what all of government is meant to follow as a baseline, but because it is web-based it doesn’t always work for native mobile apps like ours. App design can have different requirements to websites, for example, apps use buttons not inline links because the hit area of a finger needs to be greater than that of a mouse pointer.

Apple and Google have also spent considerable time developing patterns and native components that users have become familiar with and which we can benefit from both in terms of minimal development overhead but also tried and tested accessibility.

I speak more about the creation of the Mobile App Design System in a previous post but as we discovered, in our attempts to make the app accessible, not everything can be ported from web to app design. We’ve added new components, updated others and even removed one or two.

If it's broken, fix it

The expanding row was one of those that we have removed and was a good example of where things that work on the web don’t necessarily translate to apps very well. Ensuring the app is accessible is high on our priority list, so each component is tested before it goes into the app and then again when it is in the environment intended for its use. In practice, the expanding row provided the ability to hide useful information that wasn’t always required but it came with its own accessibility challenges.

During testing, we found that iOS devices wouldn’t alert the user that the row had expanded. It came down to a complication where the device wouldn’t know that a change had occurred on the screen when a user had expanded or closed the row. So, for users using VoiceOver, they wouldn’t know there was new content to read. We tried a few workarounds but after a lot of trial and error, we decided that it was best to remove it. And to ensure we didn’t complicate things for ourselves by having different implementations on both platforms we removed it on Android as well.

When using VoiceOver, the expanding row (deprecated) wouldn’t alert the user when it opened or closed. Even with a workaround that forced it to, if the user tried to move to the next item quickly it would skip reading the new content sometimes partway through.

COVID challenges

COVID-19 too brought new challenges when we needed to rapidly deploy important announcements via the app that would frequently change. Having the Mobile App Design System’s atomic approach as a basis to work from meant we could do just that. For those that don’t know, each time you make a change to the app it needs to be pushed to the Apple App and Google Play stores as an update. So, with frequently changing announcements it would have required users to download a new update each time, so we needed a way to prevent this.

We developed a new information message component that was built from other already existing components that could be constructed and deployed on demand. It then allowed us to add messages to the app without the need to republish to the Apple App and Google Play stores. Information messages could be added or removed and content updated remotely meaning users didn’t need to update their app each time there was a new announcement.

And because of the flexibility of the design system’s atomic approach, it has meant we can also use the information message to send other useful information such as letting users know if they are entitled to a Help to Save account or to sign up for paperless messages instead of post.

The information message is built on the warning message component. It can contain buttons and have specific colour themes, such as that for COVID-19 related announcements, to let users know of important changes that might affect them or helpful features that might be useful.

Better accessibility together

As we gear up to meet upcoming accessibility regulations in June the Mobile App Design System has come into its own and as version 2.2 is released, almost every area of the app now uses it and internally we’ve used it to build another two apps.

At the end of last year, we publicly open-sourced the Mobile App Design System, as well as the iOS and Android component libraries, to make it easier for HMRC, the rest of the public sector or anyone else, to make accessible apps.

Come work for us!

If this work sounds interesting, check out all our current vacancies. They’re updated regularly so worth keeping an eye on.