Good morning, and welcome to Accessibility on iOS, my name is Ian Fisch and I'm an engineer on the Accessibility team. So accessibility is really about making sure all users, regardless of abilities, have full access to all of our products and the great features you put in your apps, and that means we get to focus on users and think about how users with these different abilities use our features.

That, in turn, has allowed Apple to create great futures to empower users, like the girl you see here with a switch mounted next to her head which allows her to control all of iOS, with just that one button. And that gives her the freedom to communicate and play without the need for assistance.

And as users get older and older, more and more of them will be using these accessibility features, so the time is really now to start thinking about accessibility in the terms of your app. So Apple creates these great accessibility features, but that's only part of the story. We need all of your apps to be accessible so we can create a great ecosystem for accessibility and empower these users.

Today we will be talking about the accessibility futures that Apple provides on iOS. We will look at what's new in iOS ,9 and we will go through what we call an accessibility audit, where we will look at an app and see how accessible it is already. Then we will go through implementing some accessibility in that app.

But first, let's take a look at the accessibility features that Apple provides. We break those into four large areas: hearing, learning, vision, and physical and motor. So I will go through just a few of the features that we have, but there are many more I don't have time to talk about today.

For hearing, we have made-for-iPhone hearing aids, which allow users to stream high-quality audio directly from their iOS device and control the settings of those hearing aids. This replaces a lot of extra hardware the user would have to carry with them all of the time and provides a much more private experience for setting these or changing the settings for hearing aids.

For learning, we have guided access, which lets teachers, parents, and caregivers remove distractions so users can focus on a specific app or task. And we even provide time limits so you can restrict the time allowed in a task. For developers, we provide an API that allows you to provide specific restrictions for your app.

For vision, we have VoiceOver, which lets blind and low-vision users touch the screen and have VoiceOver read what's under their finger. So they can use gestures to interact with the touchscreen even though they can't see the screen. We also have Zoom, which lets users who may need things to be just a little bit bigger but can see the screen magnify the interface of your app and the operating system.

And it will even follow text as you type and leave the keyboard unzoomed so you can still have full access to the keyboard. Finally for vision, we have Vision Accommodations, which adjusts the interface for users who might need larger text, higher contrast, or reduced motion so users can more easily orient themselves with what's on screen.

For physical and motor, we have Switch Control, which uses these switches, or large buttons, to control the operating system. It's great for users who may not be able to fully interact with the touchscreen, and it allows them to sequentially navigate the items on screen and perform complex gestures and even play games.

If a user has difficulty performing gestures or pressing a physical button, we have AssistiveTouch, which provides a menu to quickly access recorded gestures and hardware buttons. And this even works with third-party assistive devices like wheelchairs. And brand new in iOS 9 we have Touch Accommodations, which helps users who may have difficulty performing precise gestures by changing the way the touchscreen responds to touches, and I would love to give you a demo of that now.

Like all accessibility features, you can turn on Touch Accommodations by going to Settings, General, Accessibility, and you can see the large list of accessibility features we provide. But for now, we will go into Touch Accommodations. And you see we have got three options. Let's look at Hold Duration.

And this allows people who may have tremors and touch the screen more than they would like to set a timeout so not all touches are used. So let's turn on Hold Duration and Touch Accommodations. So I go back to the Home button, you will notice when I put my finger on the screen I get this timer icon, and if I lift up before the time is up, the touch isn't passed to the icon. But if I tap and hold for the whole duration, it will open the app.

So if I have tremors, they won't be respected as touches. Great! So if we go back into Settings, we can look at Tap Assistance, which is great for users who may not be able to land on exactly the right icon that they are looking for. So if we go back to the Home screen, you can see that if I press on Clock and then move to Calendar, the touch will be passed to Calendar instead of Clock. So it's the final touch location that's respected. And that's Touch Accommodations on iOS 9.

So, many of these accessibility features rely on UIAccessibility to bridge the gap between the assistive technology and your app. For instance, if a VoiceOver user taps on the screen, it will look for the element under their finger and ask the element in your app for its accessibility label. So when you return the string Weather, VoiceOver will speak:

Weather.

