Tag: iOS
165 posts
Custom actions work with VoiceOver, Switch Control and Full Keyboard Access. They also do for Voice Control. You can say "Show actions for <item name/number>", and an action sheet with all options, numbered, will be presented to the user. For some use-cases, Voice Control users might not feel it is a big win. Navigation is not as big of an issue, and interacting with custom actions might be a bit trickier than with "exposed" buttons. But lots of times seems a fair compromise.
Custom actions work well with VoiceOver and Switch Control. It is also a way of speeding up navigation, and grouping all actions available for an item in a single place, with Full Keyboard Access. Focus an item and use the shortcut Tab (⇥) + Z.
Since iOS 14, UIAccessibilityCustomAction has an initialiser that accepts an image, as well as a name and action handler. Configuring one will make your custom actions easier to spot in the Switch Control menu. https://developer.apple.com/documentation/uikit/uiaccessibilitycustomaction/init(name:image:actionhandler:)
Custom actions work as great on Switch Control as they do in VoiceOver. It makes navigation much, much, faster and you’ll be able to find all those custom actions in the Switch Control menu.
Custom actions are also great for actions that are executed with a gesture that is overridden by VoiceOver. Think of the unread, flag and archive hidden options that you can make visible by swiping left/right on a message row in the Mail app.
Optimising for navigation by making a view accessible shouldn’t come at the expense of the buttons in it not being accessible. Configuring custom actions will allow the user to access them using the Actions rotor. With the Actions rotor, users can swipe up and down to cycle through all the options, stop at the desired one, and double tap to execute that action. You can configure an array of custom actions. Custom actions can have a name that will be announced by VoiceOver and an action handler or target selector with the code that will be executed. https://developer.apple.com/documentation/objectivec/nsobject-swift.class/accessibilitycustomactions
Sometimes you want to prioritise ease of navigation, and that's when configuring isAccessibilityElement to true on a container view makes sense. This is especially true in table/collection views and with complex cells with lots of elements. Take the example from a tweet (from Day 62's tweet). If the tweet has 9 accessible elements, you'd need 9 swipes to the right to go to the next tweet in the list. But ideally, I single swipe should be enough. https://x.com/dadederk/status/1549417799746994177 On the other hand, for the detail screen for a single tweet, you want to optimise for ease of access to each one of the elements, instead of navigation. In that case it would be better for the tweet view not to be an accessibility element.
When setting isAccessibilityElement to true, assistive tech like VoiceOver will stop looking for other accessible elements in that view hierarchy. So if we make a view accessible, its subviews, including buttons and labels won't be accessible.
VoiceOver has a very cool gesture called the Magic Tap (double tap with two fingers). It should execute the most important task for the current state of the app. Examples: start/stop timer, play/pause music, take a photo, compose a tweet... You just need to override accessibilityPerformMagicTap() to capture that gesture, execute the desired code, and return true if handled successfully. https://developer.apple.com/documentation/objectivec/nsobject-swift.class/accessibilityperformmagictap()
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
Showing 109-120 of 165 posts
