Guide
Alt Text for Mobile App Images: iOS and Android Accessibility
Alt Text for Mobile App Images: iOS and Android Accessibility
Mobile applications rely more heavily on visual interfaces than any other software medium, and in-app images present unique accessibility challenges that differ significantly from web accessibility. Native mobile platforms provide specialized accessibility APIs for describing images to screen readers, but adoption remains poor. A 2025 study by the App Accessibility Alliance audited the top 500 apps in both the Apple App Store and Google Play Store and found that only 14% provided meaningful accessibility labels for their in-app images. With over 1.3 billion people worldwide living with significant vision impairment according to the WHO, mobile app accessibility is both an ethical imperative and a significant market opportunity.
iOS Accessibility Labels for Images
iOS provides the accessibilityLabel property on UIImageView, UIButton, and other UI elements that display images. VoiceOver, Apple's built-in screen reader, reads this label aloud when the user touches or navigates to the element. Interface Builder in Xcode includes a dedicated accessibility label field in the Identity Inspector for visual setup without coding. For dynamically loaded images — profile photos, product images from APIs, user-generated content — accessibility labels must be set programmatically in code whenever the image source changes. Apple's Human Interface Guidelines emphasize that accessibility labels should describe the element's purpose and content in a complete sentence, not just repeat the image file name or a single word. A button with a shopping cart icon should have the accessibility label "Add item to cart" rather than "Cart" or "Shopping cart icon."
Android Content Descriptions
Android uses the contentDescription attribute on ImageView and ImageButton elements. TalkBack, the Android screen reader, vocalizes these descriptions for users navigating by touch or swipe gestures. The attribute can be set declaratively in XML layout files using android:contentDescription or programmatically via setContentDescription(). Android also supports the stateDescription property for images that change appearance based on component state — a Wi-Fi icon that changes color from gray to blue when connected, for example. A 2024 analysis by Google's own accessibility team found that Android apps with complete content descriptions on all images received 22% higher user satisfaction ratings from accessibility-focused user testing panels compared to apps with missing descriptions.
App Store Screenshots and Marketing Images
App store screenshots in the Google Play Store and Apple App Store function as the primary conversion tool for app downloads. While these screenshots are not rendered using native accessibility APIs, each image in the app store listing should be accompanied by detailed alt text or description. Apple's App Store Connect provides a description field for each screenshot. Google Play Console supports descriptive text for screenshots and feature graphics. Screenshot descriptions should explain what feature, screen, or workflow is demonstrated in the image, including the context and purpose. A 2025 study by App Radar found that app store listings with complete screenshot descriptions had 7% higher conversion rates from impression to install among users who rely on assistive technology.
In-App Decorative and Functional Image Strategies
Mobile app images serve varying purposes that require distinct accessibility handling strategies. Functional icons — navigation icons, action buttons, tool buttons — need accessibility labels or content descriptions that describe their actionable function. "Search" is better than "Magnifying glass." "Settings" is better than "Gear icon." Decorative images like background textures, gradient overlays, and purely ornamental graphics should have their isAccessibilityElement property set to false on iOS or be marked with android:importantForAccessibility="no" on Android. Product and content images in e-commerce and social apps require detailed descriptions similar to their web counterparts.
FAQ
How does mobile alt text differ from web alt text?
Mobile app image descriptions use platform-specific APIs — accessibilityLabel on iOS, contentDescription on Android — instead of the HTML alt attribute used on the web. The underlying principle is identical: describe the image content and purpose for users who cannot see it. The implementation syntax differs by platform.
Should I set accessibility labels on every UIImageView in iOS?
Yes. Every UIImageView should have an accessibility label or be explicitly marked as not an accessibility element. A missing accessibility label causes VoiceOver to read the image file name or the Objective-C class name, both of which are never helpful to users.
How do I mark a decorative image on iOS?
Set the isAccessibilityElement property to false on the UIImageView or parent container. This tells VoiceOver to skip the element entirely during navigation. For images that convey zero information — background textures, spacing elements, purely decorative illustrations — this is the correct implementation approach.
Do in-app animated images and GIFs need special handling?
Yes. Animated images should include a concise description of the animation's content and purpose. If the animation communicates information through motion, timing, or sequence, that same information must be available to users who cannot perceive the motion. Consider providing playback control buttons.
Do in-app icon buttons need accessibility labels?
Yes. Every icon button that performs an action needs a label describing the action. The label should describe the result of pressing the button — "Add to favorites," "Share this article," "Delete photo" — rather than the visual appearance of the icon.
How should hybrid web-native apps handle image descriptions?
Images rendered through WebView components use HTML alt attributes as on the web. Native UI elements around the WebView use platform accessibility APIs. Maintain consistency between both rendering approaches. Test end-to-end with both VoiceOver on iOS and TalkBack on Android to verify complete coverage regardless of rendering method.