In our practice, VoiceOver on iPhone reads the button as “Button” instead of “Add to cart” — because the UIImageView with the cart icon has no accessibilityLabel set. A user with visual impairments taps blindly.
This is not a theoretical situation: 2.2 billion people have visual impairments, and Apple/Google have started rejecting apps with severe Accessibility violations during review.
We are a team of engineers with 6 years of experience in mobile development; we have completed more than 40 accessibility audits. We conduct accessibility audits and guarantee compliance with WCAG 2.1 AA standards.
Why is accessibilityLabel so often missing?
Custom components — sliders, custom buttons, icons without text — do not have automatic labels. VoiceOver reads coordinates or the class name. On iOS, you need to 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 a modal closes, VoiceOver/TalkBack focus remains on elements that are no longer on screen — the user gets lost. On iOS we manage via UIAccessibility.post(notification: .screenChanged, argument: targetView).
On Android — ViewCompat.setAccessibilityPaneTitle and sendAccessibilityEvent(AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED). Manual testing of this scenario is mandatory: automated tools do not always catch focus loss.
Testing tools
Accessibility Inspector (Xcode). Launched via Xcode → Open Developer Tool → Accessibility Inspector. One-click audit — finds missing labels, small touch targets, contrast issues. Works on the simulator and on a real device.
Accessibility Scanner (Android). A Google app that scans the screen and returns a list of issues classified by type. Integrates into Espresso via AccessibilityChecks.enable() — automatically runs checks on every action in the test:
@Before fun setup() { AccessibilityChecks.enable() .setRunChecksFromRootView(true) } Every Espresso test now additionally checks a11y — any violation fails the test. Accessibility Scanner processes a screen in 2–3 seconds, which is 5 times faster than manual checking.
Manual testing with VoiceOver/TalkBack. We go through key scenarios: registration, purchase, the main user flow — using screen reader gestures only, without visual control.
This reveals semantic issues that automated tools cannot understand: logical reading order of elements, unclear label wording, lost focus.
axe DevTools Mobile. A commercial tool with more detailed classification of WCAG violations. Provides a report with severity and references to criteria. Useful when preparing for EU Accessibility Act compliance.
When is manual testing required?
Automated tools do not check reading logic or perceived usability. If the app contains complex animations, dynamic lists, or non-standard gestures, manual testing with VoiceOver/TalkBack is essential. We recommend manual testing after every significant release.
Testing 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 with reduce motion | — | Settings → Accessibility |
Comparison of audit tools
| Tool | Speed | Depth of analysis | Pricing |
|---|---|---|---|
| Accessibility Inspector | fast | basic | free |
| Accessibility Scanner | fast | basic | free |
| axe DevTools Mobile | medium | full WCAG | commercial |
Work process
- Audit — run through Accessibility Inspector and Scanner, get a prioritized list of violations.
- Automation — add
AccessibilityChecks.enable()to Espresso tests so every action checks a11y. - Manual check — go through key scenarios with VoiceOver and TalkBack, record semantic issues.
- Report — document all violations with WCAG 2.1 (A/AA) classification and remediation recommendations.
What is included
We provide a detailed report with found violations and their severity, remediation recommendations for each type of error, updated automated tests with accessibility checks enabled, a brief guide for the team (iOS/Android) on preventing 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.
Timeline and cost
An audit of an average app takes 2 to 4 days. Full documentation for the EU Accessibility Act may add another 2 days. The cost is calculated individually based on the number of screens and complexity of scenarios.
Contact us — we will evaluate your project and propose an optimal plan. Book an accessibility consultation today.
Common mistakes when implementing accessibility
- Lack of contrast for placeholders and hints — gray #999999 on white is often used.
- Small buttons in navigation bars and toolbars — smaller than 44pt/48dp.
- Ignoring gestures — if there is swipe-to-delete, it must be duplicated via long press.