WCAG 4.1.3 is dedicated to status messages and we encourage their use, but we need to be aware of some potential dangers that are often beyond strict technical conformance.
Category: Native mobile apps accessibility
Latest posts:
You connect your physical keyboard to an Android device and start pressing the tab key. And then shift tab. And sometimes – you circle around the UI but can not reach all interactive elements. Is this a WCAG 2.1.1 failure? Maybe it is, maybe you need to try harder…
This is a summary for my Universal Design 2024 (UD2024) conference contribution, where I was using parts of EN 301 549 and WCAG to check how (in)accessible are iOS and Android mobile applications from 4 largest Norwegian banks.
Web Content Accessibility Guidelines touch keyboard accessibility in a couple of success criteria. It’s essential for your native app to support keyboard interactions for it to be accessible. But how?
Grouping is not an exact science, but all designers and developers touching native mobile applications need to be aware of the simplification possibilities it can bring.
Naming is one of the most difficult and enduring challenges in software engineering, and it is obvious that it’s also a giant problem in accessibility. How can you help?
Native mobile applications are often more focused and with that – less noisy for users (and I meant that visually and non-visually). But platform choices can lead to inevitable inaccessibility as some abstractions lack support.
Sometimes I see complex web components copied to native mobile applications and often they are the cause of accessibility issues.
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.