Swift
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Optionals
-
Section 4: Object-Oriented and Value Types
-
Section 5: Memory Management
-
Section 6: Generics and Error Handling
-
Section 7: Concurrency
-
Section 8: Working with Collections
-
Section 9: Codable and Data Handling
-
Section 10: Protocol-Oriented Programming
-
Section 11: Testing and Tooling
-
Section 12: Practical Projects
-
Section 13: Interview Practice
-
Section 14: More Practice Exercises
-
Section 15: More Standard Library
-
Section 16: Advanced Concurrency
-
Section 17: Foundation Framework Deep Dive
-
Section 18: URLSession and Networking Deep Dive
-
Section 19: Combine Framework
-
Section 20: SwiftUI Fundamentals for Swift Developers
-
Section 21: Server-Side Swift with Vapor
-
Section 22: Swift Package Manager Deep Dive
-
Section 23: Swift Concurrency Deep Dive
-
Section 24: More Language Features
-
Section 25: Error Handling Deep Dive
-
Section 26: Testing Deep Dive
-
Section 27: Data Structures and Algorithms in Swift
-
Section 28: More Practice Exercises
-
Section 29: More Interview Practice
-
Section 30: Swift Macros (Swift 5.9+)
-
Section 31: Property Wrappers Ecosystem
-
Section 32: Swift Interop Deep Dive
-
Section 33: iOS App Architecture Patterns
-
Section 34: Performance and Debugging
-
Section 35: App Distribution and CI/CD
-
Section 36: More Practical Projects
-
Section 37: SwiftData and Persistence
-
Section 38: More Design Patterns
-
Section 39: More Review and Practice
-
Section 40: More Foundation Deep Dive
-
Section 41: Advanced Collections in Swift
-
Section 42: Advanced Generics Practice
-
Section 43: UIKit for Legacy and Hybrid Apps
-
Section 44: watchOS and visionOS Development Basics
-
Section 45: More Networking Patterns
-
Section 46: More Testing Practice
-
Section 47: Accessibility in Swift Apps
-
Section 48: Localization
-
Section 49: More Practical Projects Round 2
-
Section 50: Swift Charts Framework
-
Section 51: More Interview and Algorithm Practice
-
Section 52: Final Practice and Mastery
-
Section 53: Swift Compiler and Build System
-
Section 54: More Concurrency Practice
-
Section 55: App Store Guidelines and Review
-
Section 56: More Design and Architecture
203: VoiceOver Support in SwiftUI
I remember a junior dev I worked with a few years back who had built this beautiful, minimalist shopping cart. He’d used these sleek, icon-only buttons for "Remove Item" and "Save for Later"—no text, just clean SVG icons. He was incredibly proud of the aesthetic. Then, during a beta test, we got a report from a user who relied on VoiceOver. For that user, the cart wasn't a shopping experience; it was just a list of elements that announced "Button, Button, Button." The user had no idea which one deleted their order and which one saved it. It was a wake-up call for all of us that "clean" design can sometimes be "invisible" design.
Giving Sight to the Invisible
By default, SwiftUI does a decent job of guessing what an element is, but it's nowhere near perfect. If you have a Button with a Text label, VoiceOver knows exactly what to do. But the moment you use an Image or a custom View as a trigger, you're essentially flying blind. This is where .accessibilityLabel() comes in.
The label is the most critical piece. It should be a concise description of the element's purpose. I always tell people: don't include the word "button" in the label. VoiceOver already knows it's a button because of the element's trait, so saying "Remove Item Button" results in the screen reader saying "Remove Item Button, button," which is redundant and annoying.
struct ProductRow: View {
var body: some View {
HStack {
Text("Organic Coffee Beans")
Spacer()
Button(action: { /* remove logic */ }) {
Image(systemName: "trash")
}
.accessibilityLabel("Remove Organic Coffee Beans")
}
}
}
Sometimes a label isn't enough. If the action is complex, you can add an .accessibilityHint(). This is a short description that tells the user what will happen after they perform the action. Think of it as the "fine print" for accessibility.
Grouping for Sanity
One of the biggest mistakes I see is leaving too many individual elements for VoiceOver to navigate. Imagine a product card with a title, a price, a rating, and a category. If a user has to swipe four times just to get through one product, they'll get exhausted. It's tedious.
You can solve this by using .accessibilityElement(children: .combine). This tells SwiftUI to treat the entire group as a single focusable element. Instead of four separate stops, VoiceOver will read all the combined text in one go. I find this makes the app feel much more professional and fluid for users who aren't seeing the screen.
VStack(alignment: .leading) {
Text("Premium Headphones")
.font(.headline)
Text("$299.00")
.font(.subheadline)
}
.accessibilityElement(children: .combine)
.accessibilityLabel("Premium Headphones, price 299 dollars")
Handling Dynamic Values and Traits
Not everything is a simple label. If you're building something like a custom volume slider or a toggle that doesn't use the standard Toggle view, you need to use .accessibilityValue(). This separates the identity of the control (the label) from its current state (the value).
Furthermore, if you've built a custom view from scratch (like a ZStack that behaves like a button), VoiceOver won't know it's interactive. You have to explicitly tell the system by adding traits. Using .accessibilityAddTraits(.isButton) ensures the user knows they can actually interact with that area of the screen. It's a small addition, but it's the difference between a user ignoring a feature and actually using it.
📋 Practical Task
Exercise: Making a Product Detail Card Accessible
You have been handed a "Product Card" view that is visually appealing but completely inaccessible to VoiceOver users. The card contains an image of a product, a price tag, a "Favorite" heart icon, and a "Buy Now" button.
Your Task: Modify the following code to implement the following accessibility improvements:
- Combine the Product Name and Price into a single accessibility element so the user doesn't have to swipe twice to hear the basic product info.
- Add a clear, non-redundant
accessibilityLabelto the "Favorite" button (currently just an image). - Add an
accessibilityHintto the "Buy Now" button explaining that it will add the item to the checkout screen. - Ensure the "Favorite" button is explicitly marked as a button using traits.
struct ProductCard: View {
var body: some View {
VStack {
Image("laptop_photo")
.resizable()
.frame(width: 100, height: 100)
VStack {
Text("MacBook Pro")
Text("$2,499")
}
HStack {
Button(action: { /* toggle favorite */ }) {
Image(systemName: "heart")
}
Button(action: { /* go to checkout */ }) {
Text("Buy Now")
}
}
}
.padding()
.background(Color.gray.opacity(0.1))
.cornerRadius(10)
}
}There are no comments for now.