And similarly with Switch Control, the Switch Control user brings up the menu on one of your elements, will ask that element for its accessibility custom actions, and when you return the actions -- move, pass and trade, if it's a game app, maybe -- it will display those in the Switch Control menu so users have fast access to these actions on elements in your app. So you will notice that UIAccessibility is really about asking questions of elements in your app so the assistive technology knows how to work with it.

So let's go through a few of those questions. The first one is: Do I serve a purpose? This is really about whether an element is useful or important to the user. So a line that separates elements in a view is very important visually, but since the user can't interact with it and it doesn't provide information like a UI label, it's not really serving a purpose. So we answer this question with Is Accessibility Element. If we look at the Plus button in Clock, it's a button, the user can interact with it, and so for that we would return True.

The next most important question is: What's my name? We answer that with Accessibility Label. This is what VoiceOver uses to read to the user what's under their finger. If we look at the Plus button, you might be tempted to set the label to something like Button To Add A Clock, which is a great description of what the button will do, but you should think of the accessibility label more like the title of a button, so a better accessibility label would just be Add.

So what's the personality of the element in your app? And this is really about describing to the user and the assistive technology how they can interact with an element. So we answer that with Accessibility Traits. So we have a whole host of traits that you can set on elements that describe how to interact with them. So if we look at the Plus or Add button in Clock, we would set the trait to Button, because it's a button, and VoiceOver would read it as a button to the user.

Next question is: What's my value? So if an element has a state that changes frequently over its life, we would change that or update that with Accessibility Value. So if this time we look at the Clock element, the value that changes would be the time, and so we would return the string 11:20 a.m. and update that accordingly as the time changes.

So the next question is: How should people interact with me? If the traits aren't enough to describe how to interact with an element, where you need just a little bit more information, you can provide that with Accessibility Hint. So if we look at the grabber in World Clock, we could set the hint to something like, drag up or down to change the order. And this is, this describes to the user exactly how they can interact with it, just a short description of how to use it.

And finally: Where am I? You may have noticed that Switch Control and VoiceOver have cursors that move around the screen. So we need to know where to display that cursor. So we answer that with Accessibility Frame. And that's how we draw the beautiful cursor we see here. It's important to remember that the frame is in screen coordinates, so we provide a helper method to convert from view to screen coordinates. Most of the time we assume this to just be the frame of a view, so you won't need to touch this unless you need it to be something a little bit more specific.

And that's it! Those six methods make up the basic API for UI accessibility, and that's enough to get most of accessibility done, so just a few lines of code and a few minutes to make your app really accessible. But the really great news is we do most of the work. So if you use standard controls in UIKit, most of this is done for you.

If you do custom drawing, we need you to answer these questions for us so accessibility users can know how to interact with your app. So just that really small investment of those six methods will give you a large reward of a lot more people being able to use your app. So it's not that much to make something accessible.

So now your convinced: accessibility, just six methods, that's easy, how do I do it? The first step is design for accessibility. So when you are thinking about your app and thinking about how users will use the app you are building, think about Switch Control and VoiceOver users and how they will interact with your app.

But if you have an app already, like we assume most of you do, the best way to start is do an audit of your app and see how accessible it is already, because, like I said, if you use UIKit standard controls, most of this should be done already.

There are a few ways to do an accessibility audit. The first one is the accessibility inspector in the simulator. And you turn that on by going to Settings, General, Accessibility, and turning on the inspector, and you will notice that it brings up this beautiful window that answers those six questions we have been talking about. So you can quickly spot check the elements in your app and make sure they are responding as you expect. The best way to check for accessibility is to use the accessibility features on the device, like VoiceOver and Switch Control.

And I would love to do that with you now. So back in Settings, we can turn on VoiceOver by going to the top of Accessibility Settings, but I would recommend if you are new to VoiceOver to come down to the Accessibility shortcut and turn on VoiceOver, so that way you can tap the Home button three times anywhere in the operating system to turn VoiceOver on and off. So if we go back to the Home screen, I will tap the Home button three times. There is VoiceOver telling us it's on Messages, so I will take one finger and move it around the screen and VoiceOver will read what's under my finger.

weather, clock, map, videos, wallet, stocks, reminders, two tasks due today. Double-tap to open.

I have a few more things to do today. All right. So if I take one finger and swipe right, it will move to the next element.

Stocks, double-tap to open.

Tell me about stocks, and if I take one finger and slide to the left, it will move to the previous element. So double-tap with one finger will activate an element, so it will bring up Reminders. And then the only other gesture that you will need is a three-finger gesture to scroll, so I will take three fingers and scroll to the next, and previous, element, and that's it. Just the few gestures will control VoiceOver and allow you to check your app for accessibility. Let's take a look at Clock and check it for accessibility.

Clock, 9:15 a.m. Double tap to open.

Double tap to open.

Clock, edit, button.

When you are doing an audit, you want to check that everything has an accessibility label, it has a meaningful value. If its state changes, you want to swipe through the elements and make sure that the order makes sense so that it's moving from, generally, top left to bottom right if you are in a left-to-right language and the reverse if you are in a right-to-left. So let's swipe through and listen to what VoiceOver finds in this app.

World clock, heading, Cupertino, today, 9:16 a.m. Swipe up or down to select a custom action, then double-tap to activate.

So VoiceOver is telling us the label and the value.

Selected, world clock, tap.

This has the Selected trait. So that's another trait you can add. It tells us that there is three more elements in the tab bar.

Alarm, tab. Stopwatch, tab. Timer, tab. Four of four.

So I can swipe to everything in World Clock, or at least on this screen, everything has a label, a meaningful value. The traits are set properly. So this looks pretty accessible, that's good. So I will turn off VoiceOver now.

Voiceover off.

Let's look at an app that I brought called QuakeWatch. I'm from the Bay Area, which means I'm obsessed with earthquakes, so I wrote an app that will track earthquakes as they happen in real time around the world. Great for a native like me. So you can see that earthquakes are happening or have happened recently.

And it will tell you where it happened, when it happened, and the text color tells you the magnitude of the earthquake, and we even get a little map view. So if I tap in, I can look at the earthquake on a map, I zoom out. I should be able to find other earthquakes, and I can tap to get more information about the earthquake.

There is even an Info button that will take me to USGS and give me even more information. I can tap and hold on a set of earthquakes to add them to my favorite list and even compare them. Pretty cool app! Best earthquake app I have ever seen. So if I triple-tap with VoiceOver, let's see what the VoiceOver user would see with this app.

VoiceOver on, QuakeWatch, earthquakes, heading.

Earthquakes, heading, so far so good.

Favorites, button.

Favorites, button, that's pretty good. So these are standard UIKit controls, so I get them for free. That's great. Now, I will take my one finger and slide around and see what we find with the cells. [Tapping noise] So that sound you are hearing is VoiceOver telling you that it can't find anything to touch under that finger, so the cells aren't accessible. That's no good. Let's go into the favorites, look at that graph. [Tapping noise]

It looks like the graph isn't accessible either. That's unfortunate, such a beautiful graph. So there is one more gesture that might help you as you are looking at your app, if you do a double tap and hold, VoiceOver will pass through the touch and just push it through to whatever is under your finger. So even though the cell isn't accessible, we can jump in and --

Earthquake, shows more info, detail.

Get to the view.

Detail, earthquakes, back button. Earthquake. Show more info. Use the rotor to access points of interest.

All right. Nice.

Earthquake, location, 74 kilometers, felt by zero people, magnitude 1.50. Dismiss pop up. Double-tap to --

It looks like the Info button isn't accessible, so VoiceOver just doesn't see it. So it's not very accessible to a VoiceOver user. They can't really get to any of the information, so it's mostly useless. Let's turn off VoiceOver.

VoiceOver off.

So what did we find with our accessibility audit? We have got that earthquake cell that just isn't accessible, VoiceOver couldn't see it at all, and the text color is communicating magnitude, which isn't a great way to communicate magnitude because not everyone can see all colors and it's also just really ugly and difficult to read, as you can see with the yellow here. There is that map detail view, where the labels need to be a little more specific about their purpose.

And that Info button is completely invisible to VoiceOver users. So that's no good. But the great news is those six methods we have been talking about so far are enough to fix all of these issues with just a few lines of code in a few minutes. So let's do that together now. All right.

