Day 68

25 Jul 2022

Switch Control UIAccessibility UIAccessibilityCustomAction iOS

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:)

Two switch control menus for a tweet. One shows how it would look without passing an image for an action. iOS by default creates an icon with the first letter of the action, in capitals. If there are more than one action that start with the same letter, the next one will be shown with the second letter, in non-capitals. For example, Reply is represented with R, but Retweet is represented with e. The second menu shows each one of the options with an icon, so they're easier to spot in a menu with lots of options. The code used is the same UIAccessibilityCustomAction initialiser, but one of them passes an image, as well as a name and an action handler block.

Some of you have asked me how you can support what I do. This would really help, and would be hugely appreciated:

Find these posts useful? Share them at work, on social media, or with anyone that might find them interesting. Let's spread the word!
Check out any of my apps or games: Xarra!, RetroRapid!, or Mestre!.
- A download and a review go a long way. They're free by default. On the App Store, ratings and reviews really help more people discover them.
- Finding any of them useful? If so, and if you can afford it, purchasing lifetime access to all features or subscribing lets me buy the coffee that keeps me caffeinated. Caffeine keeps me going to maintain the apps, bring in new features that I hope you'll love, and keep writing.

You may also find interesting...

Day 71

The Accessibility APIs are generic and flexible. They're not just for VoiceOver. If you implement them right, you can do it once and it will very likely work great for VoiceOver, Voice Control, Switch Control, Full Keyboard Access, and more. That's why, to start with, we tend to focus on VoiceOver, the same way you may focus on keyboard navigation for the web. A great VoiceOver experience will get you most of the way to a good experience with the other assistive technologies. We've seen one example with Custom Actions. One implementation works for: VoiceOver: https://x.com/dadederk/status/1550099327053451266 Switch Control: https://x.com/dadederk/status/1551236244088279040 Full Keyboard Access: https://x.com/dadederk/status/1551874732504629249 And Voice Control: https://x.com/dadederk/status/1552253520182640645 Of course that doesn't mean you don't have to test and check how the experience is with the other technologies. But before feeling overwhelmed, or for small teams, making sure your app works for VoiceOver is a great start.

Day 139

There are a ton of customisation options in the accessibility settings in iOS. When doing things the Apple way, this options should, in most cases, just work for you. If not, you can find flags to check for all these options in UIAccessibility.

UIAccessibility iOS

Day 225

Support both orientations, if possible. I know not even iOS itself does it, but it hasn't always been like that. You'll create a more robust UI that will be easier to port to iPadOS. And especially, don't force your users to rotate their devices.

Accessibility a11y

← Day 69

Day 67 →