[Applause]

Hi. My name is Qasid Sadiq, and I am on the Apple Accessibility team. Welcome to Accessibility on the Watch. Before we get into that, let's talk a little bit about accessibility. As you know, there are many different kinds of users, and as you can imagine, these users have many different ways of interacting with the world. But for the sake of our conversation, we are going to focus on a certain subset of these users, users, for example, who are visually impaired or hard of hearing.

As developers, these users present us with a very special opportunity. It's something that's unique to us. It's the opportunity to not only accommodate these groups of individuals, but to also really enable and empower them to do things they otherwise might not have been able to do. Now, all of you are here because you guys are creating applications which will allow people to do amazing things.

So let's let everyone do those amazing things, regardless of who they are or how they interact with the world. Now, Apple is committed to this idea, and this is evident through our accessibility features on iOS and OS X, things like VoiceOver, Switch Control, Assistive Touch, Zoom, Guided Access, and so on and so forth. The Apple Watch is no different.

We try our hardest to make this device accessible to as many users as possible. So let's get into that. Now, first we are going to talk about what is accessibility on the Apple Watch, who it's for, how it works, then I want to tell you guys about how you, as developers, can make your WatchKit apps accessible, and you guys will get to see those APIs in action. Finally, we will round it out with a few tips and tricks you should consider when you are designing your accessibility experience.

Let's talk about the accessibility features, starting with VoiceOver. Now, VoiceOver is an alternate interface for blind users. The idea behind it is simple. VoiceOver simply reads out whatever is under the user's finger. So for example, if my finger is on the Clock icon, VoiceOver will read out "clock." Additionally, we provide a set of gestures so it's easy for a VoiceOver user to safely and effectively navigate an interface. I am going to demo this later on. Now, for low-vision users, we have Zoom.

Just like you can imagine, Zoom allows you to zoom into an interface. On top of that, we provide a set of two finger gestures inspired by the iOS zoom gestures and utilize the Crown to really make it seamless and easy to navigate a zoomed interface. I am going to demo that, too, later.

In the same vain as Zoom, there is the X-Large watch face. This provides large, simple, uncluttered readout of the time, so it's easy for a user to pick up their wrist and determine what time it is. Now, the Apple Watch has a compact screen, and although the fonts go a long way in terms of readability, some users may need to increase the text size. For these users, we have the text size slider and settings.

Now, for users with certain light and color sensitivities, there's a Grayscale switch, which filters the UI across the whole Watch to be completely grayscale. This creates a much easier to read and undistracting interface for these particular users. Now, certain users have trouble reading interfaces with blurs on them. Either the contrast isn't high enough or there's distracting blur or artifacts. For these users, we have the Reduce Transparency switch. This removes transparency from screens like Notification Center and Siri so a user can much more easily read what's happening on these screens.

Then there's Reduce Motion. This reduces movement on the screen all around, and where movement is absolutely necessary, makes it directly correlated with the user's action. An example of this is on the transition from the clock face to the Home screen, where instead of zooming in to icons, we simply have it appear. This creates a much more orienting experience for certain users. Finally, users with hearing issues can adjust the left/right balance and set mono-audio on their Bluetooth-paired headsets with their Apple Watch. So let's see these in action.

Okay. So let's start with VoiceOver. You can turn on VoiceOver one of three ways. You can use the Apple Watch app on the iPhone, the Settings app on the Apple Watch, or if you have it assigned in the Apple Watch app, an Accessibility shortcut. This allows you to simply triple-click the Crown to turn VoiceOver on..

VoiceOver on. Weather.

To demonstrate how VoiceOver works, let's try to do something with VoiceOver. Let's try to find out what time it is in New York. Before anything else, we have to get a sense of where we are on screen, and a good way of doing that is by placing your finger on screen and having VoiceOver read out whatever is under your finger. I am going to go ahead and do that.

Calendar. Music. Maps. Alarm.

So now I actually have a sense of where I am on screen. And I want to move through these elements and get to the World Clock app icon so I can open that application. Now, the way a VoiceOver user moves through these elements is by swiping right to move to the next element or by swiping left to move to the previous element. So I am going to go ahead and swipe right until VoiceOver speaks World Clock, indicating that it is focused on the World Clock app icon.

World clock. World clock. Stop -- world Clock.

Now VoiceOver spoke "World Clock." That means I am focused on World Clock. Now to actually open the app I need to activate the element, and to activate the element, I can double-tap anywhere on screen. So let's wait for this to load.

World Clock. World Clock. Back. Cupertino. 1:37 p.m. Today.

Now, I want to find out what time it is in New York, and since this is my Watch, I know that New York is at the bottom of this list, so I can simply scroll to the bottom. The way a VoiceOver user scrolls is by placing two fingers on screen and scrolling in the direction -- or flicking in the direction of the scroll. So I want to go ahead and do that until I get to the bottom.