So here is QuakeWatch and the first thing we will look at is that earthquake cell. The earthquake cell is written in Swift and the rest of the p roject is in Objective-C, so accessibility works in both languages and it can coexist just like the rest of your code.

So let's see. It's not accessible. If we look down, we can see that the reason it's not accessible is I'm taking a string and drawing it at a point. So if I used UI labels instead, this would be accessible for me, but because I'm drawing the strings directly into the view, it's not accessible.

And then I'm grabbing the alert color and using that as the text color for all of these strings. So the first thing we should do is get rid of that and instead use UI color black color. Now, we will all be able to read it. Won't that be great?

And now that we aren't using that for the magnitude, let's just keep up with that trend and add a magnitude string that we draw directly to the view. Why not? All right. So that will take care of the text color. How do we make it accessible? If we come up here to where we set the earthquake on the cell, we can grab the date that the earthquake happened, and a handy event description that will tell us where it happened, and format it correctly, obviously. We will set Is Accessibility Element to True on the cell so VoiceOver will be able to find it, and then we will set the label to the description we just built.

Okay. Great! The only other thing we might want to add is a value for that favorite. When you add something to a favorites list, obviously a VoiceOver user would want to know that. Down here where we toggle the favorite, we can add a little bit of code that sets the accessibility value to Favorite if it's a favorite.

So let's take a look at the popover view. I happen to know it's here. So it looks like that button is actually a UI control, which would explain why it's not accessible. If I had used a UI button, this would be accessible from the start, but we need a little bit of help to make it accessible.

So let's do that now. So we will take the More Info button, set Is Accessibility to Yes, add the Button trait, and then we'll set the label to More Info and the hint to Double-Tap To View More Information. And obviously you would want to localize this, but for now we will leave it this way.

The only other thing we want to do here is set the Header trait on the location and felt header, so it's clear what's in that view and what information is being communicated. That was just a few minutes of work, and that should clean up quite a few issues. Let's build and check it out. All right. Let's triple-tap home to turn VoiceOver back on.

VoiceOver on. FaceTime, QuakeWatch, double-tap to open, QuakeWatch, earthquakes, heading.

The first thing you notice is that ugly yellow color is finally gone. Thank goodness! So let's swipe around with one finger and see what happens.

Favorites, button, 12 kilometers, Oklahoma, 2015, 10:57 a.m.

So earthquake finds the cell now. That's good if we come to the detail view.

Dismiss earthquake, location, heading.

Location now has the heading trait, so it's clear what's happening in the view.

12 kilometers. Felt by, heading, zero people. Magnitude 3.00. More info, button. Double-tap to view more information.

The More Info button is now accessible and tells us how to use it and what it will do. Great! Just a few lines of code and we were able to clean up the app and make it pretty accessible.

VoiceOver off.

So where did we get so far? The earthquake cell is now accessible, we are not communicating anything with text color anymore, which is really great, that ugly yellow is finally gone. The map detail view now has meaningful traits on those labels so it's clear to the VoiceOver user what's happening and they can navigate by headings if they like. That Info button it accessible. We still need a way to add something to the favorite list, and the favorite graph is still inaccessible.

How would we make this graph accessible? So let's start by going back to those questions we were talking about earlier. The first one was: Do I serve a purpose? So there is a lot of information being communicated in this graph, but not all of it is really serving a purpose or really important to the user.

So what's the most important bits in this graph? I think that's the points, because they tell us exactly what we are comparing, so that's probably what we should make accessible. The next question that's worth talking about is: Where am I? So what do we set for the accessibility frame for these points?

So you might think that the orange boxes that you see now are a good idea, but if you look at the view as a whole, most of it isn't accessible. So most of it is just dead space, and so as a VoiceOver user slides their finger around the screen to search for points, it will be mostly empty.

A better frame might be something like this. So a VoiceOver user can slide his or her finger across the screen, and they will hit all of the points as they do so. And then as long as we set the accessibility value to the magnitude, we haven't lost anything. We haven't lost any information. So that seems like a good plan.

