Hi,
For anyone following this I've now managed to isolate a test case:
This project demonstrates the problem of a UILabel isAccessibilityElement state being dependent on the content of the accessibilityIdentifier of the same label.
Run on simulator 6.0/6.1 with the accessibility inspector ON to demonstrate the problem, or on device (tested on an iPhone5 - iOS6.1.4 & iPad (3rd gen) - iOS6.1.3) with either voice over active or the General -> Accessibility -> Triple-Click -> Triple-click Home = VoiceOver set.
To get a test to repo the problems I ended up adding the various frameworks that the BBC Weather App uses to the test project until the bug appeared - the key one was MessageUI.framework -> the weather App uses it for feedback emails. Removing that from the test project makes the problem go away.
So based on that and the traces of message calls in my message below I suspect something nasty in the 6.X version of MessageUI.framework is messing with the accessibility protocol on UILabel (at least - could be on other classes too, not tested) and making the value of isAccessibilityElement true when accessibilityIdentifier is non-nil.
I'd be grateful if someone else could confirm they see the problem, and if anyone has an iOS5.0 device lying around if it shows up on that.
Thanks,
Richard
On Wed, Jul 10, 2013 at 8:00 PM,
<email@hidden> wrote:
1. Re: Can't set a UILabel to not be accessible (Richard Groves)
----------------------------------------------------------------------
Message: 1
Date: Wed, 10 Jul 2013 11:22:55 +0100
From: Richard Groves <email@hidden>
To: Chris Fleizach <email@hidden>
Cc: David Dunham <email@hidden>, email@hidden
Subject: Re: Can't set a UILabel to not be accessible
Message-ID:
<CAN3G8kQQ20ozMdYsM9tOa+uM-zcs9DF-=email@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Running these tests on iOS6 - simulator and device, just that our
deployment target is 5.0 for support for older devices. Rebuilding with a
deployment target of 6.1 doesn't change the problem output.
It's not making a difference to the Log output if I start the app with VO
running or not.
I've moved a copy of the problem code to be the first thing that runs
inside AppDelegate -
- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
and am getting the same results, so I don't think it is any corruption the
app causes.
Tracing into what methods are actually called for the following two lines
of code:
dn.isAccessibilityElement = NO;
NSLog(@"DN-a11y D: %@", dn.isAccessibilityElement ? @"YES" : @"NO");
is interesting, the following messages are sent to various objects:
UILabel setIsAccessibilityElement:]
[NSNumber numberWithBool:]
[__NSCFBoolean retain]
[UILabel isAccessibilityElement]
[UILabel accessibilityIdentifier]
[UILabel isAccessibilityUserDefinedElement]
[UILabel storedIsAccessibilityElement]
[UILabel isAccessibilityUserDefinedElement]
[UILabel storedIsAccessibilityElement]
[__NSCFBoolean boolValue]
[__NSCFConstantString respondsToSelector:]
[__NSCFConstantString class]
[__NSCFConstantString description]
[NSTimeZone defaultTimeZone]
[__NSTimeZone retain]
[__NSTimeZone name]
[NSDate alloc]
[NSDate allocWithZone:]
[NSDate self]
[__NSPlaceholderDate immutablePlaceholder]
[__NSPlaceholderDate initWithTimeIntervalSinceReferenceDate:]
[__NSDate __new:]
[NSTimeZone systemTimeZone]
[__NSTimeZone retain]
[__NSTimeZone release]
[__NSTimeZone release]
[__NSDate release]
[__NSDate dealloc]
- the [UILabel accessibilityIdentifier] is the one that makes me wonder
what is going on. Why would changing or reading the isAccessibilityElement
need to check that in normal circumstances?
On Tue, Jul 9, 2013 at 4:56 PM, Chris Fleizach <email@hidden> wrote:
> So are you running this on iOS5 or iOS6?
>
> I believe on iOS5, if you set certain accessibility properties before
> VoiceOver or automation were running then those values would not actually
> be saved.
>
> In iOS6, I believe those values are preserved regardless of whether any
> accessibility features are on
>
>
>
> On Jul 9, 2013, at 7:16 AM, Richard Groves <email@hidden> wrote:
>
> Yeah - I've made a small test project and can't reproduce the error.
>
> Setting accessibilityLabel to @"" still seems to make it stop there as you
> swipe VO from element to element. I've got rid of it completely by setting
> accessibilityElementsHidden to YES.
>
> Have narrowed down the problem some more. It seems to occur as soon as I
> set accessibilityIdentifier to a non-nil value (we use that in automated
> testing throughout the app).
>
> Revised code:
>
> UILabel* dn = [[UILabel alloc] initWithFrame:CGRectMake(15, 61, 250, 34)];
>
> dn.accessibilityIdentifier = @"some text";
>
> NSLog(@"DN-a11y A: %@", dn.isAccessibilityElement ? @"YES" : @"NO");
> dn.isAccessibilityElement = NO; // Going to add the day name to the
> location name to make one item
> NSLog(@"DN-a11y B: %@", dn.isAccessibilityElement ? @"YES" : @"NO");
> dn.accessibilityIdentifier = nil;
> NSLog(@"DN-a11y C: %@", dn.isAccessibilityElement ? @"YES" : @"NO");
> dn.isAccessibilityElement = NO;
> NSLog(@"DN-a11y D: %@", dn.isAccessibilityElement ? @"YES" : @"NO");
> dn.accessibilityElementsHidden = YES; // Fixes the
> setIsAccessibilityElement not working by hiding it
> [self.view addSubview:dn];
>
> produces an output of:
>
> 2013-07-09 15:10:21.687 BBC Weather[38546:c07] DN-a11y A: YES
> 2013-07-09 15:10:21.687 BBC Weather[38546:c07] DN-a11y B: YES
> 2013-07-09 15:10:21.687 BBC Weather[38546:c07] DN-a11y C: NO
> 2013-07-09 15:10:21.687 BBC Weather[38546:c07] DN-a11y D: NO
>
> which is very confusing. This exact same lump of code in a test project
> produces the expected output of 4 NO's.
>
> Both projects running in same Xcode 4.6.3, targeting iOS5.0 running in
> simulator 6.1 or iPhone 5 with latest iOS (well, latest 6.X)
>
> Very confusing. Obviously something in the setup/running of the main
> project causing the problem, but I've no idea on how to find out what!
>
> On Fri, Jul 5, 2013 at 9:09 PM, David Dunham <email@hidden> wrote:
>
>> Weird, I have code which is
>>
>> label = [self smallLabelWithText: @"Ours" bold: NO top: &top
>> left: usLeft width: valueWidth];
>> label.textAlignment = UITextAlignmentRight;
>> label.isAccessibilityElement = NO;
>> [fScroller addSubview: label];
>>
>> and it seems just fine (the extraneous label gets skipped).
>>
>> Can you change the accessibilityLabel to @"" as a workaround?
>>
>> David Dunham
>> Twitter: @radiofreelunch http://www.pensee.com/dunham/
>>
>>
>
>
> --
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.apple.com/mailman/private/accessibility-dev/attachments/20130710/4f243bcd/attachment.html>
------------------------------
_______________________________________________
Accessibility-dev mailing list
email@hidden
https://lists.apple.com/mailman/listinfo/accessibility-dev
End of Accessibility-dev Digest, Vol 10, Issue 58
*************************************************
--
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