Rows 4 to 7. Row 6 -- row 7. New York. 4:38 p.m. Today. Plus 3 hours.

Now I know what time it is in New York. So that's VoiceOver. Now let's go ahead and look at Zoom. To first things first, I have to turn VoiceOver off, and I can use my Accessibility shortcut to turn it off by triple-tapping the Crown.

VoiceOver off.

And all the Accessibility settings are in Settings. Accessibility. Zoom. Now, I want to read this text, and it's actually a bit small, so it seems like a good place I can zoom in. So to zoom in with Zoom, you simply two-finger double-tap on screen. Now that I am zoomed in, I actually want to adjust the zoom level a bit. To adjust the zoom level, I simply two-finger double-tap and scroll.

So that's perfect. Now I have to move the zoom focus around so I can actually read this text. Now, I can use a two-finger pan gesture, which is similar to the iOS pan gesture in Zoom to move this around, but there is an issue with this. It's a bit slow, and also my fingers are in the way of what I am trying to read.

Just for this problem, we have actually utilized the Crown to allow you to move the zoom focus around. If I rotate the Crown forward, it takes me from left to right, like so. Once I hit the end of the line, it takes me to the next line. Similarly, if I rotate it backwards, it does the exact reverse of that. There you go. That's Zoom.

Now, as you can see, the Apple Watch is quite an accessible device. But for it to be completely accessible, it needs to have accessible applications. This is where you come in. This is where you really get to be the champions of accessibility and the champions of our VoiceOver users by making your applications accessible. And the way you make your applications accessible is through our WatchKit Accessibility API.

For the most part, this is actually a relatively simple task. It involves setting a couple of properties on a few interface items. Now, each interface item is a subclass of WK Interface Object, and this is exactly where you annotate your accessibility information to make these interface items accessible. You only need these two core functions to make most of your application accessible, so let's go ahead and talk about these, starting with Existence. Before anything else, VoiceOver needs to know what is and what is not an element.

Accessibility elements are those things that you saw me swiping through and touching in my demo. Now, by default, our frameworks give a lot of this to you, things like buttons, labels, and switches are all accessibility elements. But sometimes you might need to get away from the default. For example, if you want to expose an image which is not an accessibility element, that presents valuable information to the user.

Or if you want to group together a few accessibility elements to make it easy for your VoiceOver user to navigate the screen. Like we did here in the Conversation group, where we grouped together those three labels so that a VoiceOver user does not have to swipe three times to get past one Conversation. You can set this by passing a bool into the function set Is Accessibility Element on an interface item.

The way a VoiceOver user sees what's on screen is by hearing a short description of that element. This short description is called an accessibility label. Now, just like Is Accessibility Element, a lot of this is determined for you. Accessibility infers a label by doing things like looking at the text contained inside an interface item, but sometimes that inferred label may be misleading or nonexistent.

An example of that is a Home screen, where each of these app icons are not associated with any text. In these particular situations, you have to set the Aaccessibility label yourself. And the way you do that is by passing a string into the function, et Accessibility Label, on an interface item.

So now these apps will get you 90 percent of the way in terms of making your application accessible -- or these functions, sorry. But to really complete your accessibility experience, you should try to use these three functions too. Let's talk about these. Now, you might remember VoiceOver saying certain things like "button" or "adjustable" or "not enabled." What's actually happening here is that each accessibility element is associated with a set of traits. These traits let VoiceOver know how to present an element to the user.

An example of where we use this was actually on the Conversation group, where we added the button trait so that a VoiceOver knows they can double-tap and activate this element. The way you set traits is by passing a bit mask into the function Set Accessibility Traits on an interface item.

Now, sometimes the label and the traits are not enough to express to the user exactly what an element does. For these particular situations, it might be useful to use an accessibility hint, which is a string spoken out after the label is spoken that lets the user know what they could do when they are focused on an element. You can set an accessibility hint by passing a string into the function Set Accessibility Hint on an interface item. Now, certain elements are associated with a value, which change quite often throughout the lifecycle of that element.

An example of this is the Minute Picker and the Timer app, where that value is the number of minutes that's currently selected. For this particular situation, we have something called an Accessibility Value. This is something that's spoken out after the label is read out or anytime the value changes. You can set this by passing a string into the function Set Accessibility Value on an interface item.

So these are the core accessibility functions. Let's talk about something a little bit more complex, image regions. Now, it's a common pattern on the Watch to take a bunch of information, put that into an image, and present that to a user. An example of this is a weather dial in the Weather app.

We can try to annotate an accessibility label to this, but it would be pretty hard to actually express what's happening in this image with a few concise words. As you can see, there are 11 conditions, each associated with a time, and there's a current temperature. What we really need here is the ability to take the relevant regions, carve them up into separate regions, and associate information with them. So for example, one Condition icon is associated with 1 a.m., partly cloudy.