Unfortunately, I happen to know that the graph view is just one big view, and everything is drawn directly into the view. So how do we make one view accessible into multiple parts? And the good news is we have got an API for that as well, UIAccessibility element. So this is a great way to create specific objects just for accessibility to break up a view into subelements and still answer those great six questions we have been talking about. The only new part is the accessibility container, which you would just set to the containing view.

Great! So with this API, we can make the graph accessible. How do we add something to that favorite list so there is something to display on the graph? For that I think we should use Accessibility Perform Magic Tap, which is this really cool API to just do the right thing in the right context. A good example of that is when a VoiceOver user gets a phone call, they can do the Magic Tap gesture, which is two fingers, double-tap on the screen, and that will do the magic thing, which is answer the phone call.

So that will allow us to add something to the favorite list, but what do we add to the list? And for that we can use some brand-new API in iOS 9 called Accessibility Focus. This will allow you to get the currently focused element for a given assistive technology like VoiceOver or Switch Control.

If you are interested in tracking focus as it moves around your app, we provide a notification that will tell you the currently focused element and the previously focused element for a given assistive technology. We know what to add to the favorites list, we know how to add it, and then we can explore the graph. So let's look at implementing that now.

All right. Back in Xcode. So let's add something to the favorite list. So if we go to the app delegate, we can add Accessibility Perform Magic Tap. So we will grab the currently focused element for VoiceOver, check if that element responds to toggle favorite, like the cell, and if it does, we will ask it to toggle as favorite and then return Yes. Otherwise, we return No, and VoiceOver will do the next-most-magical thing in that context, whatever that may be. So that will allow us to add something to the favorite list. Now, let's look at the graph.

All right. So it looks like I'm drawing it with CAShapeLayer, which is a great way to draw a graph, but not a great way to draw an accessible graph. So down here I'm actually grabbing the point and drawing it. So that seems like a good place to create my UIAccessibility element.

So I create a UIAccessibility element, setting its container to Self, the graph view. And then I set its label to a formatted version of the date. So we know when it happened. We will set the value to the magnitude description. That's good. And then like we talked about, I will take the frame and set it to slightly wider than the point, and the full height of the graph.

I will set that as the frame after converting it to screen coordinates. And finally add that to an array that I had ready, and set that as the accessibility elements for the graph view. So just a few more lines of code. Let's see what that looks like. All right. So I will triple-tap Home and start VoiceOver.

VoiceOver on. FaceTime, QuakeWatch. Double-tap to open. QuakeWatch. Earthquakes, heading.

There's those beautiful cells. I will do the Magic Tap gesture, which is two fingers, double-tap on the screen. And there it is, now it's a favorite.

12 kilometers. California 2015. 11:10 a.m. Favorite.

It says it's a favorite. That's good. So let's add a few more. First, we have to wait for earthquakes to happen. All right. Three should be enough.

Detail, back button.

Let's see what happens when we swipe around the graph.

2005, 2/5, 2015. Pacific Time. Magnitude 0.43.

As I slide my finger across, I should hit all of them. And that's how you make a graphic accessible, an earthquake graph accessible, at least. So just a few lines of code, and we were able to clean all of that up. Let's take one more look, we have the earthquake cell is now accessible, not using yellow anymore, thank goodness.

The map detail is accessible. We can add a favorite using the Magic Tap, and we can even explore the graph and compare earthquakes, our favorite earthquakes, at least. So just a few lines of code, just a few minutes, and we were able to take an app that was completely unusable for VoiceOver users and make it probably the most accessible earthquake tracking app out there.

Remember that accessibility is about users. Thinking about how users of all abilities will interact with your app. Remember everyone that's going to be using your app as you are designing it. Apple has been embracing accessibility for so long that's it's expected of us that we are fully accessible with all of the products and features that we release. And we really strive hard to make that possible. We would like to invite you to join us in that endeavor and make the ecosystem as a whole really accessible.

If you would like more information, you can search for UIAccessibility on developer.apple or check the developer forums. We also have an Apple Watch session later today and an Accessibility and Speech Lab right after that. So you can bring your app, and we will help you make certain parts of your app accessible, or you can just sit with an accessibility expert and go through an audit of your app and see how accessible it is already. So we look forward to seeing everyone there. Thanks, have a great conference. [Applause]