Even when setting a view as modal for accessibility, you may notice that VoiceOver's focus stays in the same place, instead of moving to the presented view. You can post a screen changed notification and pass the view that should get the focus.
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...
@JanJaapdeGroot presented the ScreenReader app for An app to help anyone learn VoiceOver's gestures in a very creative and playful way.
When presenting a UI component that overlays the existing UI, you may have found that VoiceOver starts to randomly jump between the overlaid UI and the elements underneath. To avoid that, you can set its accessibilityViewIsModal to true. When setting the accessibilityViewIsModal to true for a view, VoiceOver will ignore its sibling views, treating it as if it was a modal. Useful when presenting custom popups, popovers, modals, action sheets, etc. https://developer.apple.com/documentation/objectivec/nsobject-swift.class/accessibilityviewismodal
It is useful to know these VoiceOver gestures to activate/deactivate Screen Curtain, pause/resume VoiceOver, easily simulate a long press for opening context menus, or quickly move the cursor to the screen's first or last elements.
Content © Daniel Devesa Derksen-Staats on Accessibility up to 11! is licensed under CC BY 4.0. License details
