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.
Tag: Android
Latest posts:
Sometimes I see complex web components copied to native mobile applications and often they are the cause of accessibility issues.
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!
We live in times where technology progress is amazing and therefore we need to make sure we don’t leave groups of people behind. Robots will obviously soon help us at home and everywhere and it is crucial we make their interfaces accessible. Or we will make our society full of new barriers for people with disabilities.
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?
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.
What are the most critical requirements for testing native mobile accessibility? What do we have to have for testing? Should we only test with phones? What about different operating system versions? This post will give you some basic hints.
A short post about my Global Accessibility Awareness Day 2022 contribution – online escape room for mobile screen-readers called Voice-Back.
What was the motivation, intention, implementation and goal behind voice-back.net.
Please try it out if you want and let me know how it went.
23th of June 2021 is the final step of Web Accessibility Directives mission to improve accessibility of web and native mobile. WCAG 2.1 applies for mobile as well, but there are some exceptions. At the same time I touch the importance of accessibility in our Covid / Corona pandemics situation.
Not everybody can or want to use their apps in a single predefined screen orientation. It should be a matter of preference and choice. That is accessibility as well. And we even have it as an WCAG Success Criteria. And yes – it should also be applied to native mobile devices.
Scaling down web browser is not enough. We should really test with physical devices and with at least Android and iOS based devices. UI and UX tests are important but so is testing accessibility with mobile screen-readers.
Mobile accessibility is also a part of Web Content Accessibility Guidelines and has been updated in WCAG 2.1. Using a screen-reader on mobile is quite an experience. If developers made apps accessible…