 Hi, everybody. Thanks for coming. This is just a pretty short talk. This is only in the 20-minute slot. And I really wanted to bring out more about finding elements by accessibility ID. So it's a pretty introductory talk. The things near are aimed more for newer Appium users, like beginner to intermediate. My name's Jonah, Jonah Steenan. I work at Cloud Gray. We're an Appium consultancy. We do trainings. I work with Jonathan Lips here. This is my GitHub profile photo that I can't change, because a lot of people just recognize you based on your photo. You can see it's not really up to date anymore. That is quite a bit, yeah. Also, just a chance to know one here if you haven't already subscribed to Appium Pro. A lot of people are really into it, and so it's very useful for, yeah. It's a weekly newsletter. You learn things about Appium Pro. It's definitely a way to stay in touch with the community. OK, so in Appium, I always break down Appium, like any talk or introduction to Appium or an explanation. You can break all of Appium into just three or four different chunks of things that you do. There's your setup, which is the desired capabilities. Then you have finding elements. And then you have interacting with elements. And then there's a bunch of other stuff about rotation, orientation, changing languages, touch actions. That's all the side things. But the main parts are your session with desired capabilities. You have ways of finding elements and then things to do with the elements. So specifically talking about finding the elements, these are all the ways that Appium has of finding the elements. And I've kind of ranked them here by what I would say is my ranking of the importance or the usefulness of them. And so at the very top, I'm saying that accessibility ID is the best way to get an element when it's an option. And it's not always an option. And we'll talk about that a little bit later. But accessibility ID should be your preferred way of finding elements. And XPath, which tends to be everybody's favorite, has different problems for various reasons. And the Appium community, always the developers in Appium are always saying, use accessibility, don't use XPath. But no one ever really talks about why exactly. And so that's why I'm going to try to argue here is to, these are the real reasons why we say please use accessibility and please try not to use XPath whenever you can. But because sometimes you need to use what you need to use, that's why, of course, we provide it. So what are these accessibility IDs? The important thing is that while we talk about using them for Appium, that's not what they're originally designed for. The whole point is that your devices that now everybody, their mobile phone, is really a part of their life. And there's actually a large population of people in the world who can't use these devices. And then these are people who are handicapped or have accessibility demands. And they're not something they can do. And if you want to gain a better understanding of what is accessibility, then what you can do is you can, on your devices, actually put them into accessibility mode and try it out. And it's interesting, because it's a way of using your device that you can use it with different controls than you're normally used to. That would make it easier for somebody who maybe your hands are shaky or you don't have as good control and you can't touch the tiny little icons on your app. Also, if you can't maybe read small text or have issues with your visibility, then the phone is actually talking to you about what you can do on the app. And a lot of people I know, even professional testers, know the importance of this accessibility stuff. But not many people have actually tried it. So we don't really have time to go through it during the talk here, because it's only 20 minutes. But if you want to try it out, if you're on Android, which we're talking about first, you can install the Accessibility Suite from the Google Play Store. So it's not by default on your device, depending on your vendor. But if you install the Accessibility Suite, you can then go into Accessibility in the Settings app and you can try out something called Talk Back and Select to Speak. And I have a little video of me kind of using it here. There we go. What it does is, there's this green box that currently highlights what you're selecting. And on your phone, you can just swipe and it moves the green box forward, like through your views, or back, and it goes up through the views. And each time the green box goes over an element, there's a voice that comes out of the speakers or into your headphones, and it says something. It'll say like Month Select or May, Calendar Picker, 30th May, the Thursday, June, 9 to 15. And so it's reading that to you. And so the question is, how does the Android Appering System know what's important? Because if Yth was just going through all the elements on the screen, then the green box would never move past the top because there'd be like table view, table view, table view, this thing. And you would be selecting all sorts of things that aren't important, and it's somehow able to know the parts that are interactive to the user. And the way it knows is that each of those elements is marked with special accessibility identifiers. And so the thing we're looking for is if these accessibility identifiers, which are default on all the Android widgets, but if you build your own widget, you have to like build in the support for that. And it uses separate identifiers that you pass in to say what should the system read out loud to you when you're going through it. And like I said, you go through by swiping forward and back. And then if you want to tap on one, you have to double tap anywhere on the phone. So that way you don't need to be picking the exact part of the screen. You can use the whole touch screen kind of like a controller for the app. So how do developers add this to the elements? Like I said, they're by default on all of the widgets, but if you're building your own widget or you want to put like a specific thing that you want this reader to say, it's done this way. So there's a content description property that you set on the element. The reason I'm going through this of how to add it is because if you can understand how incredibly simple it is to add these, then you can now talk to the developers and say like, look, it's no problem. Like you just need to add this. Or you can also talk to the developers manager or to the product manager and say, look, it's not like we're asking for something crazy here. All you need to do is if you're using, so Android has two ways of building an app, you can do an XML file or in code. So in the XML file, you're just on the element. So here we have an image button. You just say content description equals and you put in your string that you want it to say. If you're doing things in the code, it's pretty much the same. There's just a function on the button. So I have this play, pause, image view button element. You just do dot set content description and then you put in the string of what you want the description to be. And that's it. So it's about the same amount of work as changing the text on the button. When it comes to platforms that are frameworks built on top of Android, so we have React Native and also Flutter. People have been talking to me about Flutter here. Both of those have accessibility APIs in their documentation that when you add that in React Native or Flutter, it will insert this content description into the screen here. So if you use one of these frameworks, it might be a little bit more work to get it set up, but you can still add these accessibility IDs. Now we go to iOS. You guys have to know how to do it on both. So same thing in iOS. You don't need to install anything different. It's available on every phones by default, except it's not available on simulators. There's always something that isn't good with Android. It's something that isn't good with iOS in a different way. So you can't do this on your simulators, but if you pull out your real device, go into the settings app, choose accessibility, choose voiceover. It's the same thing. If you go through the elements, you can go back and forth, and it's double tap to select something and it's reading to you. So how do we add that in iOS app? On iOS again, there's two different ways of writing an app. One is in the code, and one is using the interface builder, which is kind of a visual tool. So in the code, it's as simple as you take the button object and you just say dot accessibility label equals and then a string. In your interface builder, you select the element and then on the sort of options to the right side, you can pick that there's accessibility section there and you enable it and you can put in a label. There's also a hint and identifier. You can look in the documentation as to what the differences are, but again, it's very simple to add and it shouldn't really be a lot of hassle. Okay, so that's kind of explaining how accessibility works on these devices and I really encourage you to try it out because it will really give you kind of a feel because it works but it's pretty frustrating, right? Like it's not what we're used to when using an app and so it really helps you think about like maybe I don't want to add an extra button to my app if it makes this more difficult. It's always something you have to work on. So now we've seen accessibility. Now how is that versus the XPath here? So why is XPath slow? Say the XPath is slow. XPath is slow for a couple of reasons. Specifically, it's slow on iOS because the way XPath works is XPath is built for querying a node within an XML document and so the way we implement it is we take the view hierarchy and we turn it into an XML document, then we can use a publicly available library to get the XPath to go through your XML and find your element. But in iOS, there is no XML file that describes all of the elements. So what we have to do is every time you use XPath, Appium on the phone has to go and take the top element and go through all the children and go through all those children and go through all those children and go through all those children and then basically write a text file of the XML. Then it has to send all that across the wire over to Appium and sometimes it can be a big file and this is why it doesn't work when your UI is too complex. Then it runs the XPath on that. So definitely the larger UI, the worse it gets. Now, why is accessibility ID fast? So I did a bunch of digging here and if on Android you were writing a UI Automator 2 test and in iOS, if you were writing an X UI test, this is the way you get an element using the accessibility ID. And so if you get them this way, then it's basically, it has already an index inside the app. It can directly get those. So for a simple app, I made this simple app, Jonah's app, just has a button on it. Finding the button using accessibility ID, 74 milliseconds using XPath, 318 milliseconds. So it's longer, okay. At this point I realized that probably nobody actually really cares about this performance because the slowest part of your app is not how long it takes to find something, but it's more about hitting the button. But I still want to just demonstrate why we say it's slower even if really it's probably not making much of a difference to your test suites. So I started to make, I started to take the same app and I made it so that there's a table view inside a table view inside a table view inside a table view and I kept changing the number of nested views to see how the speed changed. And as you can see, the accessibility ID kind of stayed the same and the XPath is getting much slower every time I go higher. And I was actually kind of disappointed with the number of data points here because I wanted to go at least to like 1,000 but after 50, iOS crashes. So even iOS can't handle big UI hierarchy even without the XPath. So pretty much there's no point in even getting that large. All right, so kind of into the more important thing here is that accessibility, these are also just easier for the testers to use. But a lot of you don't have that option because even though I showed how easy it is for the developers to add it, the developers just might not be people who you're able to get them to do things. You know, like they have the PMs and their engineering managers and their own priorities and the QA priorities for some reason just don't tend to get in there. But we can argue that accessibility IDs not only make the testing easier but they have other benefits as well. So we can tell them that they're easy to add. It's also an industry standard. Every single framework has these accessibility labels. It also, the way things work, the web has accessibility labels, people using screen readers. It's sort of an industry standard for all the people who need this sort of thing. And then it helps handicapped users. And you can always tell a business person this expands your user base. So I looked for some statistics. The World Bank says that 15% of the population is some kind of disability. And so really after, you know, a point where you have like an app that a lot of people do, this is something like Facebook, for example, can't ignore because 15% of their user base is like several hundred million people. And it's not just people who like can't see well. It's also the hearing impaired. Like I said, hand holding impaired. And also just the elderly. Like these phones are small, you know? And you don't have to think of handicapped people as somehow like they have crutches or wheelchairs or something. It can actually just be a pretty normal person. But for whatever reason that, you know, the phones can be very difficult to use. Also, in some countries, I noticed in the US, if you don't support accessibility, you can actually be sued by people. So if your company is big enough and you don't support it, someone can say like, hey, I need to use your app like you're a bank. You know, I need to access my account. You don't support my screen reader. Here's a lawsuit. So that's a good reason to do it. There's also very interesting something here that the accessibility IDs are made for people to be able to be allowed to use it easier. But also it helps our tests and makes our testing easier. If you think about it, anything that the person uses, the test needs to use. If the test can't find the element, then a person probably can't find the element. And so that's another reason that the accessibility is very important. They don't just help the accessibility. They also help robots. So if I have an app that's trying to go like a crawler, for example, all these machine learning crawlers can use the accessibility to find out which parts of your app are important to a user. It also helps your SEO. Google looks through all the websites in order to rank them. You'll get higher SEO on sites that have better accessibility, not just because Google wants to reward people who are going out there to help get out to every kind of user, but it helps Google's algorithms semantically analyze your web application because sometimes they can figure out if you have an image that's actually a button, most of the times they can say that's just an image, but if it has an accessibility label, then now it's obvious it's a button. Also helps with voice commands like Siri. So that's pretty much it there. So these are all the reasons to use accessibility IDs and the whole point here is it's to make testing better and also makes the apps better for everybody. So thank you. Any questions? Because I think we have some time. Yeah, Dan. Dan's asking about how to deal with localized accessibility labels and I have no idea. Thank you, Dan. Oh, it definitely, they are human readable. Yeah, yeah, don't just put like, yeah, don't put in your specific for your testing, like whatever you internally call it. You want that to be like the public facing thing and that way it helps out. You know, it helps out everybody. This is kind of a cool way where this way, like it's not just some random ask from QA, you're actually improving the product. You know, so this is also like product, you know, the PM should want this to you. Jonathan has an idea. So you can, to summarize for the, you can use the, you can actually get all the localized strings out of the app using Appium. So then you can use whichever string is connected to that accessibility ID. Other questions? So you can enjoy an extra five minutes and thank you.