Tips and tricks to build accessible iOS apps

#365DaysIOSAccessibility

RSS Feed

#365DaysIOSAccessibility

RSS Feed

A year-long journey exploring iOS accessibility, one day at a time. Each post shares practical insights, tips, and techniques to make your iOS apps more accessible.

Accessibility labels should not contain the type of the control, that's a job for the accessibility trait instead. If you have a button with a label like "Close button" and the ".button" trait, VoiceOver will say: "Close button, button".

Good accessibility labels are at the core of good accessible apps. It should be a localized succinct string that tells as much as possible about the component (without including its type) and provides context avoiding verbosity and redundancy.

SwiftUI has equivalent accessibility modifiers for some of UIAccessibility's properties in UIKit. Same basic concepts apply. Label: https://developer.apple.com/documentation/swiftui/view/accessibilitylabel(_:)-9ek2h Value: https://developer.apple.com/documentation/swiftui/view/accessibilityvalue(_:)-8esl7 Traits: https://developer.apple.com/documentation/swiftui/view/accessibilityaddtraits(_:) Hint: https://developer.apple.com/documentation/swiftui/view/accessibilityhint(_:)-3i2vu

UIAccessibility is the cornerstone of any accessible UIKit app. Among others, understanding what an accessibility label, value, trait or hint are, is key. This is an example of how they could be configured for a custom rating component. #GAAD2022

Tomorrow is @gbla11yday! And I'm going to start a challenge, tweeting everyday, for a whole year, about tips, resources, and other useful info on how to develop accessible iOS apps. Are you up for the challenge? #GAAD

Showing 226-230 of 230 posts

← Previous

Page 16 of 16

Next →

Special thanks to

Quintin Balsdon

for helping extract the content from the original Twitter posts.

Created in Swift with Ignite.

Supporting Swift for Swifts