Navigating Accessibility: A SwiftUI vs. UIKit Comparison
A Comparative Exploration of Accessibility Complexity between SwiftUI and UIKit.
With the emergence of SwiftUI, Apple’s declarative UI framework, developers now have a novel approach to crafting interfaces. This article delves into an exploration and comparison of the accessibility features between SwiftUI and its well-established counterpart, UIKit.
Understanding Accessibility 📘
In the realm of iOS development, creating apps that prioritise both visual appeal and accessibility is important. For many, accessibility is a necessity. For others, it’s a practicality.
Accessibility in app development entails designing and constructing an experience that caters to users with diverse abilities and disabilities. These disabilities encompass visual impairments, motor limitations, cognitive challenges, and more.
By embracing accessibility principles, developers enhance usability for all users which allows a wider audience to have an uncompromising experience. You can learn more about accessibility, including VoiceOver, Dynamic Sizing and Layouts from Apple over here.
Dynamic Type 📱
Dynamic Type is Apple’s system-wide feature that allows users to adjust the font size across the whole system. Users can choose from various text size options, from small to extra-large, based on their visual needs.
As users adjust the size of the font, it is important that app layouts respond and accommodate scaling in a way that does not diminish the experience or usability of the application.
For example, with a banking app — you would want to ensure the entire balance fits within the screen, no matter the size of the font.
Text Layout 🔤
SwiftUI adopts a declarative paradigm for UI development, where the coder articulates how the UI should appear and behave, rather than specifying procedural steps.
Text layout in SwiftUI offers:
1. Automatic Line Wrapping: Text automatically wraps onto multiple lines in response to the available space, dynamically adjusting without explicit line settings.
2. Flexible and Responsive: SwiftUI adjusts text layout as the view’s dimensions change, filling the available space given to the child. This forces you to consider defined boundaries of your layout.
Text("This is a long piece of text that will automatically wrap to multiple lines in SwiftUI.")
.font(.body)
.padding()In contrast, UIKit operates under an imperative paradigm, requiring explicit instructions for layout and how each view should behave on the screen:
1. Fixed Number of Lines: Text is displayed on a single line by default, truncating with an ellipsis if exceeding the line width unless specified otherwise using properties like numberOfLines for UILabel.
2. Manual Handling: UIKit necessitates more intricate code to manage constraints accurately and prioritise elements, contributing to increased complexity.
let label = UILabel()
label.text = "This is a long piece of text that won't wrap automatically in UIKit."
label.numberOfLines = 0 // Set to 0 for unlimited lines
view.addSubview(label)
label.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
label.topAnchor.constraint(equalTo: view.topAnchor, constant: 16),
label.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 16),
label.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: 16),
label.bottomAnchor.constraint(equalTo: view.bottomAnchor, constant: 16)
])SwiftUI shines when considering the implications of dynamic type. Accommodating changes in layout such as font size is inherently simplified due to automatic line wrapping and flexible responsiveness. As users adjust the font size, SwiftUI child views seamlessly fill the available space.
In contrast, the imperative nature of UIKit necessitates more intricate code for managing layout constraints, making it less intuitive and more error-prone when accommodating changes in font size for accessibility purposes.
Moreover, SwiftUI provides convenient tools like ViewThatFits (introduced in iOS 16), which further streamlines the creation of dynamic layouts. This adaptive layout container evaluates child views based on their ideal size, and selects the first child that fits within the available space. By eliminating the need to manually manage constraints, SwiftUI reduces complexity and potential errors in handling dynamic type scenarios compared to UIKit.
var body: some View {
ViewThatFits(in: .horizontal) {
HStack {
Image(systemName: "person.fill")
Text("Hello World")
.font(.system(size: 65))
}
VStack {
Image(systemName: "person.fill")
Text("Hello World")
.font(.system(size: 65))
.multilineTextAlignment(.center)
}
}
.padding(16)
}
VoiceOver 🗣️
Apple has made significant strides in enhancing the accessibility experience with VoiceOver, particularly within SwiftUI:
In SwiftUI, you can now automatically combine accessibility elements within a child view. This leverages the dynamic generation of the accessibilityLabel based on the contents of the view.
Example: A custom container view can provide a unified accessibility label for its child elements.
VStack {
Text("Hello")
Text("World")
}
.accessibilityElement(children: .combine)UIKit lacks a direct equivalent to this, requiring you to manually construct an accessibilityLabel.
accessibilityLabel = ["Hello", "World"].joined(separator: " ")This also has the pitfall of having to ensure whenever the subview content changes (for example more labels are added), that you also remember to update the accessibilityLabel.
Development Experience 🧑💻
Accessibility Inspector
Xcode comes bundled with an Accessibility Inspector application that allows developers to manually inspect and playback VoiceOver when targeting the simulator.
However, using this tool can be slower due to the requirement of rebuilding each time and seeing if those changes are then reflected accurately when analysing the simulator again.
Previews 👀
Integrated into Xcode, Previews provide developers with a real-time preview of their SwiftUI code within the Xcode interface. This feature streamlines the iterative development process by offering an instant glimpse of how the interface will appear without requiring rebuilds.
This tool is invaluable for developers, allowing them to refineSwiftUI layouts and components iteratively.
Within SwiftUI, the Accessibility Inspector is seamlessly integrated into Xcode Preview, providing a built-in tool for developers. It facilitates:
- Element Selection: Developers can click on any view in the preview to access and adjust its accessibility properties, including labels, hints, and traits.
- Speed of integration: Developers can quickly drill down into specific elements directly, inline of where the changes required would be in order to quickly sanity check and modify before moving onwards. This is particularly useful when checking what default properties have been dervived on the element already.
It is worth noting, it is still good practice to actually use VoiceOver on a physical device to hear how elements are spoken and to see if navigation feels natural — however Previews offer a quick feedback that allows for faster iterations during the development cycle, especially when it comes to accessibility.
Conclusion 🚀
In the world of iOS development, SwiftUI’s integrated tools, like the Accessibility Inspector andSwiftUI previews, offer practical solutions for creating both visually appealing and accessible apps. These tools simplify the development process, allowing developers to refine designs efficiently. As we navigate this landscape, SwiftUI emerges as a user-friendly platform that priorities lessons learned from UIKit in simplifying accessibility considerations from the ground up.
