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.
Tag: Native mobile application
Latest posts:
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.
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.
2023 is over, this is a short reflection about it, primarily to remember the key accessibility efforts later in life.
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.
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.
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.
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.
Every (front-end) developer should add screen-reader to their tools. Screen-reader experience can really help us make products more accessible and also be better at our coding. Combinations of screen-readers and browsers can get over complicated, so it is important to think if code we write is supported for majority.
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.