We have been facing this issue wherein developers are not going to use accessibility ids and accessibility labels anymore. We still can use other locator strategies to keep our existing and new scripts running, Need help on how to overcome this issue? Also please suggest any other tool for mobile.
@Chats1859 you can go with className/id etc. also there are lots of locator which are equally effective as accessibility ID/Lablels.
By the way as per appium philosophy you really need not to make any changes in exiting app in order to automate it.
Here is the link for details:
Thank you for your reply abhiqa but wouldn’t that slow down the performance of appium tests ?
It will.
Basically you need to get a team policy in place. Every time you need a control to have an accessibility ID, you raise a defect ticket. Simple, devs will start adding ID’s automatically after a batch of these tickets land on their desk. The time to fix the defect and add 1 line of code is tiny compared to the wasted time to write a test for that screen, and then the time wasted in automated runs being 5 times slower; adding to your product release cycle directly.
1 Like
@Chats1859 you can get it done (what ever mentioned by @Conrad_Braam) vai your project manager by explaining the situation to him/her and try to convince him/her that it’ll save lot of efforts and time in script development/maintenance as well as during execution. 
2 Likes
Thanks, Conrad, but going forward Accessibility are not going to be unique ID’s as dev’s gonna use those for its actual use Accessibility testing which means those ids will be kind of sentence or so.
Thanks abhiqa, May i ask how do you improve your performance of the test to make it run them faster ?
@Chats1859 go for other natively supported locator strategy. if you don’t have accessibilityID than there some other also e.g iOS predicate string etc .
apart from it avoid using sleep, and don’t define element are not used in tests and many more.
1 Like
Chats, that sounds fine. I’ve not used iOS predicate strings myself, some people say the performance is the same.
So your app is using the accessibility id’s on the forms to work with screen readers? I.E. you are actually testing with really disabled users? I always through this is what the ID’s were supposed to facilitate. I have to do some homework it seems. The automation ID’s are the same thing I understand, but the content should be populated correctly? Trying to understand the impact and the underlying decision I suppose. Are you saying your team is moving away from this : https://developer.apple.com/documentation/uikit/uiaccessibilityidentification?language=objc
@Conrad_Braam- late reply : yes you are right gonna use accessibility id’s for disabled users.
This has completely made us to move away from using accessibility ids as it’s nothing but a long texts now which is gonna help the people to screen read and navigate app smoothly.
1 Like