What's the difference between setAccessibilityLabel and accessibilityIdentifier in ios?
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.
Answer
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 to you, not what it does.)
Hope that helps!