I've been going through our code base and setting the accessibilityIdentifier property on all of our buttons and text fields so that I can access them using UIAutomation. While doing this, I came across some code that was already in place.
[_goodButton setAccessibilityLabel:#"off"];
I can't find any documentation on what the differences are between these two methods. It looks like they do the same thing. Does anyone know? I find it peculiar that this label is set to "off" as well.
There's definitely some confusion about these two properties. I myself fell into that very same trap, but research and experimentation with VoiceOver and UI Automation testing showed there is a clear difference.
accessibilityLabel
This is the value that's read by VoiceOver to the end-user, or exposed through other accessibility tools. As such, this should be a localized string. It's best to keep this to a single word, if possible, describing what it is (i.e. 'Help', 'Play', 'New Note', etc.) It should also be capitalized, but not end in a period. This helps with VoiceOver's pronunciation.
Because this is end-user facing, as part of user-testing, a developer may change this to be more clear as needed. For instance, it may change from 'Play' to 'Read Comments'. Because of that, you wouldn't want this to be tied to automation testing as such a change would break any tests referring to the now-non-existent 'Play' label. That's where accessibilityIdentifier comes in.
accessibilityIdentifier
While accessibilityLabel is end-user facing, accessibilityIdentifier in contrast is developer-facing only and is primarily used to identify an accessible element to UI automation and testing tools. As such, it should not be localized.
A developer should use a value that makes sense in the context of UI testing only, not to the end user. For instance, a button which displays a help topic can have the identifier 'HelpButton' as that's clear to what it's identifying but isn't something the end user would ever need to be exposed to.
Make it a habit to use this value! Doing so ensures your UI automation tests will never break due to localization or from changes to accessibilityLabel.
accessibilityHint (including for completeness)
accessibilityHint is for cases where the accessibilityLabel may not be clear enough on its own. Since accessibilityLabel should, if possible, be kept to a single word, accessibilityHint can provide additional context. However, if accessibilityLabel is expressive enough on its own, you should leave accessibilityHint blank.
If it is determined that accessibilityHint is required, keep this to a simple, short sentence fragment, capitalized and ending in a period. It should describe what it does, not tell you what to do (i.e. 'Plays the current track.' instead of 'Play the current track.' as the latter sounds like an instruction telling you what to you, not letting you know what will happen.)
How this is used is VoiceOver will first read the label, pause briefly, then it reads the hint (e.g. 'Play... Plays the current track.' If the user disables hints, it will of course just say 'Play')
Hope that helps!
Instead of using accessibilityLabel (see below) you should use accessibilityIdentifier.
This github issue explains the difference:
Given that accessibilityLabel is an outwardly-facing string that is actually used by accessibility screen readers (and should be localized to the device user's language), Apple now provides an alternate property (iOS 5+) that is specifically intended for UI Automation purposes
You check this one
Accessibility Label and Identifier Attributes
The label attribute and identifier attribute figure prominently in your script’s ability to access UI elements. It is important to understand how they are used.
Setting a meaningful value for the label attribute is optional, but recommended. You can set and view the label string in the Label text field in the Accessibility section of the Identity inspector in Interface Builder. This label is expected to be descriptive, but short, partly because assistive technologies such as Apple’s VoiceOver use it as the name of the associated UI element. In UI Automation, this label is returned by the label method. It is also returned by the name method as a default if the identifier attribute is not set. For details, see UIAccessibilityElement Class Reference.
The identifier attribute allows you to use more descriptive names for elements. It is optional, but it must be set for the script to perform either of these two operations:
Accessing a container view by name while also being able to access its children.
Accessing a UILabel view by name to obtain its displayed text (via its value attribute).
In UI Automation, the name method returns the value of this identifier attribute, if one is set. If it is not set, the name method returns the value of the label attribute.
Currently, you can set a value for the identifier attribute only programmatically, via the accessibilityIdentifier property. For details, see UIAccessibilityIdentification Protocol Reference.
AccessibilityLabel is the value that’s read by VoiceOver to the end-user. As such, this should be a localized string. The text should also be capitalized. Because this helps with VoiceOver’s pronunciation. accessibilityLabel is used for testing and Visual Impaired users.
AccessibilityIdentifier identifies an element via accessibility, but unlike accessibilityLabel, accessibilityIdentifier's purpose is purely to be used as an identifier for UI Automation tests. We use a value for testing process.
Related
I have a huge VCL Forms application in delphi and there is an option to display or hide a certain control (MyControl) on each form. Right now the traditional option is enabled, so MyControl should be hidden at runtime.
In Delphi Designer both Controls are visible. Every form is derived from a MyForm-class and in its OnCreate-Procedure the Visible-property of a MyControl (if available) is set to false (according to the traditional option enabled). This does work (as I can see with breaking points and watching expressions). For almost all forms this results in the MyControl not showing.
However for one certain form at some point the MyControl-component itself or any other part of the program sets the MyControls' visibility to true again. How do I find out where this happens?
I am using Delphi 10.1.
my approach:
I've tried to watch the visible-property through the watching-expressions-window using several breaking points. But of course the watching-expression is not available anywhere in the Code (myControl.Visible will only work if the breakingpoint is somewhere myControl is defined). I set a breaking-point anywhere I could evalute myControl.Visible but the magic seems to happen somewhere in between.
So my question: is there some kind of a global variable name, so that I can evalute and watch the visible-property wherever the debugger pauses the program?
a different approach:
I set a data- and an address-breakingpoint but they never fire. Only when I close the program they pause the program a few times.
As advised in the comments, if this is your code you can modify the property to use a Setter and then set a breakpoint on the setter. However if this is not your code and it simply exposes the variable (field) then changing the code to include a setter can be anywhere from triovial to impossible depending on what else needs to be recompiled when you make the change.
If this is your own custom component then you can redeclare an inherited property to use a setter.
If this is not your own custom component - you could make it a custom component and simply change the setter for the property.
You can set a memory breakpoint to alert you to when a memory location changes but your success with this may vary.
I encourage you to experiment with the conditions you can put on breakpoints, get the debugger to work for you.
I've been tasked with supporting an application that is written in Delphi, which is occasionally crashing with the error message "Control '' has no parent window".
My question is not to understand WHY the error is happening, but to understand why the control has no name assigned.
Is the seeming lack of a name for the control a function of the way the control was coded (i.e., controls can have names but they are optional), or is this because the name of the control is inherited from the (non-existent) parent?
My question is not to understand WHY the error is happening, but to understand why the control has no name assigned.
Controls that are created at runtime, as opposed to design time, need not have names. So, this control has no name because the programmer created it without naming it, or it is a control created internally by another control, without being named.
It is perfectly normal for controls not to be named. It is perfectly reasonable for complex applications never to refer to control names.
There are multiple reasons, including but not necessarily limited to:
1) It wasn't given a name in the code.
2) It doesn't inherit a name for whatever function called it
I've been playing around with a button in my storyboard, and had a hard time getting a border around it, until I found a page where it showed how to add a User Defined Runtime Attribute. I was able to make the button look as I wanted, but I wanted to know if there was a way for me to view the list of available attributes for a particular Object.
Clicking the "+" to add a new attribute doesn't provide any kind of auto-complete to show the available ones, and looking through my project code doesn't seem to reveal anything either, not surprisingly. Is there somewhere I can find all of the available attributes for all/any Objects in Xcode? Searches here on SO and in general have not shown any useful results so far.
You can achieve the same thing from code, so just check the properties of UIButton (which is available in the documentation and with autocomplete) and you're good.
You also have to make sure you are checking the properties on an UIButton instance and not the class properties.
User defined runtime attribute is a list of key paths that NIB loading subsystem uses through unarchived process. After initialisation message -setValue:forKeyPath: will be send to your unarchiving object for each key path from this list. So available attributes are not more than set union of all methods with selector sort of -setAttribute: and ivars with "_attribute" or "attribute" name.
All that public attributes you may find at public headers or documentation.
There's also possible to set private attributes, but it's not good practice. For instance, you may find all ivars by breakpoint execution inside any method and look inside "self".
for an SDK, I would like to create a text field class that behaves like a standard UITextField except that it is impossible for the developer using the SDK to know the value of the field (for security reasons). Is this possible?
My approach: When creating a UISecureTextField that inherits from UITextField, I can overload text and the notification delegates, but am I missing something? Is there still a way for the developer to access the field? Would you do something differently?
Instead of blacklisting certain methods, you could go the opposite route – use containment so your UISecureTextField has a UITextField private property, and then whitelist the methods and properties you want to expose by calling through to the text field.
More work to maintain, but it's another way to do it!
How can I access an attribute that's been hidden via:
__attribute__((visibility("hidden")))
I'm trying to access UINavigationItemButtonView, but it seems sometime recent (iOS 7.1?) they've added the above into the header file. Recursively printing the window no longer reveals UINavigationItemButtonView in the view stack either.
So, given a UINavigationBar, how can I access a UINavigationItemButtonView that has been hidden via the above flag?
Printing all the subviews in UINavigationBar doesn't reveal it.
The attribute keyword is simply a message to the compiler, and has nothing to do with the runtime. Using ((visibility("xxx")) only serves to tell the compiler if the given declaration should be "visible" or usable by clients in some other package. visibility("hidden") just means that, despite the public declaration, make this thing invisible to external packages, so that they will not be able to use it. Compiling will fail if you attempt to use this class or method.
If you don't see this class being used in a recursive description, it is likely that this class is no longer used; it certainly isn't because of the attribute statement.
Since it's a private class, you shouldn't. Anything you do to bypass that restriction may result in your application failing the review process. Not to mention that, in general, accessing private and/or hidden API's, classes, instance variables, properties or whatever else it is, is a really good way to make sure your application breaks in the (not too distant) future.