Hello. I’m trying to make parts of my iOS app accessible, and find myself stumped.
I have some video playing in a plain UIView. A custom (subclass of UIView) subview is displayed over the video view, containing a hierarchy of views, UIControls (buttons, progress bars, labels etc.). This overlay subview, is always in the view hierarchy, but after some time it fades away, animating its alpha (from 1.0 to 0.0). When user taps the video view, we bring it up, animating the alpha back from 0.0 to 1.0 1. When the overlay (containing the controls) is transparent - none of its sub-views (controls) is accessible in VoiceOver. Why? How can I revert this behavior? 2. When the overlay (and all its subviews) are visible, I can navigate to them in VoiceOver, but cannot enlist them by swiping down with two fingers, or swiping right/left to select next/prev accessible Item. I tried all kinds of things. * sending UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil), nil) when the overlay finishes fading in/out. No effect (probably because my view hierarchy doesn't change). * Implementing the full UIAccessibility protocol on my overlay custom UIView - but It is pretty heavy, because I need to deal with recursive search for accessible elements, and amazingly enough - even when I am correctly reporting them all — still VoiceOver won’t enlist them, and still they won’t be navigable when the overlay is transparent. * I tried to make my overlay view accessible - but that immediately bans it from being accessibility container - it won’t even be asked for its contained accessibleElement items. This overlay view is not tailored for a specific use - we use it in many places in the app (it draws a vague gradient, and all the control hierarchies over this gradient). * Most frustrating, when my overlay view is visible (forever, alpha=1.0, no animations) all the buttons are separately accessible no matter how deep they are in the view hierarchy. This means, UIView itself implements accessibility container protocol - to certain degree. So why won’t VoiceOver enlist them, or allow the user navigate through them? When I print the .accessibilityElementCount() of one of those plain UIViews in my control hierarchy (they’re only there to layout together sets of related controls, with constraints) I get the value of NSNotFound — which is out of the very definition of that protocol method!!!! definitions say a number - 0 if none. NSNotFound is a huge integer. When I print the .accessibilityElements property of those plain UIView in my hierarchy - I simply get nil. If so - HOW DOES VOICEOVER dig down my hierarchy to find the controls? The documentation states that VoiceOver is not part of your process, and so it has no access to the view hierarchy - only toe the Accessibility protocol. That doesn’t match my reality. The documentation on Apple’s site is somewhat cryptic, and only answers to “what happens if everything is Apple’s controls” or “what happens if everything is your own custom accessibility elements” but not what happens in the middle - where most views Apple provided, accessible UIControls, but only SOME views in the hierarchy are NOT. It seems a little stupid to force full-fledge collection views everywhere, just to get the free behavior of accessibility navigation, where UIViews are meant to contain other views. After going through tons of blogs, docs, sample code and WWDC videos. I’m not a bit closer to an accessible app. Any knowledgable hint can make me smile again. Thanks! Motti Shneor _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
