Accessibility regulations were made UK law on 23 September 2018. The aim of the regulations is to make public sector websites and mobile apps accessible to all users. The deadline for public sector websites to be accessible and to have published an accessibility statement was 23 September 2020.
From 23 June 2021, public sector mobile applications, or apps, need to be accessible and publish an accessibility statement.
The technical accessibility standard is the same for mobile apps as for websites (EN 301 549 v2.1.2), which for the most part translates to the Web Content Accessibility Guidelines (WCAG) 2.1 AA as the minimum level of accessibility. There are some WCAG success criteria that do not make sense for mobile apps, and extra guidelines for mobile features such as biometrics, which we explain more in our information about the requirements.
We’ve been talking to teams in the public sector that develop mobile apps to find out what makes a good accessible app.
Use native features when building mobile apps
Where possible, use native Android or iOS components to build your app to be accessible. This normally means you get all the in-built accessibility features of the mobile operating system - but you should double check, for example, how a component reacts to screen readers and keyboard/switch inputs (switch access is assistive technology that is often used on mobiles).
If your app is complex, or you have many teams working on it at once, you may want to develop a component library with approved, tested items that teams can use to build new functionality and screens. HMRC have written a blog post about how they use and manage an app component library.
When designing and building accessible screens in a mobile app, it’s important to make sure the design is flexible enough to cope with both portrait and landscape views, and users with different accessibility features set in the operating system (OS), such as dark mode, different text sizes and bold text.
It’s likely you’ll need to present some information from your website within the app; for example, you may want to store cookie and privacy information on the web. You can use embedded web browser views within your app, but you’ll need to test to make sure they are still accessible and it’s easy for users to get back to the main app.
Differences to the web
Mobile views or screens are built differently to web pages made out of HTML and CSS. Some functionality that makes navigating a web page easy using a screen reader is not available; for example, in HTML you have a number of different levels of headings, so the designer can give structure to the web page. In apps, there are headings, but not different levels, and it’s easy to create a lot of headings in an app. This can mean a lot of text will be read out as headings, and users will find it hard to understand the structure of the app screen.
Think about the order that information will be read out on an app screen, and that it may not match the visual display that has been designed. User testing will really help guide the order of what’s most important to read out first.
Another big difference between web pages and apps is that there are often more dynamic changes happening on screen when using an app. You should make sure that people using assistive technology know that a change has been made to the app screen, but you also want to make sure that the alerts and updates are relevant. Do not overload users with updates.
Testing mobile apps for accessibility
You’ll need to test the accessibility of your app on a variety of real devices - you could miss real-world issues if you’re only testing on simulators or virtual devices. There’s a wide range of Android devices with different versions of screen readers so you’ll need to pick a representative sample of devices to test with. If you’ve already got a live app, you should be able to get analytics on what devices your users are using.
Most of the accessibility testing will use the in-built screen reader software - TalkBack on Android and VoiceOver on iOS. It is also worth testing using technologies such as keyboard navigation and switch access.
It’s really important to test input validation and form errors in the app, as well as expected paths through your user journeys. Also, try rotating your phone and changing OS settings mid-flow. You’ll want to test with a comprehensive range of accessibility feature settings to make sure all users get the same experience.
There are some accessibility checkers for Android devices, such as Google’s Accessibility Scanner and Deque’s Axe for Android. These will highlight some underlying technical issues in the app, but these should be picked up in the screen reader testing. They may also speed up some tests, such as colour contrast.
Publishing app accessibility statements
Public sector mobile apps need to have accessibility statements, like websites. You should make the accessibility statement available in the same place users can find out more information and download it, such as a webpage on your website where you talk about the app). It’s best practice to also make the statement accessible from within the app, either on the launch screen, throughout the app in a footer, or through an obvious section such as Help or Accessibility.
Find out more
Google publishes information about testing mobile app accessibility in Android and Apple has developer guides about making your iOS app accessible.
Thanks to the people we have spoken with about mobile app accessibility, especially the HMRC app and accessibility teams.
If you have any questions about mobile app accessibility, join the cross-government accessibility community, and for more information about the accessibility regulations, see gov.uk/accessibility-regulations.
1 comment
Comment by LastPlot posted on
This is really helpful! Thanks for this initiative.