Mobile Accessibility Testing: Find and Fix Violations Before App Store Review

In our practice, VoiceOver on iPhone reads "Button" instead of "Add to Cart" — because the `UIImageView` with the cart icon lacks an `accessibilityLabel`. A user with visual impairments taps blindly. This is not theoretical: 2.2 billion people have vision impairments, and Apple/Google now reject app

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
Mobile Accessibility Testing: Find and Fix Violations Before App Store Review
Medium
~2-3 days

Our competencies:

Frequently Asked Questions

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    895
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    782
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1216
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1079
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    1002
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    597

In our practice, VoiceOver on iPhone reads "Button" instead of "Add to Cart" — because the UIImageView with the cart icon lacks an accessibilityLabel. A user with visual impairments taps blindly. This is not theoretical: 2.2 billion people have vision impairments, and Apple/Google now reject apps with gross accessibility violations during review. We are a team of engineers with 6 years in mobile development; we have completed over 40 accessibility audits. We conduct accessibility audits and guarantee compliance with WCAG 2.1 AA.

Why is accessibilityLabel so often missing?

Custom components — sliders, custom buttons, icon-only elements — lack automatic labels. VoiceOver reads coordinates or class names. On iOS you must explicitly set accessibilityLabel and accessibilityHint. On Android — contentDescription in XML or via ViewCompat.setAccessibilityDelegate. Developers often forget to set a label when creating a custom view. In 70% of cases, the problem is solved by adding one line of code.

How to properly manage focus after closing a modal?

After closing a modal, VoiceOver/TalkBack focus remains on elements no longer on screen — the user gets lost. On iOS we control via UIAccessibility.post(notification: .screenChanged, argument: targetView). On Android — ViewCompat.setAccessibilityPaneTitle and sendAccessibilityEvent(AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED). Manual verification of this scenario is mandatory: automated tools do not always catch focus loss.

Testing Tools

Accessibility Inspector (Xcode). Launch via Xcode → Open Developer Tool → Accessibility Inspector. One-click audit finds missing labels, small touch targets, contrast issues. Works on simulator and real device.

Accessibility Scanner (Android). An app by Google that scans the screen and lists problems by type. Integrates into Espresso via AccessibilityChecks.enable() — automatically runs checks on every test action:

@Before fun setup() { AccessibilityChecks.enable() .setRunChecksFromRootView(true) } 

Each Espresso test now additionally verifies a11y — any violation fails the test. Accessibility Scanner processes a screen in 2–3 seconds, 5x faster than manual checks.

Manual testing with VoiceOver/TalkBack. We walk through key scenarios: registration, purchase, main user flow — using only screen reader gestures, no visual feedback. This catches semantic issues automation misses: logical reading order, unclear label wording, lost focus.

axe DevTools Mobile. A commercial tool with detailed violation classification per WCAG. Provides a report with severity and criteria references. Useful for EU Accessibility Act compliance preparation.

When is manual testing required?

Automated tools cannot check reading logic and ease of perception. If the app has complex animations, dynamic lists, or non-standard gestures, a manual run with VoiceOver/TalkBack is essential. We recommend manual testing after each major release.

Audit Matrix

Violation Automated test Manual test
Missing accessibilityLabel Accessibility Scanner / Inspector VoiceOver
Incorrect focus order VoiceOver / TalkBack
Touch target < 44pt/48dp Accessibility Inspector
Contrast Colour Contrast Analyser
Animations at reduce motion Settings → Accessibility

Tools Comparison

Tool Speed Depth Cost
Accessibility Inspector fast basic free
Accessibility Scanner fast basic free
axe DevTools Mobile medium full WCAG commercial

Our Process

  1. Audit — run through Accessibility Inspector and Scanner, get a prioritized list of violations.
  2. Automation — add AccessibilityChecks.enable() to Espresso tests so every action checks a11y.
  3. Manual check — walk through key scenarios with VoiceOver and TalkBack, record semantic issues.
  4. Report — document all violations classified by WCAG 2.1 (A/AA) with fix recommendations.

What’s Included

We deliver a detailed report with found violations and their severity, fix recommendations for each error type, updated automated tests with accessibility checks enabled, a brief guide for the iOS/Android team to prevent regressions, and a WCAG 2.1 AA compliance certificate (upon request). According to WCAG 2.1 Success Criterion 1.4.3, the minimum contrast ratio for normal text is 4.5:1.

Timelines and Pricing

An audit of an average app takes 2–4 days. Full documentation for the EU Accessibility Act may add another 2 days. Pricing is calculated individually based on the number of screens and complexity of scenarios. Contact us — we will assess your project and offer an optimal plan. Request an accessibility consultation today.

Common Mistakes When Implementing Accessibility

  • Low contrast on placeholders and hints — often using gray #999999 on white.
  • Small buttons in navigation bars and toolbars — less than 44pt/48dp.
  • Ignoring gestures — if there is swipe-to-delete, it must be duplicated with a long press.