Starting to check design mock-ups for accessibility issues, long before they are implemented in code is the best practice for sustainable accessibility. Call it whatever you like (“shift left” is often used), it can really save a lot of time and resources. The worst thing that can happen if we don’t have the opportunity to prevent accessibility issues is to re-design and re-code.
Bad for business, bad for users (that is even worse for business).
I’ve done some accessibility auditing on design mock-ups (I can perhaps just say “Figma”) of website and native mobile application designs for e-commerce and was somehow surprised when I saw that web design was directly copied to native mobile application. I do love design systems, as they are central in providing accessibility as early as possible, but copy-pasting from web to mobile with no filter is a very dangerous thing.
Semantic possibilities on the web are wider than on mobile platforms
If we are really trying to make a native mobile application (and not just “wrap” a website in a container that can be installed like a native mobile app), then we need to be aware of the platform possibilities (and mostly limitations).
It’s a fact that HTML with it’s implicit semantics is a powerful accessibility-by-design system, but when we also consider the Accessible Rich Internet Applications (ARIA) we can immediately detect that designers and developers get a lot of possibilities (in terms of semantics and especially assistive technology behavior (that is mostly for screen-readers)).
I am not a native mobile applications developer, but I did a lot of research of the platform (Android and iOS), to be more effective at my accessibility auditing (and trying my best to come with practical remediation suggestions where possible). It is quite clear to me that web offers more possibilities than mobile does when it comes to semantics (especially when it comes to screen-reader possibilities). This is, as mentioned, due to HTML and ARIA versus Android and iOS possibilities.
I have not been able to make a total comparison (that can be quite an endeavor when we also add the versioning of the Android and iOS operating systems and even more when we also consider the hybrid mobile application possibilities), but it is a fact that native mobile applications can not reach the complexity that we can achieve on the web.
This is the main reason for this post – we often can’t replicate web components to native mobile applications. And we also shouldn’t. Mobile devices need to be simpler than web. Actually we should try to make the web simpler as well. That would be best if we want to make our products as accessible as possible.
But OK, on the web – we at least have the possibilities to make a very complex user experience with ARIA (please remember that some parts of ARIA are more theoretical than practical and may not work for everybody), but trying to copy complex web design to mobile applications is almost a guarantee for it to be inaccessible.
The problem is not the visuals, the problem is how to make sure it will work with assistive technologies, especially screen-readers (as we have way better control with ARIA than we have on native mobile platforms).
Keep it simple(r) on mobile or risk accessibility issues
Before the web we had graphic designers. Some of them transitioned to web and it is not a simple task without knowing the basics of coding (I usually advocate even the need to understand the basics of ARIA for best results). With the transition from web to mobile, I believe, it’s very similar – innovation originated in the design needs to be guard-railed by the platform capabilities. This is once again a team effort. Ideally a designer should understand the code, but it’s already difficult with the web. The native mobile platforms are even more difficult and abstract (HTML is simpler to understand).
So – designers need to be a bit less innovative and the cooperation with developers is even more essential if we want to succeed and make the end result accessible. Of course the developers need to really understand the accessibility possibilities and practices to be able to support designers, or the team should have access to specialized accessibility specialists that understand the native mobile application specifics. The situation gets a bit more complicated because of the differences on the platforms, their versions and then – once again – even worse when we consider the hybrid native mobile application spectrum.
Keeping the design simpler (respecting the platform as much as possible) is a quick way to make most accessible native mobile applications. The same is actually also true for the web – using the platform is mostly a guarantee for best accessibility (with small exceptions).
