Apple

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:

https://github.com/richardgroves/A11yTest

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

www.noodlfroot.com

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

www.noodlfroot.com

NoodlFroot Limited is a company registered in England and Wales with registration number 07245048.
Registered office: 145-157 St John Street, London, EC1V 4PY.