I’ve recently done some accessibility audits on native mobile applications against WCAG and the whole EN 301 549 and decided to share some thoughts about perceived complexity. Actually how sometimes it’s very difficult to make things work on native mobile applications compared to web applications.
If we start with the summary for everybody needing it fast – it’s actually quite obvious when we compare the possibilities on the web and possibilities on iOS and Android. But to do that we need to invest a lot of time and be familiar with all three platforms. As I am originally a web developer I have quite a good understanding of the possibilities and problems there, but checking possibilities on mobile platforms was not a simple task.
Native mobile apps are locked to platform version
To put it differently – if we have an old application made for older phones we get less accessibility options. The problem is that when we want to support a wide range of users we are actually forced to support old versions. So if we need to implement user experience that is more advanced than defaults on the platform we risk making things less accessible.
Both Android and iOS accessibility API documentations include minimum versions where accessibility API / interface was made available first. Some parts are really old and go back to first versions and other are quite new and added recently.
So when we think from the aspect of accessibility – latest is best. Besides any bugs that may not be fixed for some time you can get most of accessibility API using latest version.
To be specific about it – let’s say we want to support heading levels in our native application. We will soon find out that Android don’t support them at all. And iOS only supports them in latest versions.
Another example can be support for status messages in native app applications (WCAG 4.1.3) where we can again see that it’s difficult to support them on older platforms.
So let’s imagine a scenario: we have a new design going on and we make it really accessible from the beginning. We think about screen-readers and other assistive technologies available and everything is annotated for developers, to make it easy for them. And to not forget about important details. Then the developers get to check the designs and annotations. I think we could soon find us in an impossible scenario if we have to support old versions that don’t support the required accessibility features.
So it means that designers and developers must cooperate tightly when still in design phase. So that designers know what is possible and what not. And so that developers make informed design suggestions together with designers. It’s way more complex than when we design for web because of that. Also when working on web the designers and developers should cooperate tightly, but it’s often not needed to cooperate on known patterns on the web. Because they are known.
For native mobile apps it can all drill down to the version(s) we have to support. And here is also another catch – as mentioned – if we support latest versions only we can make more accessible apps that are available to less people. If we support older versions we make less accessible apps that are available to more people.
When we support latest versions of native mobile apps we can make more accessible apps that are available to less people. When we support older versions we might make less accessible apps that are available to more people
My reflection on accessibility and availability based on the version choice.
How can we work with older versions then? I think that the only sustainable way is to not be too clever when designing them. It all drills down to user experience and patterns. If we can use patterns that are a part of the native apps functionality we can be quite certain that the whole experience will be more accessible. If we are “too clever” and invent new kinds of interaction we risk that some users will not be able to use them.
This is not only applicable for native mobile apps. It’s also true on the web. But on the web we have at least some better possibilities with ARIA. At least theoretically. While on native mobile the possibilities are narrowed down.
Accessibility of cross-platform solutions to develop native mobile applications
Personally I’ve just done some development with React Native and before that Apache Cordova. Small applications and proofs of concepts. So I am by no means an expert on the subject. But I did invest some time to check the accessibility possibilities lately, to be able to audit and evaluate accessibility of native apps and also come with constructive remediation suggestions where possible.
I will concentrate on React Native here, but I think that all – cross-platform / hybrid / whatever you want to call them – offer similar solutions and have similar problems when they try to support both Android and iOS. Just to name some possibilities when we want to write code once for Android and iOS (and sometimes also web and more);
- React Native,
- VUE native,
- Native Script,
- Ionic framework,
- Apache Cordova,
- Xamarin,
- Flutter.
The first thing I would like you to know is the fact that all of them are a bit behind “native native” in terms of accessibility (and most probably also other aspects). That is also a fact as we know that they have to implement new possibilities after they first arrive on native platforms. And sometimes it gets quite interesting there as well – because they need to support both iOS and Android they often get stucked with supporting just one of them.
Just visit React Native Accessibility page (opens in new window) and you will quickly understand what I am writing about. Search for “Accessibility properties” navigation list items and you will get my point – some properties are only working on iOS and some only on Android. I’ve just count them for you and at the time of writing we have:
- 31 accessibility properties in React Native,
- 19 of them are available for both Android and iOS,
- 5 are only available for Android,
- 7 are only available for iOS.
To be fair, this is not a problem because of React Native. React Native tries to support both Android and iOS and it’s not possible to implement accessibility properties that only exist on one platform to work on both. So these numbers don’t indicate that it’s the React Native that is the problem for all accessibility properties not being supported. It just indicates how hard it is to have same application accessible in the same way on both Android and iOS.
I am also not saying to drop React Native (or other hybrid platforms) because of this. Personally I love the idea to write once and deploy to Android, iOS (and Web). But reality is harsh and I can’t really suggest that you use React Native if you want to make your app accessible on all platforms.
I am mentioning web with React Native because it’s also possible to use same code for web. I’ve seen just some parts of the generated code and would advise not to use React Native for the web. But that’s a subject for another post.
There are of course ways of making accessible native mobile applications with these platforms as well. I think that it again drills down to design and it’s implementations. If the design supports the limitations of the platforms it should not be a problem to make final products accessible.
In case of hybrid solutions where we have to think about Android and iOS possibilities at the same time we are a bit more limited in terms of patterns but it is still possible to develop accessible hybrid applications if we calculate the limitations into designs.
To conclude this post – I really think that making native mobile applications accessible requires much more planning than making web accessible. It’s probably logical to you as well – on the web we are limited by operating systems, browsers and assistive technology, but those can be updated way faster than on mobile. Some mobile phones can’t really update after a year or two. Some have better options but still, comparing situations make it obvious that updates on PCs are way faster than on mobile devices. And those updates can and often do also include accessibility improvements, bug-fixes and new possibilities.
