It is well known that we have multiple options when it comes to making mobile applications. There is “native native” or “vanilla native” (Android and iOS directly) way, cross-platform way (same codebase that gets produces native code for both Android and iOS), a hybrid way (usually using web technologies like HTML, CSS and JavaScript to work inside native app container) and we can also add Progressive Web Applications (PWA) to the list as they can be installed on both Android and iOS even if they are only using web technology.
Having separate Android and iOS developers (or whole teams) is not an option for some (most?) organizations. So “write once, use everywhere” definitely sounds great, but we need to be aware that sometimes we “pay” for the speed of feature development that we get when we choose the “faster” path. And unfortunately it seems that in some cases we once again sacrifice accessibility because we want to spend less time and money.
Delivering value for end users is and will always be a priority. It’s often the main motivation, but we need to make our products and services accessible, otherwise we risk a lot. It depends on the type of app and targeted geography (for now at least), but we risk legal consequences and we also risk to reach less end users when our apps are not accessible.
Shifting accessibility even more left
In languages that are written from left to right – left is the start. So references like “shift left” mean shift closer to the start.
Shifting accessibility left is basically saying to think of all possible ways to consider and implement it closer to the start of whole production (already when thinking about features, personas and – technologies).
So – how to shift accessibility even more to the “left”? How to start with thinking about accessibility even earlier? Well, you need to consider the technologies you will use to build the app. Because using “native native” will allow you to make most accessible apps and by using cross-platform or hybrid apps you will most definitely run into limitations and sometimes even total lack of support for assistive technologies (and with that you will be forced into making an inaccessible app).
I’ve done quite some accessibility audits of mobile apps in the recent years, and I really need to write about this situation to make people aware of the risks:
- Best chances to make accessible apps are possible with using “native native” – separate Android and iOS apps, both respecting EN 301 549 (and when possible WCAG on levels AAA), and using best accessibility practices offered by the platform.
- Cross-platform frameworks often make your app less accessible or even totally inaccessible to some groups of users. It’s often difficult to abstract (accessibility) features into a single codebase.
- Hybrid apps are quite similar to cross-platform frameworks, symptoms are same.
- Progressive Web Applications are “only” web applications – they can be made extremely accessible if we know how to. But – users will know right away that they are not native applications and sometimes it can be an issue (not to mention limited possibilities when it comes to using the hardware features of the device).
This does not mean we need to stop using cross-platform and hybrid, not at all. They are slowly progressing and with improving focus and awareness on accessibility I surely hope they will reach the levels of accessibility available on “native native” platforms. A lot of work is done, but a lot is still needed.
Unfortunately I still see that accessibility bugs are often not a priority, and this is an additional motivation for this blog post. We all need to do more to get the accessibility prioritized. Or we risk people will abandon the frameworks. With more focus on accessibility it’s strange that sometimes accessibility issues are not worked with.
In some cases accessibility specialists do the work of reporting the issues, providing examples and even making videos of issues, just to see the issues being automatically closed as “stale”, because nobody worked on it.
Therefore I say – we need to shift accessibility even more to the start!
If you are lucky to start a new app – do your research before you choose your technology stack (platform)! It is vital to know if the platform can make your features accessible from the start. It is vital to know if you will inherit unsolved critical accessibility issues because the platform decided not to prioritize accessibility.
If platform is open source – please check open accessibility issues to get a feeling about the situation. And also – please check closed accessibility issues for even better feeling. And if you find basic and vital accessibility issues being automatically closed because they were stale – you will understand that your product may perhaps never be accessible.
You will understand that you will need to document this when you will be asked “how accessible is your app” to your potential customers and users. Basically you will need to decide who will your app discriminate.
For all of you that had to make a choice about the platform in the past – I guess that it will come to a point where you will have to rethink and consider to switch if the platform is holding back your accessibility issues.
We have a lot of choices. I love the possibility of using the same codebase to make a product that runs as a native application on Android and iOS (and yes, also web), but unfortunately it’s not so simple. We need them to be accessible. Sooner or later. Better sooner. And currently, it is not an easy task. Accessibility needs to be a priority for the frameworks as well, not only for us!
It is totally possible to make accessible apps that are as accessible as “native native” apps with cross-platform and hybrid ways, but only if our features allow us to use the parts that are accessible.
So – if we for example need to use forms in our app – then we need to check if they work with assistive technologies that are available on both Android and iOS. And if we find out that a platform doesn’t support keyboard only operation – we need to check if there are some alternatives. Perhaps our platform is already in place and perhaps we can use a third party to bridge the gap and get the keyboard support, but perhaps there is no solution yet.
Once again – accessibility issues need to be a priority and we all have a responsibility to make them a priority. Document them, open issues in version control. Advocate and when possible try to come with suggestions. And even if we do not have anything to do with the code – ask questions. Does the platform support screen-readers? Does the platform work with keyboard? Do you have any open accessibility issues and when are you planning to fix them? Do you have an accessibility roadmap? Can the platform make my app conformant to WCAG? Can the platform support EN 301 549?
Some platform vendors are already recognizing that they need to document accessibility and offer features. But it is only a start. Reported issues need to be worked on and not just automatically closed because nobody touched them!
We are in this together!