You can do this through the WK accessibility image region object, where the region is a CGRect frame, and the information is a string label. You can take an array of these objects, pass them into the function Set Accessibility Image Regions on an interface item to present them to a user as a series of accessibility elements that they can swipe through and touch.

Finally, as you are designing your accessibility application user experience, you might come across a situation where you might need to adjust the UI a bit for your VoiceOver users. And to do that, your application needs to know whether VoiceOver is running or not. So for this, we add a new API, WK Accessibility is VoiceOver running.

Let's see this in action. So I created an application which allows you to order a sandwich right off of your wrist, and it's actually pretty straightforward. First thing you do is you actually make your sandwich by selecting the layers that you want on your sandwich. So I want to take some bread, add some roast beef on top of that, maybe I'll have some lettuce, and end it with some more bread.

And I can go back, see a visual representation of my sandwich, and then I can go ahead and order. So we want to see if this application is actually accessible to all of our users, especially our VoiceOver users. And a good way of actually doing that is by actually just turning VoiceOver on and trying the application out. So let's turn VoiceOver on with our Accessibility shortcut.

VoiceOver on. Make sandwich. Button.

Okay. So we have one issue right away. We can see that this image representation of our sandwich, which presents us valuable information in terms of what our sandwich actually is composed of, is completely inaccessible, so we should make this available to our VoiceOver users.

Make sandwich. Order. Button. I button.

Now, although it's obvious to us because we can see this is an information button based on the visual cues, a VoiceOver user will only hear the letter i, and it could be confusing as to what this actually does. We should add an accessibility label to this that speaks information. Also, this button looks a bit small. If you can imagine, it might be a bit difficult for a VoiceOver user to feel around and find this information button. So for this, we should actually make it larger when VoiceOver is running. Let's go ahead and see.

Make sandwich. Make sandwich. Tap what you want in your sandwich. One layer of, roast beef, 210 c. Two layers of. Button.

The first issue is VoiceOver is speaking 210 c, and VoiceOver speaking isn't necessarily limited to the screen space that our interface is. We should make it speak 210 calories. Also, notice we have to swipe it three times to get past one layer. If you can imagine I am really hungry and want to make my sandwich right now, I don't want to have to swipe three times to get past one layer. I have a large sandwich.

We are going to have to fix that by grouping together each layer. Let's go ahead and fix that. So you can actually fix a lot of your accessibility issues just through the Storyboard. So let's go ahead and tackle the Make Sandwich screen first and fix the grouping of the elements in the Make Sandwich screen so a VoiceOver user only has to swipe once per layer. First things first, we have to find the group that contains these three labels. And that's here.

We can go over to the sidebar and set "Accessibility Enabled." This turns it into an accessibility element that a user -- additionally, we should add a button trait to it so a user knows they can double-tap and activate this element. The other issue we had on this screen was the calories label was being spoken "210 c" instead of "210 calories." So let's go to wherever the number of calories are being said, which is right here on the Calories label. Setting text to be the number of calories and c. Let's add a line to Set Accessibility Label here too.

What we are doing here is taking the calories label, calling the function set Accessibility Label on it, and passing in a string, which uses the number of calories followed by the string Calories. So a user will hear "210 calories" instead of "210 c." So we fixed the Make Sandwich screen in terms of accessibility and we want to test our changes. We can build onto the Watch, but that's going to take time to build on the Watch for every iterative change. Instead, let's use the Simulator. I am going to run this on the Simulator.

Now, to test accessibility changes on the Simulator, you have to use Accessibility Inspector, and the way you turn on the Accessibility Inspector is by going to Settings, General, Accessibility, Accessibility Inspector. This is a Simulator-only tool. This allows you to inspect the accessibility of your elements by clicking on them, displaying exactly what is contained inside the element in this red box, and also seeing descriptions of that element, such as label, hint, value, and traits associated with it. So this is awfully useful when you are trying to make an element accessible. So let's go ahead and see if our changes took.

Now with the Accessibility Inspector, clicking only selects an element. To activate an element, you have to double-click. Now, let's click this. So let's notice a few things here. First of all, notice how the whole layer is one element. So now a VoiceOver user only has to swipe once for each layer, so they can make their sandwich quicker and easier. Also, notice how the Calories label now speaks "210 calories, " so it's much more clear to the user what this is actually saying. And finally, it has a button trait, so our user now knows that they can double-tap and activate this element. So we fixed a screen.

Let's go ahead and fix the starting screen where we actually -- the interface controller. Now, the first issue we had here was that sandwich image representation was not accessible at all. And that sandwich image representation actually provided a lot of information to the user. So it's a bit hard to actually try to just add an accessibility label to that image because we want to express what layers are on there and the order of those layers. So this seems like a job for accessibility image regions.

