Re: Problem when too many elements in UIAccessibilityContainer
Re: Problem when too many elements in UIAccessibilityContainer
- Subject: Re: Problem when too many elements in UIAccessibilityContainer
- From: Richard Groves <email@hidden>
- Date: Thu, 25 Jul 2013 11:50:34 +0100
Hi Chris,
Thanks for your help on this - very enlightening.
I'd thought it would be ok for the accessibility container to represent a whole hierarchy to control the order of VO presentation, but re-reading the documentation in light of your comments does seem to imply the vended items should be direct subviews. It's a shame it works with the full hierarchy as well as it does otherwise we might have found the problem sooner.
Rather than writing a bunch of subclasses to override -(id)accessibilityContainer in for each type of item we add to the view I'm going to have a go at making our container class vend out UIAccessibilityElement objects for anything that is not a direct subview - and frankly it might be easier to just vend those out for all items regardless of position in the hierarchy.
I'll report back on how I get on.
Cheers,
Richard
On Wed, Jul 24, 2013 at 8:35 PM, Chris Fleizach
<email@hidden> wrote:
Took a little look at this.
It appears the problem is occurs because you're sticking subviews into an accessibility container that has a different parent hierarchy.
This messes up the ability to determine where VoiceOver can find the next element.
So, it looks like you have
A11YContainer
UIScrollView
UIView (axElement)
But A11YContainer returns UIView (axElement) as one of it's children.
Generally the UIAccessibilityContainer protocol doesn't work that well when you mix in view hierarchies.
A way to fix this I think would be to override
-(id)accessibilityContainer on your UIView element to return A11YContainer, which is what would normally happen when using a UIAccessibilityElement (the recommended child if you're using a container protocol)
On Jul 24, 2013, at 8:16 AM, Richard Groves <
email@hidden> wrote:
Hi,
We've had a problem in the BBC Weather app since launch whereby if there are too many hourly slots for the current location the accessibility list can't swipe through them all - it gives the 'thud' noise indicating end-of-list mid way through the items. I was able to isolate it down to an exact number of views in the UIAccessibilityContainer we are using at that point of the app - add one more and it breaks, remove it and it all works fine. The magic number is 24 views in total - 24 works, 25 doesn't.
I've finally managed to replicate the view hierarchy and setup into my test project at:
and it demonstrates the exact same problem, even though it uses a much simpler set of views and a simpler UIAccessibilityContainer class for presenting accessibility items to the VO system. I've not worked out if it the exact same number of views that cause the problem, but having 10 column items off to the right works, having 24 doesn't.
The code in the test uses accessibilityElementsHidden to turn on/off a bunch of elements depending on if the user has chosen (by tapping the 'summary area' button) to view the more detailed content: otherwise they are just in a basic view of 3 items which works fine. The curious thing is that if the user taps on an element that is after where the swiping has stopped they can continue on to the end of the list, but if they come back until the focus is on an item before the false end then they get stuck again. In the setup as currently on github the false end comes on the 4th item (labelled 3) of the first page - tapping on the last item allows the swiping to continue.
Questions:
1) Has anyone else seen this sort of false limit in their own code?
2) Any ideas about what might be going wrong?
Thanks,
Richard
PS: This code also outputs a lot of the debug messages '**** Accessibility: Could not find a valid index for ....' when it changes the container contents as the user selects to see the detailed views to the right of the main view - no idea if that is related.
--
Richard Groves
Technical Director | NoodlFroot
M:
+44 (0)7962 054 163
NoodlFroot Limited is a company registered in England and Wales with registration number 07245048.
Registered office: 145-157 St John Street, London, EC1V 4PY.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (
email@hidden)
This email sent to
email@hidden
--
Richard Groves
Technical Director | NoodlFroot
M: +44 (0)7962 054 163
NoodlFroot Limited is a company registered in England and Wales with registration number 07245048.
Registered office: 145-157 St John Street, London, EC1V 4PY.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden