From XU Magazine, 
Online News

Making mobile apps accessible

April 28, 2021

This article originated from the Xero blog. The XU Hub is an independent news and media platform - for Xero users, by Xero users. Any content, imagery and associated links below are directly from Xero and not produced by the XU Hub.
You can find the original post here:
https://hmrcdigital.blog.gov.uk/2021/04/27/making-mobile-apps-accessible/

My name is Marc Belle. I work on the HMRC mobile app team as an interaction and product designer. It’s been nearly two and a half years since we released the HMRC Mobile App Design System. All public sector apps need to meet accessibility guidelines by June, so we thought it’d be a good time to provide an update on where we are.

Image of Marc Belle

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.

Comparison of hit areas between mobile web and the mobile app
The relative hit area of PAYE in mobile web compared to the mobile app. Recommended minimum hit areas are at least 44x44 density pixels.

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 broke, 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.

Expanding Row component
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.

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.

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.

Information message component construction diagram
Expanding Row component in situ on the tax credits and PAYE screens
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.

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.

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. It’s always a work in progress but we hope you find it useful and if you use it to make an app or have any suggestions to help improve it then let us know in the comment section below.

Why leave it there?

Straight to your inbox

Subscribe to our newsletter for updates as they happen
We hate spam too. We NEVER sell our mailing list.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.