 Hello everyone, my name is Madhushan. I'm working with a company called Hatikas, so we're trying to make it easier for the people with disabilities to commute between Singapore. We were together with some government organizations to make it easier for them. So as part of my project that happened to be an experiment on these accessibility features on the iOS you have. So I'm here to share my findings with you guys. So this talk, I will go by two main topics. One is what does it mean by accessibility for the iOS ecosystem. And next, I'm trying to look at how to make your apps accessible. So for that I will take two existing GitHub reports which are not much accessible. And we will see how to make it more accessible especially for voice over users. Accessibility is a wide subject. So I had to choose one area or one or two areas and see how we can improve our apps in those two areas. So if you are not familiar with the accessibility so you might be wondering what it is. What does it mean by accessibility? Accessibility is about supporting all users regardless of their abilities. I mean, giving all users the great features you put into your apps. So regardless of their disabilities or whatever the disabilities they're having. So I should say from the very early iOS versions Apple has been supporting this accessibility feature pretty well. It's voice over and some... I mean, I once have some hearing aid support like this. So it's great to see that Apple doing great job in this area. So as developers we should aware that these kinds of features you have the users having their devices. For example, this one is the inward color mode in iOS. So I mean, if any user have some difficulty in differentiating colors so they need higher contrast ratio than the normal users. So they might enable these modes. So you should aware that, I mean, there are significant number of users that might enable these modes. Why the gray scale mode, right? So the message with gray scale mode and this... the one I showed earlier is that the color shouldn't be alone represent any state of the app. I mean, if you're using just color to represent something, so what if the user is color blind? Right? So for those users they don't see any difference. So when you're designing your UI, I mean, remember that and make your designers aware of that these set of features you're having your devices. First come, this is another one. This is the switch control is the first one. So people with physical and motor disabilities, I mean, someone died, it's doing Hawkins. I mean, all they have is this kind of the focus element that keep moving in the app. So once it gets to the element you want to activate, they just have a switch, the one switch. So that switch can be either eye blink or some head movement or some just tap. You can configure in whatever way you want. So the second one is something I think at least every app must support. So this is about dynamic font sizing. So I see a lot of apps is keep this one, but when I'm using transit, I see a lot of users, especially elderly people, look at their phones like this, right? So I mean, they're having some tough time to read the text and the elements of the app. So keep remembering that there's such feature in the device. I mean, most of the Apple own apps support this pretty well. So you can, for example, say go to settings and change this to the font size and check how your app behaves for these changes. Anyone here has enabled the voiceover feature of your iPhone and just how it works? There's a feature for voiceover for people with blindness. I mean, it is to read the elements to app. No one tried, apparently no one. So earlier I mentioned that the configurations users can make their devices to adjust the device to their requirement. But in your case, if you still want to have the animation reach and the great UI you create, but you can use this API to check whether the user has enabled this one of these settings. And I mean, you can adjust your UI based on the current configuration of the device. I mean, average, I would say, I mean, don't... I mean, this is kind of the design and everything, but don't make apps, I mean, much fancier with unnecessary animations. Make it simple, right? Have something for nice interaction, but don't make use of them without any purpose. Think about these people when you're developing apps. So I'm going to take few examples of how well these apps support these accessibility features. So this is the first one. So I hate to bring this one because they have improved these apps from the PS version alone, but in terms of accessibility, let's see how well it works. Voice over on. Deep FH. FH. Fee. FJ. Login. ATM and branch. Markets. Button. Insights. Button. Promotion. Button. Online account opening. DBS Marina Regatta. FH. FH. FH. FH. Apple Pay. You get the point, right? They're not doing good job in terms of accessibility. As a banking app, as a prominent banking app, I would expect they shouldn't ignore the blind people. They might have bank accounts. This is one of the... I think for sure they're using some platform thing. That's why the buttons are beginning like effects, effects, effects. Right? If you're using the native control, so you have these access features for free. If you're using a button and your button has a name, this accessibility speaks this name to you automatically. Why this one is not doing good job is they're not using the native button. Especially for example, they have some segmented control to pick a segment, but at least when you're navigating, the segment should say which element is highlighted, but this one not saying that. I mean, the user doesn't know which one is highlighted, either promotion or banking, whatever. Right? And the second thing I noticed is, once you bring the slide in the UI, so it's still speaking the elements in the behind. Right? That's a problem. So, yeah, I'm going to take another application and see how it works. So, from... Can you use the grab app? Okay, I'm kidding. So, this is the notification center. And the app is the workflow. This one won't award at the last time that they're busy for the best app using the accessibility features provided by the APIs. So, I pick the notification system rather than app also doing really good job because of the accessibility. But here, I will show you one thing that they're doing. So, this is the workflow app is that you can aggregate certain tasks into one action and you can execute it. For example, the first one, the share location, what it would do is, it would fetch my current location and get the URL from the Apple Maps to that location and send it to a preconfigured email. For example, if I'm a blind user, that is really helpful. I mean, if I want to share my current location to maybe my parents or my friends, so, I mean, it's simple as pressing one button. So, he will get an email with a proper link to my current location. I'll show you how it works. Yeah, for example, the first one, the workflow app is just a one-button click. It gets your location and email your URL to your location to preconfigured email. The second one is the bus, the SG Nexmas app. It also doing some good job. I mean, when you're supporting accessibility, not just about reading the element you have in the UI, it must make sense to the user with these disabilities. So, for example, this one is picked, I mean, it doesn't just say it's a one or something, it says the one minute and the next bus in three minutes like that. So, now I'm going to see how you can make your apps accessible to these users. I mean, these four, I mean, these four are the two categories. So, one is the visual accommodations. So, this is about using the, I mean, supporting your apps in terms of the configuration that user can make. For example, the grayscale mode, the inverted color mode, you should aware of that and you should design for those features in mind. So, second one is the semantic accessibility. The semantic accessibility means using the existing APIs to make, for example, the voiceover. So, how do you support the proper voiceover use case in your app? Yeah, the first step when making your apps accessible is design for accessibility. Without even thinking about the APIs or whatever it is, first you should design for accessibility. I will take one example here. Yeah, this one, this is two very famous apps. You may already know the both apps. So, one is, I mean, here, I can say one app is great in terms of the accessibility and the second one is not that great. So, who said one is the great one? First one. Okay, so what are they saying? The second. I'll show you what's the difference. So, assume if you are colorblind. This is what you see. So, in the second one, you don't know which one is it. But the first one is, of course, the apple fauna. So, the point here is don't make, I mean, the second one is using just the color only to represent the state. That's the problem. But the first one, I mean, they just, I mean, not only using the color. They fill the element with the color. So, the colorblind uses no, the reason is the one selected. And you can notice this. I mean, this is a great example of one of the examples of app pearls, attention to detail. Right? And second one is dynamic typing. As I mentioned earlier, you should accommodate the font size changes. I mean, the font size changes should present in your app. So, we can, yeah. I can show you some demo for this. So, I'm using this app from VeeVee Desi. I can sign in VeeVee as she's learning iOS. Yeah. I think she, this is her first, very first iOS app. So, I'll show you how you can make it more accessible with the APIs. Right? So, for that, I'm going to need to connect my phone. Sorry, sorry, sorry. Below the arrow, arrow beside the record button. Okay. This time. It was great. So, yeah. This is, this app just showed the, the events happening in Singapore in the next two days. And also it has, it showed some famous, I mean, the popular GitHub reports related to Singapore. So, it's a very simple app. So, that's why I choose this easy to explain using this app to how to make it, how to make dynamic typing works with this app. So, if I go and change the, so this is where you can see the accessibility features and go accessibility. I select the larger text. I increase the font size. You can see the Apple apps, they dynamically change the font size when I adjust in the font. So, if I go to this app, it doesn't change the font size. Right? So, I mean, it doesn't support accessibility. So, I'm going to show you how to make it support this dynamic typing. Okay. Okay. So, I mean, this is the list view controller. So, the controller controlling the list view piercing. So, here the method for the cell phone related, cell phone at index bar. So, here I mean, this is the two lines I made to the font adjustment work when I adjust in the font. I mean, rather than using the static fonts, Apple has its own set of the font styles you can use. Right? If you're using these font styles, it will automatically change. But you should remember to add this here. In the VVD plot, you should listen to this notification. Right? This one. UI contents are scalability change notification. If you didn't listen to this, you have to wait until the next app launch to adjust the font. If you listen to this notification and call the reload table, once this notification is sent, so then you get the... I mean, it should automatically adjust the font size. Right? I run it. Yeah, maybe. She doesn't know I picked this up. This is the first one. Yeah. As you can see, the label size and the date label size get adjusted to the font size user's adjustment. I mean, this is great in iOS 8 because the house is now the dynamic cell height thing. I mean, you don't need to manually calculate the required font size. If you use Autoleo properly, you will get this for free. You just need to use the font styles instead of the static fonts. So that's the point. So I'm going to... Yeah. Except for this, I just added one more feature to this app, like this sliding thing. This share button don't have any actions, but what I'm trying to say sure is, so I mean, how these features should support the accessibility. Like, I mean, when you enable the voiceover, the system takes control of the gestures. So you don't have the manual control of gestures. I mean, the OS has the control of everything. So you have to deal with the OS itself. So if I enable accessibility, I think I have to. For some reason, the sound from the phone doesn't get sent to the... through the HDMI. Sorry. Okay. I'll skip that part. So one more thing I have to say. So this is... The accessibility has some... something called accessibility crates. So crates and the values. And it's about answering the question. The system will ask you some questions. So you have to answer those questions. Then the system will speak those questions properly to the system. So if I go back to the presentation. So we are moving to the UI accessibility and the voiceover. UI accessibility is an informal protocol, which is... It's the extension of the NS object. And if you talk about the object, you see it's a category for the NS object. So every NS object has this capability of the UI accessibility. So, I mean, there are basic five questions you need to answer. So I'll show you one of those five questions. And as an example, I take one component. This is from the Apple's own setting set. Let's say how the system deal with this particular component in terms of the voiceover. Noise cancellation. Left-right stereo balance. 50% left. 50% right. Adjustable. Swipe up or down with one finger to adjust the value. Right. You can see how the system deal with this kind of controls. So now I'm going to interrupt those five basic questions you have to answer in reference to this particular control. The first point is the voiceover purpose. So if you... I mean, every element should be accessible. For example, you have some UI we use... I mean, if you make every UI we use accessible, it's a mess. So you should focus what elements should be accessible. And this is a binary question. Yes, no question. So you should say true or false whether this element is accessible or not. Right. The second one is the name. So this is about the accessible label. So this is the one the system speaks when the voiceover user interacts with the device. The third question is the traits. Traits is about the personality. I mean, how... For example, the element I showed you, the trait is... The system says it's an adjustable element. There are few traits. For example, buttons, adjustables, labels, like that. So this one is... The one I showed you is an adjustable element. And next is the value. So in the control I showed you, it says the 50% left, 50% right. So that's the value of that element. The thing is how to interact with the element. In the pre-example, it is side up or down to adjust the value. So if you answer these five questions properly, you will get a good level of accessibility in your app. So I mean, at least try to answer these five questions in your app elements. This is the last demo we have. It's a chart control. So it is... I'll show you the app. This chart is not accessible. It's also a library from GitHub. I think it's a famous charting library. How many stars in the GitHub. So the problem with this chart is it's rendered in the UI web. I'll explain a little bit how it works. So they have some class for the bar view. And it has different render classes for two axes. And one render classes for the charts itself. So when the draw rate element of your... The controller gets called. The in-weave gets called. So it will collect each renderers and pass it to the graphic context to draw each thing. So this one, the by default, they're not supporting accessibility. For example, if I try to... You can see the highlight doesn't get picked. This chart. So yeah, this is a project. And I'll quickly go through it. This is the render classes for the bar chart. Here, what I'm doing is... So while it is rendering, I'm collecting the required information for accessibility here. And I assign it to an array called this array. It's an array containing structures for accessibility frames. So I collect those information while the graph gets rendering. And in the base class of the bar chart, I have a method for setup accessibility. This has... I mean, then here, I'm collecting... I'm iterating that array. And in the graph view, you can assign something called accessibility element. It's an array. So once you set everything, I mean, you can collect element inside the view. It's as a children of the view. So you get those elements and set the value. And you answer those... Basically, you answer that five questions. The freight, value, label, those things. And then assign to this array called accessibility element. So make note that in this array, before assigning the elements, I also attach the parent view. Because if I didn't attach the parent view, it will just quickly jump through the bars of the chart instead of the total graph. I'll show you how it works. Here, I need to show you the... In the simulator, you can actually inspect the level of accessibility you are having here. In general accessibility, you have this accessibility inspector. You can see... I mean, this is the way you can see the accessibility in the simulator. There's no voice over support for the simulator. I mean, it will show you the answers for those five question dimensions. So the label is tuned. The value is 31.0. The frame is this and it will show you how the voice over will interact with this element when you run on actual device. So here, the takeover should be when you are making these kind of graphs accessible, don't only make the frame for the element. Expand the frame until the top edge. Because, let's say you have something called element for zero. So then the voice over users cannot... I mean, it's not like enough for those users to trace and see what's behind. Anyway, I'll push this code to the GitHub. So any question you can tweet at me or ask in the group. So what's going to be the future for this accessibility? So it's remembered that Siri API is on the way. I'm not sure. Anyone going WPC this time? Yeah, okay. A few people. Yeah, if you happen to... As a minor, if you happen to bump into an engineer from the accessibility team, just please ask this how Siri will help to make apps accessible. I mean, instead of having Siri at one location, so if Siri can interact instead of the voice over, it can do many more things, right? And second thing is the home personality. You can see the Google also introduced something for Amazon Alexa. And we may see something like, hey Siri, do this, do this in your home. So if the Siri API is coming out, it would be great for accessible people because then only you can support your apps to interact with just voice. So, okay, as the final slide, so the takeover should be the user base is diverse and the users are aging. So, keep in mind that these users, in number they're not insignificant. There are a lot of users with this ability to support them and invest some time for them. I mean, so if you support accessibility, as I said, it will widen the user base. I mean, wide user base means more users will have access to your apps and that means more users will use your apps, right? And also the accessibility is something low-offered, high-reversed thing, right? You can say if you answer those five questions, maybe we'll get a lot of accessible features. Okay, any questions? Do you have any statistics to share how many of the iPhone users are dying? Yeah, sorry, I don't have it at the moment, but I can say in numbers I can remember, but I can share some links. But I recently saw it that how many users affected with color blindness? There are a lot. It's like 4% of the population or something like that. I mean, it's not just about they don't see the black and white, but they have some users have the efficiency in seeing the particular colors. For example, they cannot see blue color properly. So, there are a lot. Around 4% of the entire population are affected with some kind of color blindness, for example. Any more questions? For the accessibility voice over feature, can we use it for non-English? Yeah, you can. So that means you automatically stick it there? No. In your apps, you have to use the localization properly. Yeah, I mean, don't just put the static text, but put it as the localized screen. So then, based on the language you use in the setting, which will speak in the language. That's slightly below the school accessibility. Okay. As it offers, we tend to use labels and add gestures or tap gestures or something like that. Yeah. As an accessibility user, if you add a tap gesture to a label, if you add a tap gesture in your code, it doesn't make any difference as for a normal user. You can still tap on the line, you can still show, you can perform some action on that. But when it comes to accessibility user, the system takes that as a label instead of an action associated. Yeah. So when you enable the accessibility on your application, you can detect this kind of design changes as well. So other, I don't have one experience, but I designed my UI as a label, and then later I got a requirement sheet. I had to make it as a button. So instead of changing the UI, I created a tap gesture added to that label. Okay. But later, this kind of accessible accessibility issue came in, and then I got to change that minor thing. Okay. So is it something, small things, that has a lot of possibilities sometimes? Yeah. That's a good point. I mean, at least enable accessibility. So you will find how fancy your app is. You think your app is great, but if once you enable the voiceover, you can see how fancy your app is. Right. Just enable voiceover and just take how these users will see your app's content. Yeah. I mean, please invest some time for these people. Okay. Any more questions? Okay. We can close. I think I'll put that call in the GitHub or something. Any question you can create at me. Thank you very much.