What's the difference between setAccessibilityLabel and accessibilityIdentifier in ios?

Question

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.

Pluvious

Answer 1

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

Perren

Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – Charliecharline

Answer 2

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!

Necessarily

Also with the hint it is important to remember that users can (and often do) disable the hints so only put hints in there – Lorylose

Well explanation! – Palumbo

Thanks @nahung89! I try to write my answers in a way that I would like to see them... to help myself and others learn. Glad you agree! :) – Necessarily

Answer 3

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.

Nacred

Answer 4

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.

Bullington