Accessibility in iOS apps is a powerful way to highlight the importance of inclusive design while showcasing the robust accessibility tools Apple provides, such as VoiceOver, Dynamic Type, and Switch Control. It not only helps fellow developers understand how to create apps that are usable by everyone, including people with disabilities, but also demonstrates professionalism, empathy, and technical depth. By promoting best practices and raising awareness.
For this post, we will focus only on visual accessibility aspects. Interaction and media-related topics will be covered in a future post. As we go through this post, I will also provide the project along with the source code used to explain the concepts.
Accessibility Nutrition Labels
Accessibility Nutrition Labels in iOS are a developer-driven concept inspired by food nutrition labels, designed to provide a clear, standardized summary of an app’s accessibility features. They help users quickly understand which accessibility tools—such as VoiceOver, Dynamic Type, or Switch Control—are supported, partially supported, or missing, making it easier for individuals with disabilities to choose apps that meet their needs. Though not a native iOS feature, these labels are often included in app. Eventhought accessibility is supported in almost all Apple platforms, some accessibility labels aren’t available check here.
They can be set at the moment that you upload a new app version on Apple Store.
Sufficient contrast
Users can increase or adjust the contrast between text or icons and the background to improve readability. Adequate contrast benefits users with reduced vision due to a disability or temporary condition (e.g., glare from bright sunlight). You can indicate that your app supports “Sufficient Contrast” if its user interface for performing common tasks—including text, buttons, and other controls—meets general contrast guidelines (typically, most text elements should have a contrast ratio of at least 4.5:1). If your app does not meet this minimum contrast ratio by default, it should offer users the ability to customize it according to their needs, either by enabling a high-contrast mode or by applying your own high-contrast color palettes. If your app supports dark mode, be sure to check that the minimum contrast ratio is met in both light and dark modes.
We have prepared following following screen, that clearly does not follow this nutrition label:
Deploy in the simulator and present the screen to audit and open Accesibility Inspector:
Deploy in the simulator and present the screen to audit and open Accesibility Inspector, select simulator and Run Audit:
Important point, only are audited visible view layers:
Buid and run on a simulator for cheking that all is working fine:
Dark mode
Dark Mode in SwiftUI is a user interface style that uses a darker color palette to reduce eye strain and improve visibility in low-light environments. SwiftUI automatically supports Dark Mode by adapting system colors like .primary, .background, and .label based on the user’s system settings. You can customize your UI to respond to Dark Mode using the @Environment(\.colorScheme) property.
We’ve designed our app to support Dark Mode, but to ensure full compatibility, we’ll walk through some common tasks. We’ll also test the app with Smart Invert enabled—an accessibility feature that reverses interface colors.
Once smart invert is activated all colors are set in their oposite color. This is something that we to have to avoid in some components of our app such as images.
AsyncImage(url: URL(string: "https://www.barcelo.com/guia-turismo/wp-content/uploads/2022/10/yakarta-monte-bromo-pal.jpg")) { image in
image
.resizable()
.scaledToFit()
.frame(width: 300, height: 200)
.cornerRadius(12)
.shadow(radius: 10)
} placeholder: {
ProgressView()
.frame(width: 300, height: 200)
}
.accessibilityIgnoresInvertColors(isDarkMode) In case of images or videos we have to avoid color inversion, we can make this happen by adding accessibilityIgnoreInvertColors modifier.
It’s important to verify that media elements, like images and videos, aren’t unintentionally inverted. Once we’ve confirmed that our app maintains a predominantly dark background, we can confidently include Dark Interface in our Accessibility Nutrition Labels.
Larger Text
In Swift, «Larger Text» under Accessibility refers to iOS’s Dynamic Type system, which allows users to increase text size across apps for better readability. When building a nutrition label UI, developers should support these settings by using Dynamic Type-compatible fonts (like .body, .title, etc.), enabling automatic font scaling (adjustsFontForContentSizeCategory in UIKit or .dynamicTypeSize(...) in SwiftUI), and ensuring layouts adapt properly to larger sizes. This ensures the nutrition label remains readable and accessible to users with visual impairments, complying with best practices for inclusive app design.
You can increase dynamic type in simulator in two ways, first one is by using accesibilty inspector, second one is by opening device Settings, Accessibilty, Display & Text Size, Larger text:
When se set the text to largest size we observe following:
Only navigation title is being resized the rest of the content keeps the same size, this is not so much accessible!.
When we execute accesibilty inspectoron this screen also complains.
By replacing fixed font size by the type of font (.largeTitle, .title, .title2, .title3, .headline, .subheadline, .body, .callout, .footnote and .caption ). Remve also any frame fixed size that could cut any contained text.
func contentAccessible() -> some View {
VStack(alignment: .leading, spacing: 8) {
Text("Nutrition Facts")
.font(.title)
.bold()
.accessibilityAddTraits(.isHeader)
Divider()
HStack {
Text("Calories")
.font(.body)
Spacer()
Text("200")
.font(.body)
}
HStack {
Text("Total Fat")
.font(.body)
Spacer()
Text("8g")
.font(.body)
}
HStack {
Text("Sodium")
.font(.body)
Spacer()
Text("150mg")
.font(.body)
}
}
.padding()
.navigationTitle("Larger Text")
} 
We can observe how the view behaves when Dynamic Type is adjusted from the minimum to the maximum size. Notice that when the text «Nutrition Facts» no longer fits horizontally, it wraps onto two lines. The device is limited in horizontal space, but never vertically, as vertical overflow is handled by implementing a scroll view.
Differentiate without color alone
Let’s discuss color in design. It’s important to remember that not everyone perceives color the same way. Many apps rely on color—like red for errors or green for success—to convey status or meaning. However, users with color blindness might not be able to distinguish these cues. To ensure accessibility, always pair color with additional elements such as icons or text to communicate important information clearly to all users.
Accessibility inspector, and also any color blinded person, will complain. For fixing use any shape or icon, apart from the color.l
Reduced motion
Motion can enhance the user experience of an app. However, certain types of motion—such as zooming, rotating, or peripheral movement—can cause dizziness or nausea for people with vestibular sensitivity. If your app includes these kinds of motion effects, make them optional or provide alternative animations.
Lets review the code:
struct ReducedMotionView: View {
@Environment(\.accessibilityReduceMotion) var reduceMotion
@State private var spin = false
@State private var scale: CGFloat = 1.0
@State private var moveOffset: CGFloat = -200
var body: some View {
NavigationView {
ZStack {
// Background rotating spiral
Circle()
.strokeBorder(Color.purple, lineWidth: 10)
.frame(width: 300, height: 300)
.rotationEffect(.degrees(spin ? 360 : 0))
.animation(reduceMotion ? nil : .linear(duration: 3).repeatForever(autoreverses: false), value: spin)
// Scaling and bouncing circle
Circle()
.fill(Color.orange)
.frame(width: 100, height: 100)
.scaleEffect(scale)
.offset(x: reduceMotion ? 0 : moveOffset)
.animation(reduceMotion ? nil : .easeInOut(duration: 1).repeatForever(autoreverses: true), value: scale)
}
.onAppear {
if !reduceMotion {
spin = true
scale = 1.5
moveOffset = 200
}
}
.padding()
.overlay(
Text(reduceMotion ? "Reduce Motion Enabled" : "Extreme Motion Enabled")
.font(.headline)
.padding()
.background(Color.black.opacity(0.7))
.foregroundColor(.white)
.cornerRadius(12)
.padding(),
alignment: .top
)
}
.navigationTitle("Reduced motion")
}
} The ReducedMotionView SwiftUI view creates a visual demonstration of motion effects that adapts based on the user’s accessibility setting for reduced motion. It displays a rotating purple spiral in the background and an orange circle in the foreground that scales and moves horizontally. When the user has Reduce Motion disabled, the spiral continuously rotates and the orange circle animates back and forth while scaling; when Reduce Motion is enabled, all animations are disabled and the shapes remain static. A label at the top dynamically indicates whether motion effects are enabled or reduced, providing a clear visual contrast for accessibility testing.
Reduce Motion accessibility is not about removing animations from your app, but disable them when user has disabled Reduce Motion device setting.
Pending
Yes, this post is not complete yet. There are two families of Nutrition accessibility labels: Interaction and Media. I will cover them in a future post.
Conclusions
Apart from the benefits that accessibility provides to a significant group of people, let’s not forget that disabilities are diverse, and as we grow older, sooner or later we will likely need to use accessibility features ourselves. Even people without disabilities may, at some point, need to focus on information under challenging conditions—like poor weather—which can make interaction more difficult. It’s clear that this will affect us as iOS developers in how we design and implement user interfaces in our apps.
You can find source code that we have used for conducting this post in following GitHub repository.
References
- Evaluate your app for Accessibility Nutrition Labels
WWDC 25 Video
- Accessibility
Apple Developer Documentation
