A mobile permission flow should remain understandable and usable before, during, and after the operating system notice. Review the feature that needs access, the explanation, the system dialog, the denied state, and the route for changing a decision later. Test each state with accessibility features rather than judging screenshots alone.
Begin with the feature
Open the feature that needs camera, microphone, location, contacts, photos, or another protected resource. The request should appear in context after the user chooses that feature. The explanation should name the data and the reason it is needed. Avoid asking for unrelated access at first launch.
Android's runtime permission guidance tells developers to ask in context, permit cancellation of an educational screen, continue gracefully after denial, and verify access status whenever protected functionality is used. Apple's privacy design guidance likewise recommends requesting access only when clearly needed and writing a brief, specific purpose description.
Test with assistive technology
Use the platform screen reader and move through the feature from the beginning. Confirm that the request control has an accurate name, the reason for access is announced, focus reaches the system dialog, and the result is communicated after the dialog closes. Repeat with larger text and alternative input.
Google's Android accessibility testing guide includes manual testing with TalkBack and Switch Access and checking whether alerts or temporary messages are read aloud. Apple's accessibility testing guidance calls for testing tasks with VoiceOver and Voice Control and checking that layouts reflow without truncation or overlap at larger Dynamic Type sizes.
Review denial and recovery
Deny access once. The app should explain which feature is unavailable without blocking unrelated work. Confirm that the explanation is specific, not color-only, and does not repeatedly pressure the user. Follow the route to system settings, change the permission, return to the app, and verify that the feature updates without a hidden gesture or reinstall.
Android advises minimizing functionality loss, identifying the affected feature, avoiding a blocking full-screen warning, and respecting the user's choice. Apple notes that people can review and update permission decisions in Privacy settings.
Apply a recognized review frame
W3C's WCAG2ICT guidance explains how WCAG 2 Level A and AA criteria can be applied to non-web software, including mobile apps. It is informative guidance rather than a standalone conformance standard. Use it to organize checks for names, roles, focus, contrast, reflow, errors, and status messages while also following native platform requirements.
Keep repeatable evidence: app and operating-system versions, device, permission state, accessibility settings, feature, expected result, and observed result. Include first request, denial, limited or one-time access where available, revocation in settings, and access after an app update. The review is complete only when the feature and its no-access alternative both work for the intended users.
Sources
- Request runtime permissions — Android Developers
- Human Interface Guidelines: Privacy — Apple
- Test your app's accessibility — Android Developers
- Performing accessibility testing for your app — Apple Developer
- Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies — World Wide Web Consortium, Oct. 8, 2024