So let's first find out where the sandwich image is set. That's set over here, and the image is generated here. Let's generate the image regions. So I am going to add a function to generate the image regions. What this function is doing is enumerating each layer, creating an accessibility image region, setting the label of that image region to be the name of the layer or the sandwich layer, and setting the frame to be the frame used to generate the original image. Finally, we are adding it to an array and returning that. Let's go ahead and add this to the header so we can call it from the interface controller. And then let's go ahead and call it from the interface controller.

So we are taking the sandwich image, we are calling Set Accessibility Image Regions on it, or the generated image regions. Now, the second issue we had here was that the information button only being spoken as "i." Since the label doesn't change at all throughout the lifecycle of the information button, we can simply set it in the Storyboard. Let's select that information button. Let's go ahead and set the label to be "information." Like so. Okay.

So now we fixed that label. But the other issue we had with the information button was that it wasn't large enough for a VoiceOver user to easily feel on screen. So we need to resize it based on whether VoiceOver is running. So I am going to add a function to do that.

What this is doing is it checks whether VoiceOver is running with a WK Accessibility Is VoiceOver Running call, and if it is, it sets the height and width to be 40. Otherwise it sets it to be 20. Now, we have to call this on Will Activate, so this ... And also, just in case someone turns VoiceOver on while on this screen, we should go ahead and register for the notification and have it call this function. Notification is WK accessibility VoiceOver status changed. Now, let's see our fixed application in action.

Eats. Eats fixed. Eats fixed. Make sandwich. Button.

Right away, we can see that that information button is already larger.

Information button.

And the label is being spoken correctly. So let's go ahead and make our sandwich.

Make sandwich. Button. Tap what you want in your sandwich. Roast beef, 210 calories. Button. One layer of roast beef. Bread, 130 calories. One layer of bread. One layer of roast beef, 210 calories. Button.

Okay. So right away you can see the calories label is being spoken correctly, and that's a lot more clear to the user. Also, each layer is a separate element, making navigation significantly better. Now let's go ahead and look at our image representation of our sandwich and see how accessible that is.

Make sandwich. Roast beef. Image. Bread. Image.

Now, our VoiceOver user can literally swipe through their sandwich. So there you go.

Home. [Applause]

Now, as you guys know, you, as developers, now have the ability to make your own custom clock face Complications. And just like your applications, these need to be accessible too. Now, our frameworks can determine an accessibility label for most complications, but there are a couple situations where that accessibility label may be misrepresentative or nonexistent.

You see, each clock face Complication is composed of a set of image and text providers, and although most of these providers have very obvious accessibility labels associated with them, a couple don't. Image provider and Simple Text provider. So for these two particular providers, we've added a property, Accessibility Label.

This works just like the accessibility label does on a normal WatchKit application, and it's actually pretty easy. So I made a complication to make it really easy for you to order a sandwich, just in case you are really hungry that you don't have time to open the application. You simply want to lift your wrist and get a sandwich right now.

So this is the Complication right here. And since it's an image, it has no accessibility label associated with it. So let's go ahead and actually set an accessibility label on it. So we go to wherever the Complication is created, or the provider is created. And we set an accessibility label. And there you go. It's that easy. So let's see how a VoiceOver user will hear this.

Get sandwich now.

So if you couldn't hear, the label spoke "get a sandwich now," so now our VoiceOver users have the ability to order a sandwich on a double-tap. So as you can see, it's actually really quite easy to make your applications and Complications accessible. Let's talk about a few things you should keep in mind when you are designing your accessibility experience. First of all, try to make your images accessible. Especially if they provide valuable information to the user. You should set an accessibility label on them. Or, if they are providing a very complex set of information, use the accessibility image regions API.

When you design your application, think about how a VoiceOver user is going to navigate your screen. You don't want to make it so a VoiceOver user has to swipe several times to get past one logical item. So group your accessibility elements together by using Set As Accessibility Element.

Now, this is probably true for non-VoiceOver users as well, but you should avoid tiny interface items. It's difficult for a VoiceOver user to feel and find a tiny interface item on screen. Finally, most importantly, try accessibility on your application. See what your application looks like with increased text size. Or, see how your application works with VoiceOver on. You might be surprised at what you find.

In conclusion, the Apple Watch is quite an accessible device. But for it to be completely accessible, it needs to have accessible apps. This is where you guys really get to be the champions of our VoiceOver users. And as you guys just saw, this is actually a pretty easy task.

So let's empower all of our users to do those amazing things that our applications let us do, regardless of who they are or how they are interact with the world. Thank you for your time. You can actually get more information on the WatchKit Programming Guide. You can ask questions on the Developer forums, or contact your Evangelist, Paul Marcos. Thank you for your time. I appreciate it. [Applause]