A mobile app may pass a visual review while a screen-reader user cannot reach its submit button or understand a changed status. Accessibility acceptance should be a set of complete user journeys, not a claim based solely on the component library. Include it in the agency scope before screens are finalized.
Related service: Mobile application development- 01Choose representative tasks
- 02Use accessibility settings
- 03Check errors and updates
- 04Record and retest issues
SECTION 01
Agree the supported test matrix
Identify the platforms, device sizes and accessibility modes included in acceptance. For an Android and iOS app, testing one platform is not evidence for the other. Ask the agency to show how visible text, control names and reading order connect, especially in custom components and complex lists.
Android's accessibility testing guidance recommends manual, tool-assisted, automated and user testing approaches. W3C's text-resizing guidance offers useful principles for avoiding lost content or functionality, while native platform requirements need their own implementation review. Do not turn a web criterion into an unsupported blanket native-app compliance claim.
SECTION 02
Illustrative example: changing an appointment
A screen-reader user opens an appointment, selects a new time and submits the change. The app announces the selected value, exposes the confirmation action and communicates a server conflict if the slot is no longer available. It preserves the user's context instead of returning them to the top of a long list.
With enlarged text, the appointment details wrap without pushing the action beneath an unreachable overlay. Error text identifies the field and offers a recovery step. This hypothetical journey tests whether the person can complete the change, not just whether every screen contains a technically accessible label.
SECTION 03
Include transient and exceptional states
Review empty lists, loading, authentication expiry, permission denial, dialogs and offline status. Important feedback should not depend only on color, sound or a disappearing toast. Check touch targets and alternative navigation where relevant. Avoid repeated announcements that interrupt the user's reading whenever background content refreshes.
Request a task-based test record, device and assistive-tool versions, issue ownership and regression cases. A standard control may reduce implementation work, but customization can change its behavior. Prioritize core tasks in an initial release while being explicit about unresolved issues; accessibility should remain part of future feature acceptance rather than a one-time badge.
SECTION 04
Frequently asked questions
Is an automated accessibility scan sufficient?
No. It can detect some issues, but complete workflows and dynamic behavior need manual testing with the supported assistive tools.
Should we test the largest text settings?
Test the supported settings deliberately and document the result. Important content and actions should remain readable and reachable as text grows.
Does using native controls guarantee accessibility?
No. Native controls can help, but labels, grouping, focus, errors and the surrounding workflow still need review.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Test application accessibilityAndroid Developers
- Understanding text resizingW3C WAI
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy