Mobile App Accessibility in 2025: Why It Matters, and How to Get It Right
Fiona Diggins
Imagine being suddenly unable to use a digital tool you depend on every day
Your banking app. Your email. Your health portal… all inaccessible. Not because of a system outage, but because a few lines of code were written without accessibility in mind.
For millions of people, this isn’t a hypothetical scenario. A few missed accessibility labels or incorrectly worded actions can make critical functionality not just unusable but effectively invisible. Accessibility isn’t about extra features or add-ons; it’s about making your product or service available to anyone. If you’re not implementing even the most basic considerations (like screen-reader support) your users can be cut off from vital services.
In 2025, with the technology we have available and at the rate it is advancing, implementing accessibility shouldn’t even be a challenge. Sadly though, according to a study by Infosys, only 3% of organisations in Australia and New Zealand currently meet digital accessibility standards.
Despite this, accessibility often slips down the priority list in digital products and services. We’d argue this isn’t done in malice, but a lack of understanding of the importance and a failure to understand that if done during the Software Development Life Cycle (SDLC), it’s generally an expensive proposition.
The truth is simple: overlooking accessibility doesn’t just exclude users. It exposes businesses to legal, reputational, and financial risk and shuts out a significant portion of your audience.
In this comprehensive accessibility for mobile apps article we’ll cover the following topics:
A QA Tester’s View: Personal insights on quality, empathy, and inclusion
Beyond Compliance: Losing users, legal risks, and business benefits
Apps for Everyone: From accessibility to inclusive and universal design
Design Principles for Retention: How a11y boosts engagement and Day 1 stickiness
Designer Tips: Contrast, typography, layouts, and clear hierarchy
Why Barriers Go Unnoticed: Common issues and simple fixes
Developer Essentials: Native components, labels, and screen-reader testing
Testing Best Practices: Automation + manual + real-user feedback
Ongoing Maintenance: Audits, WCAG 2.2, and preparing for 3.0
A QA Tester’s Perspective on Accessibility
As a QA Tester, verifying quality includes making sure all features are accessible and work properly across as wide a variety of devices, assistive technologies, and input methods as possible.
But it’s more than that. As a team, Adapptor’s priority (and our vision) is to work with our clients to build the best possible product experience for all users. That means bridging accessibility gaps so no one is barred from using digital services that may be essential to their everyday lives.
While I’m fortunate enough not to require assistance to use digital technology (my hearing, vision, and motor skills are [currently] healthy), I still care deeply about accessibility. Aside from knowing these things could easily change and I could one day require these features, it's about ensuring everyone has the ability to live their life as fully as possible.
Outside of QA, I run a bird rescue sanctuary which provides lifelong care for many disabled birds. Through this, I’ve met people from all walks of life, each navigating their world in different ways. Some rely on assistive technologies like screen-readers just to perform everyday tasks that many of us take for granted.
That experience has helped me realise that an app which doesn’t support all users is:
Unnecessarily preventing people from accessing services or information.
Not making optimum use of what’s already built into iOS and Android systems.
Not of the highest quality possible—and shouldn’t be considered as such.
Accessibility isn’t just a legal and functional requirement; it’s a measure of empathy, understanding, and true product quality. Every time an accessible feature enables someone to complete a task, find information, or enjoy an activity independently, it’s a reminder that quality isn’t only about performance or polish, it’s about inclusion.
Did you know two of the most frequently cited accessibility challenges of mobile apps are orientation and dark mode? Features that many people take for granted (in fact, I keep my phone’s orientation function locked in portrait, since I find unintentional switches between to be quite jarring), can literally make the difference between the app being usable and not.
Users who have their devices in a fixed position, or may require landscape mode to make text and images larger, are unable to use an app which only supports portrait mode. (This is made even worse by apps that don’t support text sizing or pinch and zoom.)
For users who suffer from migraines, black text on a white background can be enough to trigger migraines.
When I’m testing an app, whether for functionality or usability, user experience is constantly at the forefront of my mind.
When we set aside Assistive Technologies (ATs), meaning equipment or devices that help people do things they otherwise couldn’t do due to their disability (NDIS, 2025), the following questions help assess the basic quality of an app:
How easy is this app to use, in its default state?
How is the onboarding process, and initial usability set-up?
If a screen is scrollable, what’s off-screen that might be easy to miss?
If there are buttons/navigational links, how accurate do I need to be with where I tap?
How much risk is there in accidentally touching something else nearby?
Aside from work, I spend a lot of time looking at apps for personal use, particularly to assist in everyday organisation due to ADHD. I regularly go through the App Store downloading various apps to try, and deleting them just as quickly, when onboarding is confusing or lengthy, or the task I’m using the app for isn’t able to be completed quickly and with minimal effort.
These frustrations have shown me firsthand that the difference between an app I keep and an app I delete often comes down to clarity, ease, and cognitive support. And that brings me to the bigger picture: accessibility matters for far more than meeting standards.
Why Accessibility Matters Beyond Compliance
You’re Losing Users
Picture this: a user with low vision relying on a screen-magnifier in your app. If your colour scheme lacks sufficient contrast (for example, grey text on a light background), that person simply can’t read your content and will abandon your app immediately.
How a user with protanopia colourblindness sees the Google Maps app
Or someone with motor-impairments struggling to tap a small icon. It’s worth remembering what’s effortless for one user can be impossible for another.
Apple suggests a minimum of 44pt for hit targets for buttons. Any smaller and misfires can occur causing frustration
At Adapptor, we’ve seen firsthand how small design and development adjustments, like ensuring proper colour contrast, providing descriptive labels, and expanding tap targets, can dramatically improve usability and reduce user frustration. These aren’t big changes in scope, but they have a huge impact on inclusion.
Accessibility Has a Legal, Ethical, and Business Value
In Australia, the Disability Discrimination Act 1992 (DDA) requires digital services to be accessible (WCAG 2.2 AA seems to be the minimum standard at least for government). Ignoring accessibility not only risks complaints or legal consequences, it damages reputation.
Ethically, inclusive design ensures everyone can use your app, regardless of their ability.
From a business perspective, accessibility broadens your audience. The Australian Bureau of Statistics (2022) reports that 21.4% of Australians (about 5.5 million people) identify as having a disability. Designing inclusively means you’re not excluding one-fifth of the population.
Accessible apps also have better retention, higher ratings, and fewer support requests. While integrating accessibility early can add 10–20% to project costs, retrofitting later can cost significantly more in fixes and lost goodwill.
Don’t Forget: Apps Are for Everyone
Producing an app isn’t just about aesthetics and functionality, it’s about creating an experience that works for all users. We often think of ‘accessibility’ as the goal, particularly since it’s still an evolving process and in its early days for the majority of businesses, but really it’s only the minimum standard for removing preventable barriers.
Inclusive design goes a step further by acknowledging that users experience the world in different ways, including visually, cognitively, and physically. It intentionally builds flexibility into the interface to accommodate that diversity.
But universal design is the goal: One design that works for everyone, without needing adaptation. Universal design isn’t just about complying with standards; it expects differences and anticipates individual needs and preferences, so all users can engage equally, regardless of ability, device, or situation. If you’re only considering happy paths within your mobile app designs, try to think broader to aim for universal design.
Design Principles of Successful Apps and How Accessibility Supports Them
Here’s a scary statistic: according to Userpilot (2025), the average app retention rate (across platforms) after one day was 20-25%.
That means, at most, only a quarter of users still use an app after the first day.
Anyone involved in the app development process from conception to post go-live monitoring should question why this is, and actively work to improve that number. If your app retention rate is low, it’s not that it isn’t being downloaded; it’s that something (or multiple things) are making the app experience less than optimal for the users.
Accessible apps have better retention rates, and it’s easy to understand why. Inclusive, well-considered design means not just optimising functionality and minimising the number of defects; it’s about creating a positive experience for every person using the app.
According to Jhavtech Studios (2005), there are seven design principles underpinning high user retention rates. These include:
Design for simplicity and speed
Follow Apple’s Human Interface Guidelines (HIG), which emphasise hierarchy, harmony, and consistency
Create onboarding that actually onboards, according to a study by Localytics, effective onboarding sees a 50% increase in Day 1 retention
Ensure consistent navigation and common gestures
Know that personalisation enhances engagement
Utilise feedback loops and microinteractions. Subtle yet powerful cues can reassure users that their actions are working as intended
Give dark mode and accessibility options. Making sure your app supports even basic accessibility features, like dark mode, VoiceOver, and text sizing, reduces frustration and makes users more comfortable in being able to adjust settings for their needs.
While number seven directly references accessible design, most of these principles improve accessibility by default. When accessibility is part of your foundation, users spend less time struggling and more time engaging right from the first tap.
Other Key Considerations for Designers
Following the mentioned patterns as a designer can dramatically improve the level of accessibility within your experiences. But what about some practical examples? Here’s several small things you can do to help you meet an accessible standard.
Colour contrast and visual clarity: Use accessible colour palettes and verify contrast ratios meet WCAG 2.2 guidelines.
Typography and spacing: Choose readable sans-serif fonts with adequate line spacing.
Responsive layouts: Ensure UI adapts smoothly across different screen sizes, orientations, and text sizes.
Clear language and content hierarchy: Write in plain language and use logical heading levels (H1, H2, H3) to make the navigation as easy as possible for both sighted and SR users.
Why Accessibility Barriers Often Go Unnoticed
Accessibility barriers are easy to overlook when you don’t experience them yourself. If your vision, hearing, cognition, and motor abilities are typical, most apps can be navigated through without a second thought; in many cases, muscle memory does much of the work.
For many users, though, every tap, swipe, or line of text can be a hurdle; not because they’re doing anything wrong, but because the product wasn’t built with them in mind.
We’ve listed out all of the common barriers users face based on our over 15 years experience. If you address these, you’ll be most of the way there for a highly accessible app.
Barrier | Typical issue | Solution |
Visual | Text that blends into the background, or fonts too small to read comfortably | Meet a 4.5:1 contrast ratio and support text resizing |
Auditory | Alerts or videos that rely solely on sound | Provide captions and text alternatives |
Cognitive | Dense text, confusing navigation, or unpredictable layouts | Use plain language, clear headings, and consistent patterns |
Motor | Buttons that require precise tapping, or controls placed too close together | Ensure 44 × 44 dp minimum targets; support alternative inputs |
It might sound like a lot, but it’s surprisingly simple to incorporate into each part of the process, from conception to testing the final product. (In fact, many teams already apply these instinctively without fully realising their accessibility benefits.)
Let’s Get A Bit More Technical: Some Practical Takeaways For Implementing A11y
Accessibility Essentials for Developers
Accessibility in development is about building inclusivity directly into the foundation of your code, rather than patching it in later. When mobile app accessibility is treated as part of good engineering practice, it naturally leads to cleaner, more maintainable, and higher-quality code.
Good, universal development practices include the following:
Use native UI components wherever possible
Native components (like Button, Switch, TextField) come with built-in accessibility traits and behaviours:
They announce correctly to VoiceOver and TalkBack
They support focus, actions, and states
They behave consistently across devices
Custom components require developers to manually add accessibility semantics, leaving more room for error.
Only override accessibility attributes when necessary
Flutter, SwiftUI, UIKit, and Jetpack Compose all provide platform-specific accessibility APIs (e.g. Semantics(), .accessibilityLabel(), androidx.compose.ui.semantics).
Defaults should only be overridden when the native component does not adequately express its purpose.
Examples:
An icon-only button needs a verbal description.
A custom control with no native equivalent needs manual semantic roles or states.
Only Use Accessibility Labels in Specific Situations
Accessibility labels (e.g. .accessibilityLabel() in SwiftUI, semanticsLabel: … in Flutter, semantics { contentDescription = … } in Compose) provide spoken descriptions for screen readers only when needed.
Use labels when:
A control has no visible text (e.g. icon buttons)
Visual meaning needs explicit clarification
A state or purpose isn’t obvious
Avoid labels when:
There is already visible text. Let the assistive technology read the on-screen text
The element already conveys meaning clearly without additional description. if an icon is accompanied by text or is part of a labelled UI component, adding extra labels causes redundancy.
They include information not available to sighted users. The same information should be available to everyone
The element is decorative. It leads to verbosity and confusion
Ensure You Use Screen-Readers To Test Compatibility
Screen readers like VoiceOver (iOS) and TalkBack (Android) are the primary way many users interact with mobile apps. Testing compatibility isn’t just about hearing that labels are read; it’s about verifying that the user experience makes sense when navigated non-visually.
Developers should:
Ensure focus order follows a logical, predictable path that mirrors visual layout.
Confirm dynamic updates (such as new content appearing after an action) are announced correctly using ARIA live regions.
Avoid trapping users in custom components without clear exit points.
Test regularly with VoiceOver and TalkBack during development, not just before release.
When accessibility is tested continuously, issues are cheaper to fix and far less likely to slip into production.
Okay, That Covers Design & Development. Let’s Talk Testing.
Accessibility testing is essential, and can’t be left to a single audit at the end. While automated testing can play an important part in highlighting technical issues, nothing beats manual testing to ensure accuracy and to find issues that automation never catches.
The most important point we can raise here with regards to accessibility testing is that nothing can match or replace the value of real user testing; that is, by individuals with disabilities who face accessibility barriers every day. Their feedback reveals practical, lived experiences that automated tools and traditional QA cannot, and will never replicate.
A Quick Primer on Manual vs Automated Testing
Automated tools are great for quickly scanning an app to detect obvious technical issues, like:
Missing alt text
Colour contrast failures
Missing form labels
Incorrect heading structure
But they’re not perfect, and this is where false negatives come in.
What a False Negative Means
A false negative is when the tool says ‘no issue found’, but there actually is one. In other words, the automated scan misses a real accessibility problem.
Example:
A button has a label, so the tool passes it… but that label might be confusing to a screen-reader user (e.g. “Tap me” instead of “Submit form”).
The tool can’t understand the context or intent, so it falsely reports that everything’s fine. This is an example of automation failing to understand the accessibility problem.
Why False Negatives Happen
Automated tools can’t:
Understand visual or contextual meaning (e.g. “Does this text make sense out loud?”)
Detect whether focus order follows a logical path
Evaluate readability, tone, or cognitive load
Test gestures or interactions on mobile (like swipe, drag, or double-tap)
In short, they can catch roughly 30–40% of common WCAG issues, but the remaining 60–70% require manual or user testing.
Best Practice
An approach that we’ve found works well is to bring in automation early. Tools like Android’s Accessibility Scanner or iOS’s Accessibility Inspector can quickly flag basic issues like missing labels or low contrast. It’s a fast way to catch the low-hanging fruit.
That said, as mentioned, automation only gets you so far. You need to follow it up with hands-on manual testing: try navigating with a keyboard, run through the app with VoiceOver or TalkBack, and check how gestures work for everyone. These checks often reveal things the scanners miss.
If you can, involve people with disabilities in your testing. Their real-world feedback shows what actually works (and what doesn’t) in ways no tool can replicate.
And it’s worth repeating: don’t leave accessibility to the end. Build it into your regular testing cycles. Make it a part of every sprint and every update, so it stays solid as the app evolves. That way, you’re not just meeting standards. You’re making something that truly works for everyone.
Some Final Tips
Accessibility should be thought of like security: you don’t ‘finish’ it; you maintain it. A great app development team should bake it into the SDLC. Here’s a few ways you can do that.
Quarterly Accessibility Audits
If possible, try to conduct a11y audits throughout the year to maintain quality. This could take the form of a full app scan using GSCXScanner for Android for instance. You’d ideally want three to five participants and ensure the final report is shared with the team and findings added to your product backlog.
Stay Ahead of Standards
It’s important to stay ahead of the standards if you hope to remain as inclusive as possible within your app development. WCAG 2.2 was released in December 2024, which introduces key requirements like Target Size (2.5.5), ensuring interactive elements are large enough for all interactions, and Dragging Movements (2.5.7), requiring non-dragging alternatives for all dragging functionality. You should consider being compliant with these criteria right now.
Looking ahead, WCAG 3.0 is being developed and represents a huge shift. It moves away from the current pass/fail ‘success criteria’ to a system based on ‘outcomes’ and a more nuanced scoring model, which requires a more holistic approach to user experience. You should start familiarising yourself with these concepts now to prepare for the future of accessibility. It’d also be a great idea to subscribe to the W3C Accessibility Newsletter for direct updates.
In a Nutshell
In the end, building accessible mobile apps in 2025 is about recognising that true quality isn’t just smooth performance or sleek design, it’s creating experiences that welcome everyone, no exceptions.
From catching basics early with automation and hands-on testing, to weaving in real user feedback and staying ahead of evolving standards like WCAG 2.2, it doesn’t have to be complex or costly when it’s part of the process from day one.
At Adapptor, we see accessibility not as a checkbox, but as a commitment to empathy, inclusion, and building products that genuinely improve lives, because an app that works for all isn’t just compliant; it’s complete.
Ready to make your app truly universal? Give us a call on +61 (0)8 6381 9170 or email us at hello@adapptor.com.au
