Tag: iOS
169 posts
Please, don't use accessibility labels as ids for your UI tests. It can completely ruin the experience for VoiceOver users. There is actually an accessibility identifier property that you can use instead to uniquely identify your UI elements.
Apple recommends in their guidelines a minimum tappable area size of 44x44 points for all controls. A lot of times this can be corrected in an app without changing how it looks, but making it objectively easier to interact with for everyone.
It is possible to embed icons within text using NSTextAttachment and NSAttributedString. If you do, please remember to override the accessibility label, otherwise VoiceOver will announce it as "Attachment.png File".
Example code in the image:
```swift
let magnifyingGlassIcon = UIImage(systemName: "magnifyingglass")!
let searchButton = UIButton()
let searchTutorialLabel = UILabel()
searchButton.accessibilityLabel = "search"
let textAttachment = NSTextAttachment(image: magnifyingGlassIcon)
let string = "Select the
When thinking about accessibility labels and values, it is easy to miss adding information or state that are represented by little visual cues and icons: a checkmark indicating something has been played, a down arrow indicating a downward trend...
Convey important information in multiple modes (sounds, haptics, colour, iconography, messaging...) so no-one misses it. Take Spotify's shuffle button. It is green when on, white when off, but it has also a dot indicator. https://wearecolorblind.com/examples/spotify-shuffle-and-repeat-buttons/
accessibilityActivate() lets you capture a VoiceOver double tap. This is useful if you are creating a custom component you interact with using complex gestures or VoiceOver navigation gestures. An example: slide to unlock. https://developer.apple.com/documentation/objectivec/nsobject-swift.class/accessibilityactivate()
A similar experience can sometimes be achieved in different ways using labels, traits, and values. Most times there are no right or wrong answers; it will be up to your users to say which approach they like the most. Two great pieces of advice though: > **@Sommer:** "Check and see how Apple's own apps handle similar scenarios. Not because our apps are perfect but rather to help build on consistent patterns." > > Tweet by @Sommer > **@dotjay:** "Meet the platform expectations, and give users control rather than prescribing what you think users want." > > Tweet by @dotjay
In Objective-C accessibility traits are a bitmask. Some devs find tricky to work with them using bitwise operations. In Swift they conform to the OptionSet protocol that conforms to SetAlgebra. That means you can simply insert/remove traits.
Accessibility values are about state. Using them appropriately will make the experience better for Voice Control users. Think of a repeat button (values could be: off, one or all songs) or a notifications tab (value could be: x new items). For more on accessibility values, check out this fantastic blog post from @MobileA11y with info on the APIs (UIKit, SwiftUI), accessibility attributed values, WCAG, or some more examples (text in a text field, value on a stepper or slider). https://mobilea11y.com/blog/accessibility-values/
The .summaryElement accessibility trait causes VoiceOver to announce that element when the app starts. The element won't get the focus though, and the order is not affected. A candidate for this trait could be the rings info in the Activity app.
There is another accessibility trait: .playsSound, that does a similar thing than .startsMediaSession. This one seems more suitable for buttons that have their own sound effects when interacting with them, like it often happens in games.
When interacting with a button with VoiceOver, the accessibility label is repeated to the user. If you are playing some audio, it could be difficult to listen to it properly. To avoid that, you can add the .startsMediaSession accessibility trait.
Showing 121-132 of 169 posts
