Sometimes I see complex web components copied to native mobile applications and often they are the cause of accessibility issues.
Category: Native mobile apps accessibility
Latest posts:
Any help to make native mobile application accessibility clearer is welcome. We really need to know more to make apps more accessible.
There are some limited resources on ARIA role application, but I missed more information for mobile screen readers and just quickly checked the situation on Android and iPhone. It seems that support is not there, besides some small quirks. Be even more careful with role = application!
Sometimes developers have good intentions and want to make their products more accessible, but can fake accessibility and make things even worse.
Municipality avoided paying fines after vendor of e-learning app fixed issues with 4 success criteria out of 6 tested (all A level). I found some interesting facts that seem to reveal procurement and especially awareness problems and I also offer some potential solutions.
Autocomplete and correct keyboard layout when filling out forms are simple and powerful helpers to make less errors when filling out forms. They benefit everybody, but they are even more appreciated by people with different disabilities. Web support is there for years, but what about native mobile applications?
I don’t like the fact that EN 301 549 is provided in PDF format. It’s way simpler to process HTML. And when I did some parsing I figured out I could also check how exactly does EN 301 549 goes beyond WCAG for web and mobile applications. Quite a lot is the short answer.
After auditing some native mobile apps for accessibility I tried to understand the capabilities and possibilities of native mobile platforms for Android and iOS applications. In this post I try to reflect on the fact that making native mobile apps accessible can be much harder than when we try to make web accessible.
I had to fail an Android app in a recent WCAG audit because it’s expand/collapse components didn’t have the semantics. On the review I got asked about possible solutions and here you go – hope it will help somebody make accordions on Android more accessible.
Mobile native applications are often with no headings. Sometimes even have visual headings but are missing on the semantics. Screen-reader users can and also like to navigate via headings, so we should be responsible and use them. They are supported on both iOS and Android.
It was not clear to me if WCAG 4.1.3 can be applied to native mobile applications. At least on both iOS and Android. So I did some research and came with the conclusion that we can and should or even must use status messages also on native mobile apps.