iPhone • 54:06
Speakers: Chris Fleizach, Eric Seymour
Unlisted on Apple Developer site
Downloads from Apple
Transcript
This transcript has potential transcription errors. We are working on an improved version.
Welcome. What a great day for accessibility. What a great week for accessibility in general, not just at Apple. Welcome to Session 121, iPhone Accessibility. My name is Eric Seymour. I manage the VoiceOver Engineering Team at Apple and I cannot tell you, we cannot tell you how happy we are to be here today to talk to you about this topic.
We get so many requests for adding accessibility features to iPhone and for adding VoiceOver to iPhone. And so it's just a thrill to finally be here on stage to actually be able to show it to you today and show you how to make your applications work really well with it. So we're going to get straight to it.
It's going to come in two parts. First, I'm going to give you a quick overview of iPhone accessibility features for the iPhone 3GS and then I'm going to give you a demonstration And then my colleague Chris Fleizach is going to come on stage and tell you how to make your applications work well with some of these features, with all of these features. OK, so let's get to it. So, perhaps you recall seeing this screenshot during Phil's introduction of iPhone 3GS on Monday. And this is the new accessibility settings panel on the device.
And it showed up in the keynote for a very short period of time but this was marked an incredibly important day for blind users around the world and this is what we suspected before this slide made it into the keynote. That the impact that this has had, that the message of releasing this product on the blindness community is unbelievable. It's been off the charts this week. Really, really incredible. So, I'm going to walk through the features. First, VoiceOver. So, VoiceOver is screen access technology that allows somebody who's blind or visually impaired to use the device.
So effectively, it speaks things that are on the screen. It speaks as a result of user activity. It plays sound effects to help embellish that experience. So it's effectively, it's a spoken interface with some extra sound effects to make it a really rich experience. And so to put VoiceOver into iPhone, there were a couple of important things that we did. VoiceOver, perhaps some of you know is a technology that we have in several products now, most notably on our desktop platform.
So it's a very feature-rich mature screen reading application for users who are visually impaired. And to move that into iPhone, we had to make it iPhone simple. We had to take something that is relatively mature that's based a lot on keyboard activity because of its roots but make it available on a device that has no keyboard for users that have an expectation that it's really approachable, really usable, really fun and we think we've done that. The other thing we needed to do is create an experience where it's safe to touch the device.
So when you can see the screen, you explore with your eyes, you control with touch. But when you can't see the screen, you need to be able to explore with touch safely without pressing buttons or doing things that you didn't intend to do. And then when you're ready to do that, do a few gestures to actually make the phone do interesting things.
And so we've done both of those things. So I'm going to demo that in a few minutes. We've added Zoom. Now this is full screen zoom. This doesn't replace the zoom that exists on the phone. All the zoom features that you know and love, pinching in Safari, and in mail, and in maps, all of that stuff just works. This is a full screen zoom.
It zooms the entire screen up to 500 percent. So because of this, it uses a different gesture set which I'm going to demonstrate quickly in a few minutes. We've added White on Black which for some visually impaired users makes it more comfortable and easier to see the screen.
Mono Audio, so for somebody with a hearing impairment on one side, this sends both channels of audio to both ears. And then what we think of this neat little feature, Speak Auto-text. So, you know these bubbles that appear when you are typing along to suggest a correction or misspelling or to notify of a misspelling, this will actually speak what pops up automatically with text-to-speech synthesis.
And so really good if you're using zoom and that bubble pops up and it's panned off screen but we actually think it's going to be useful for all users just because sometimes even as a sighted user, I myself just stare at the keyboard and I might miss what's popping up.
So it's a nice convenience feature too. And then there's how we turn on these features and this is really important. You can turn it on of course from the phone and the reason that's important is because we want you to try all these features with your app. And so you just drill down to the panel, turn the things on that you want and start moving around and using them with your application to see how well it works.
If you need these features as a user before you can even get into the phone, it's also really important that you can turn it on from iTunes which of course you can do. So when you see your main panel in iTunes for iPhone 3GS, you'll see a button here, Configure Universal Access and that will open a little panel and then you can choose the features that you want to turn on, click OK and suddenly they're enabled in your phone.
Your phone will start talking or you'll have zoom features or any of the others. So, I am going to give you a demo of the phone. Alright, so here's a phone and I'm going to turn it on. Let's go in. We'll go to Settings and we'll go to General. And here is our new button.
See the Accessibility button here, I'm going to press it. And here are the new features in our panel. I'm going to spend a few moments on Zoom and then I'm going to spend time on VoiceOver. So let's go into Zoom first. We'll just turn it on. So, Zoom, full screen zoom, uses a three-finger gesture. Basically I take three fingers. Double tap to zoom in, double tap to zoom out. And when I'm in, I can move around.
I can trough as one would expect. I can increase zoom by double tap and push up and push down like so. Let's go somewhere else. So, I go to Notes and if I'm doing a control which requires panning, it automatically will pan with me as I move around the screen. So that's it. It's really simple. And so that's Zoom.
And now I will go to Accessibility and turn Zoom off and we'll go to VoiceOver. Alright, so here's VoiceOver.
So already VoiceOver is speaking to me and it's speaking descriptions of the screen and I'm just going to go Home.
Messages.
Now remember how I talked about having the ability to touch anything on the screen and be in a safe environment, so that I'm not actually doing anything yet. I'm just exploring. So here are the ways that you explore with VoiceOver. I can just touch the screen.
Photos, Calculator, Notes, Voice Memos.
I can drag around the screen.
And you'll notice you hear this ticking sounds and that tells me when I'm crossing a boundary. So right away if I can't see the screen.
Screen curve none.
You can see how important that becomes. I'm going to turn it back on for demo purposes. Now you also might notice this black and white box that's around, around the Weather icon right now and that's the VoiceOver cursor and that's the last thing that's spoken. It's the thing that's selected and as I move my finger--
Clock, Notes, Voice Memos.
And this assures that I can get to every element on the screen. So if the screen is really dense with elements and I can't quite get my finger on the one I want, I can get near it and then I can flick left or right.
Settings, iTunes.
9:07 a.m., status power 85 percent battery power. Status 9:07 a.m. 100 percent WiFi signal. 9:08 a.m. Clock.
So I can get the things and then I can move around within them very, very easily. OK, so the next thing I might want to do of course is interact with something and the way I would do that, the most common way is to just do a simple double tap and what's nice about this is I don't have to double tap on the phone icon here for example.
Trust that I could make a phone call if I wanted to. Let's look at a few other things. So, we've made every application that Apple produces and ships on iPhone 3GS accessible. And I obviously can't show them all here. So I'm just going to show a couple. I'm going to go to Stocks.
So, automatically and this happens on a lot of screens, it will read summary information for me right when I go into the screen. It gives me what I want to know usually very quickly. And then I can move around here same way.
Now the other important thing that I want to point out is that we've really tried to uncover and do a complete job, uncover all the nooks and crannies of the user interface and go to great detail to make it accessible. So for example, even the graph works.
And this is important because we know that there are so many graphical aspects to iPhone applications especially in your applications and we've provided API which we think will help you do this with minimal effort.
So Chris is going to be talking about that in a little while. Let's go out of here and, so another very important application to users, especially visually impaired users, well all users, but important that we get it right, is web browsing.
Safari, Apple Link.
And I'm happy to say that what iPhone gave us with Touch provides probably the most realistic web browsing experience of any screen reader to date and that's because I can simply touch anywhere on the screen.
I can basically touch anywhere on the screen and now I instantly know the layout. Now this is important because on any other screen reading application for example, on a desktop I just have a keyboard and so I'm moving between elements. Now I can actually touch the screen. I know it's there, I know what the graphic designers had in mind.
So it's really, really-- it's really fan-- it's actually profound for users of this technology. And of course I can find anything.
The new iPhone 3GS includes a screen reader. The new iPhone 3GS includes a screen reader, full screen magnification and other new accessibility features. Learn more, Link. Mac OS X Snow Leopard disk.
[ Simultaneous Talking ]
Mac OS X Snow Leopard.
And I can pause speaking by just doing a tap with two fingers. So expert screen reader users expects in their web browsing experience the ability to jump around to find elements very, very quickly and we really wanted to bring this to iPhone but the challenge was how do we do that and keep the gesture set simple so that there's not a lot to learn and it's really intuitive and we think we've come up with a good way to do that. So for example, I might want to jump between all the headers in the document or all the links or all the images so that I don't have to wade through the other stuff.
And what we've come up with is a concept called the rotor and the rotor is like turning a dial on the iPod, or excuse me, on the iPhone.
And there's headers.
So really, really, really powerful web browsing capabilities. Alright, so, of course iPhone is also a great iPod.
iPod.
Big Whisky and the Groogrux King. iTunes Pass, Big Whisky and-- Lying in the Hands of God. [Background music] Dave Matthews' Band, Lying in the Hands of God.
[ Inaudible Remark ]
So of course iPod is fully accessible, everything is fully accessible, but there are a couple of nice things I want to point out here. First is you may have noticed I paused music without pressing an actual tangible button on the screen and we determined that sometimes you want to do something on the phone where you don't really want to fumble like pausing and playing music, like answering and hanging up a phone call or ending a phone call, like pausing and playing video and so we've invented this two finger double tap kind of does the right thing and so for example since I was just playing music. [Music] I can pause and play that music really, really easily from anywhere.
The other thing you might notice, actually I'm going to ask you to notice in a second is that we do really great ducking and this improves the experience when your listening to text to speech so much when you're using your iPod.
[ Music ]
[ Voice Over ]
Now you might be asking the question how does this work with my application that we're producing, does this only work with Apple stuff. And so like our other accessibility technologies on other platforms we have full accessibility API that we've designed and we have gone to great lengths to burn it into all of the UIKit controls so that it's there for you and in a lot of cases just works automatically. And so to illustrate that I'm just going to go into an application that's from the App Store.
I'm going to go into Urban Spoon.
Now Urban Spoon, like all of you, had no idea about any of these features until this week, so this is stock right down from the App Store, no changes, no accessibility in mind and here's how well it works.
...Indonesian, Indian-- Indian, dollar sign, dollar sign, dollar sign, dollar sign, picker item adjustable.
For example, we were able to pick out those dollar signs and speak them. This is Urban Spoon's opportunity for example to say well we really want to say high roller or low roller or some other thing that reflects how they want to articulate what that dollar sign value means, and so we provide tools to do that and Chris is going to talk about those in a couple of minutes and so let's do a Shake for the fun of it.
[ Noise ]
[ Voice Over ]
I mean really actually even-- even I was astounded by how accessible it is just right off the shelf and so we're hoping that-- we think that you're going to experience the same thing and then for the few things you can embellish, it will make a really fantastic experience for our users.
Alright, so I just want to end on one thing and I'm going to go into Settings. So some of you might be wondering [background voice over] how does this work for international customers. So I'm going to show you. We're going to go International. Francais. Deutsch. Italiano. English
VoiceOver is localized for all of them, totally works. [Applause] So with that, I'd like to invite my colleague Chris on stage to tell you how to make it all work in your applications.
[ Applause ]
Thanks Eric. That is a great demo. So as you've seen we've done a lot of work to make all the Apple apps accessible out of the box.
Now I'm going to talk about how to make your app accessible and we've spent a lot of effort to make this as easy as possible. We don't want to make it an onerous or burdensome task and I think you'll find that we've done just that. So the UIAccessibility API is new for iPhone 3.0 and it allows your app to provide information about the elements on the screen to an assistive application like VoiceOver. So before I dive in to the protocol, and we start looking at the details, let me just give you a quick overview of how accessibility works on the phone.
We have VoiceOver which runs in the background and your app. Now your app might have a button like Start and VoiceOver would like to get some information about that. So using the UIAccessibility protocol, VoiceOver will ask your app for the button at this position. Your app then says this button is at this position, it turns that information to VoiceOver and then VoiceOver is able to get the text and say start.
So the first thing to know about iPhone Accessibility API is that it's simple and if you use UIKit for most of your controls, a large amount of the work is already done for you. In fact most apps you only really need to provide a few labels for some elements that appear as images or maybe need a little bit more descriptive information about them. So let's look at the API. The Attributes API has six things and that's it.
Most of them you won't even need to use, so I won't go through all of them here. We'll go through the common ones and then we'll look at some of the ones that you won't need to use as often. So the most common attributes you'll need to implement are-- is accessibilityElement which is a Boolean that determines if this object is accessible and that means it's visible to VoiceOver. So importantly, this means that this object and traditionally it's a UIView that it does not have anymore information below it in any subviews and its superview does not return any information. So this UIView is sort of the end of the line.
This is the thing that's going to give you all the information; accessibilityLabel is the textual representation for this element and Start button that we saw before, accessibilityLabel would be the start and that's an NSString, so pretty simple. With just those two things you're going to get 85 percent of the way there for your app.
Another common attribute that you may or may not need to change are accessibilityTraits and traits are a new concept for the iPhone 3.0 SDK, a little bit different from the desktop accessibility.
And these are a set of traits that you OR together and they help define the status, the type and state for the element. Now, UIKit controls has already returned the appropriate traits and other information for a variety of states.
So that means if you need to return more trait information, you should OR that with super so you get everything UIKit already throws in there. So let's look a little bit about the traits and see an example. So I have all the traits listed here. We have things like button, link, whether it is a keyboard key, whether it is an image, these are all well documented.
There are some documents available already for UIAccessibility protocols, so I'm not going to go through all of these, but let's take a little look about where traits would fit in on a screen like this. So obviously we have a button up in the top where we have a button.
The picture would be labeled as an image as that's what it is and on the bottom, we have something where the trait would say it is not enabled because that icon is dimmed out and if you press it, nothing will happen in that case. So, we'll look a little bit more traits in the demo and see how we can use them to make our app more accessible. So the other accessibility attributes are there, you may need to use them, but most likely if your app is a standard UIKit based app, you won't need to look at these. The accessibilityFrame is the onscreen rectangle for the UIElement.
If you're using UIViews, that's done automatically for you, so you never need to change accessibilityFrame for anything that's a UIView. The accessibilityHint is a way for you to give a little bit more information about what happens when an element is pressed. So we'll go into that but you can think of this as just informing the user if the case is not really clear what will happen when you press it.
accessibilityValue is a way to return some textual information that is different from the label and more dynamic. So the easiest way to think about this is a slider, so you might have something where the slider is a volume slider. In that case, the accessibilityLabel would be volume, but the accessibility value would be 75 percent so that allows us to distinguish between the two. So, how do we add accessibility? It's really, really easy. We are going to go through the easiest ways first.
So, simple information can be added through Interface Builder and in 3.0 SDK, you'll see there is this new pane in the Interface Builder that allows you to change some accessibility information. So the other picture on this screen is from the demo that we're going to use. It's just a UIView, a window with a bunch of different UIViews. The blue UIView is selected in this case and we see that some of the information is already filled in. One that it's enabled.
Two that it is not an accessibilityElement. So, what are the fields in this pane? We can determine if accessibility is on or off for an element. That is the accessibility flag and that tells us if this UIView will return information to VoiceOver. There is the accessibility label which we can change, the accessibility hint we can change and traits, which you can select and you don't need to crazy with the traits just because there are check boxes that you can check. You only want to pick the ones that are most appropriate for this element.
So once you've added accessibility information to your app, you're going to want to test it and Eric showed how you can test it with VoiceOver, but when you're in the mode, you're in the zone, and you don't want to sync your app over to your phone and turn on the VoiceOver, we've added an Accessibility Inspector to the simulator.
So in the simulator and this is not just for iPhone 3GS, this is in the SDK, in Settings and then in General, there is now an Accessibility tab. When you go there, there is an Accessibility Inspector that you can turn on and you get this little floating window.
You can move this around so that you can click on things and this Accessibility Inspector works a lot like VoiceOver. So, you click once to select something. That gives you information about it, then you double-click to activate it. You can also minimize this window by clicking that little Close button and then you can use the simulator like you normally do and just click to activate things once. Alright, so now I'm going to show you a demo and we're going to start to look at how to make your app accessible.
Alright, so here is the app that we're going to make accessible. Let me just run through this and we can get a feel for what it does. So I have a formula and as I change values, it just sort of redraws a graph in different values. I can type something in here and that will also change the graph.
I can click here and then that sort of gives me values for different portions of the graph. I have a Table button which brings in this view and shows me lots of buttons and I have this thing which will start animating the graph automatically. Now the first thing you're thinking is how can I get this app, I need this right now? Well, it should be available to you as a developer sample. If not yet, hopefully very soon and then once you get that app you're going to wonder how accessible is this.
So let's go and turn on the Accessibility Inspector and we'll go to the-- Here, now it's on. So I can click things and it tells me information about them such as the label in the frame. Here this tells me the label is general, the trait is a button, and it also tells me the frame. So let's go home. So now, notice that the app is on the other screen.
If I just try to switch over, it's not going to work, so I'm going to minimize this and then switch over. I'll open up my app and now we can start examining things. So, I can click up here. Here is a label. It tells me that information automatically at static text. Here's a text field with the value, but notice it does not have any label, so if I went to this, it would just say 0.15.
Slider, same type of thing, I only have a value, no label. Down here at this button, it just says button, it doesn't tell me what it does. Same with this thing over here, it's another button, and here this doesn't tell me what it does. It just says visit our webpage but we don't know if it is a button or a link or whatever. The graph is also a black box to us because it's rather dynamic. This is not a standard UIKit control and we're going to look at how to make that accessible in a few minutes.
OK, so let's go to Xcode and alright, I'll just open up the Xcode project again and we'll open up our Interface Builder first and we'll see what we can do. So, the first thing we get to is this text field and let's add a label to this. We can call this Alpha, so we know that's Alpha. Now here's something I want to do.
I have this little label that says Alpha equals right next to the text box, but the text field also says Alpha and I don't want to make my app overly complicated with lots of little labels all over the place, so in this case, I can just turn off accessibility for this UI label so that it doesn't have to show up and so the user can get all the information right in the text field. The slider also doesn't have a label, so I can add that, something like Alpha. How about these buttons, no labels again, so for these ones we can do something like show table and this one also, there's no label so we'll say start animating.
Finally, we have this UIView. Notice that it's not enabled with accessibility, so before we go into any big detail about how to make this graph accessible and all that stuff, let's just see if we can make it show up. So, we'll say it's enabled and we'll say it's graph for now and we'll save that. We'll run it and we'll see what happens. Alright, so I click there and all of a sudden the label says Alpha. Alright, so things are working. I can no longer click on my Alpha here because we've made that not accessible.
My slider says Alpha. My graph now just says graph, so that's good, it now appears. I have a Show Table button and a Start Animating button. Alright, so with just a few simple things in Interface Builder, we've made this app a lot more accessible. All of a sudden, a VoiceOver user will know what these buttons do and what's going on in the screen. So, there's a few more things we can do in Interface Builder with some of the traits.
So, let's go back and go back to Interface Builder and see what traits we can use to change this. So here's an easy one. Visit our webpage. Now this would open up a webpage in Safari that the user would browse to. So in that case we should say this thing is a link because it opens up and opens up in Safari. Alright. So, another thing we noticed, you may have noticed, is that when I press this button, it plays a sound and there's also a trait that says play sound.
This is not a normal kind of trait that you think would be important but when a VoiceOver user presses a button and activates it, VoiceOver automatically plays a sound and that's so the VoiceOver user knows what they've just done. So if you play a sound and VoiceOver plays a sound all kind of shenanigans break loose. So you don't want to both play a sound at the same time and you can do that by saying this plays a sound.
VoiceOver, you don't need to play a sound. Finally, we have this graph here. All we've done is just mail this one in and we'll say it's a graph but we can also say it's an image so that the VoiceOver user doesn't get confused-- Is this a control, what am I supposed to do with this graph? We can just save some image for now.
So save that, run it again and see if our changes took place. So here we have a link and it says play sound. It looks like I chose the wrong one but you get the idea. That link may also play a sound. I didn't click on it for all you know. Here the graph, it's-- it now has a trait as an image. So that's good. So with just a few clicks in the check boxes we didn't go crazy.
We've added a lot of accessibility to our app. Alright. So that will get you at least 85 percent of the way there for accessibility for your app. It was that easy. So we also have ways to add accessibilities to UIViews that are created programmatically or anything that you need to do in the code.
And that can be done either through setting accessibility attributes or by overriding the accessibility methods in an instance. So let's look at how that works. So, all of the accessibility attribute methods have setters with them. And if you have an object that doesn't change its label overtime, it's just there on the screen and it has something static like in this example we have a UIControl that would be a Play button. You can set it right when you instantiate the object. So here what we've done is we say setIsAccessibilityElement:YES. That means VoiceOver can see this and we say setAccessibilityLabel to play and we're done. Ship it. But there are some other cases that are a little bit more tricky.
You might have a UIView that's label changes overtime. So you might think as something like a MyTemperatureView and in this UIView it would get some data from somewhere and display temperature. So to make this accessible, we'll first override isAccessibilityElement. Return yes for that. We'll override accessibilityLabel to use some data model that we have.
In this case I have something called cityWeather and that can return me the current temperature string. So that can be returned to the accessibilityLabel and be updated whenever the data model changes. I also have some accessibilityTraits here and I've added a new one and that's the UIAccessibilityTraitSummaryElement. So this trait allows you to choose one element in your app that when your app starts, VoiceOver will find and use the information from it to give an overview of that. So if this is some sort of weather app, VoiceOver would start the app and it would say, "Application name, 75 degrees Fahrenheit." So without doing anything, the VoiceOver user will get an overview of the most important information your app has to offer.
Now you don't need to add this to your app. Not every app has a summary element that you want to define but you may have something that requires that. I noticed I also OR'd with super. So I can get what other traits come through UIKit for free. So with those accessibility attribute methods, we're able to adorn our UIViews and Elements with almost all the information VoiceOver needs to operate.
There are also a few cases though that VoiceOver needs to know when something has changed on the screen. And we can use notifications to tell VoiceOver when something has happened. We have two notifications, one is screen changed, one is layout changed. The screen change is when a whole new screen comes in, maybe it slides in from the bottom, all the elements are different. In this example if I press the Bookmarks button I'll get a screen that looks like this and I want to post a notification that says, UIAccessibilityPostNotification (UIAccessibilityNotificationScreenChanged).
Now that's a lot to type but don't worry if you use autocomplete it's not that bad. So layout change is a little bit different and that will be something more like if I press the Edit button. Now when I press the Edit button, I get a few new elements in the screen but generally it's the same screen. So to inform VoiceOver of this change, I can post a layout change notification instead. Alright, so let's look at how we can do this in the code.
So I'm going to go back to Xcode and we'll see what we can do. So, there's a few things we're going to do to make this even better experience. I'm going to tell what they are because you don't know yet. And some of the things we missed out on were hints. We didn't add any hints. We didn't have-- we've had some few elements that sort of change their behavior overtime. So the first thing I want to do is change the Stopwatch button.
And the Stopwatch button, what it did when you pressed it on it started animating but when you pressed it again it stopped animating. So in that case the label sort of changes when it goes from start to stop. So I can also update my label when that happens and I'm going to find out the right place.
And Stopwatch button was pressed. And here we're going to change the label to be something a little bit more accurate. So I'll say Stopwatch set accessibilityLabel and here is a state where it is changed from on to off and if it's now off, pressing it again will start animating. Likewise if I go from off to on pressing it again will stop animating. So now I can change my label a little bit more dynamically based on updating conditions in the app.
Now the Stopwatch is a little bit of a strange creature. I'm really not sure what it does. It can start animating, stop animating but we can also add a hint for this and I might want to that in viewDidLoad and then I can say Stopwatch set accessibilityHint and I'll just toggles animation.
So the user gets a little bit more context of what was going on. So our GraphView right now, all we did was make an accessibilityElement and we said that this was a graph. That's all we had. We can add a little bit more information to that. We can tell it it's a graph when the Alpha value equals whatever it equals.
So that won't be too hard. We're going to override accessibilityLabel in the graphing view to do that. So I'm going to copy some code and pastes that. So now my accessibilityLabel will return a string with format that says graph with Alpha of and then it paste in the right Alpha.
So that will give a little bit more context to a VoiceOver user. The last thing I want to show is posting a notification. So we do have a case where a new screen comes in. When I press this Table button, we get a whole new screen that slides in and then also one that goes away. So we can-- here we want to post a notification and I'll do that and Table button was pressed.
And right at the end, I can say UIAccessibilityPostNotification UI accessibility screen change notification and we don't need an argument. So it's much easier when I have autocomplete. Alright, so let's run it and see what Accessibility Inspector tells us happened. So if I click on the graph, all of a sudden it says graph with Alpha of 0.15.
If I change the slider and look at it again, it says graph of Alpha with a new value. So we've added a little bit more dynamicism to our app with just a little bit of code. Let's check out this button over here. The label says start animating and it gives me a hint which says toggles animation.
If I press it, now the label says stop animating. So the VoiceOver user would know that if I press this now it will stop animating.
So that's pretty good. If I show this table, nothing happens now because only VoiceOver listens to those notifications but rest assured the right thing will happen.
Alright, so there it was, setting accessibility attributes. That's all you need to know to adorn your UIViews with the right accessibility information to give users the best experience they can. So that will probably cover 95 percent of all the cases for accessibility that you'll need to do in your app and we hope this will be a really easy experience and something that won't be onerous or burden. It may even be fun when you can play around and try it out with VoiceOver.
Now, we haven't talked about some other cases that you might have been wondering about, that is namely, how do we make the graph accessible? This looks like one UIView that draws a bar line and is a little bit more complicated than some of the UIViews we've seen so far. So we have a protocol called the Accessibility Container protocol that allows a UIView with separate subelements to return information about those subelements.
So in this case we have one subelement that told us something about January 1st and right next to it we have another subelement that told us something about another date. So to implement the Accessibility Container protocol, a UIView no longer is an accessibilityElement because its self doesn't return accessibility information but it instead implements this three methods, accessibilityElementCount, returns the number of elements this UIView has. accessibilityElementAtIndex which is just the element from zero to the count and indexOfAccessibilityElement which gives you the location in the list of this element. So sort of like an array function that you can call and get the right element that you want.
So to make this as easy as possible, you can wrap up all this accessibility information in an instance of UIAccessibilityElement which is a new class in UIKit that you can create and it's made so that you can stick what you need to into this object and return it. So let's see a little bit how this works. We have a object that you want to return information for and we have a UIAccessibilityElement and what you want to do is first, initWithAccessibilityContainer and the Accessibility Container is the UIView that contains it, obviously.
In this case we'll call it the stockGraphView. Then we stick the right information into it like the accessibilityLabel, in this case it will be January 1st and so on and we can do that by saying chartPart.accessibilityLabel = this and then we need to set the accessibilityFrame Remember this is the onscreen rectangle that defines where this object is and it is important to set it for this element because it's not a UIView.
UIKit doesn't know where this object actually is onscreen. So you can do that by setting the accessibilityFrame with the rectangle and then finally you want to add this to a list of children that you can keep around in reference. So at this point, I'm just going to show you some of the Accessibility Container protocol and we'll see how that works.
[ Pause ]
So what are we going to make happen with the Accessibility Container protocol? Well we have this graph and it's a UIView and it draws some stuff and it also has these strange buttons here which don't like buttons but I can click on them. They don't look like buttons because they're just NSStrings drawn at a point. Now, I want to take those NSStrings and return accessibility information for them.
Send them back through accessibility so that VoiceOver can get to them and now they can press on them because right now if VoiceOver went to this, all it would be able to do is just touch on this graph. Alright. So to do that we're going to go to graphing view. We no longer need this accessibilityLabel so I'll just remove it because the graphing view no longer returns information about accessibility.
It returns children that have accessibility information and the first thing I'm going to do is paste in the outline of what we want for the container protocol. So we have an isAccessibilityElement that will be no because that's not an accessibilityElement. We have accessibilityElementCount which is the number of children it has.
The ElementAtIndex which is the element at that index and the index of this object and notice how I've done this, I just referenced a function that we haven't yet defined that will return an array and give me the right information so I can call normal array methods to do most of the work.
I can call count on it object at index and index of object. So now we have the outline of this. We want to define this accessibility children method which will make the right children for us. So I'm going to copy this in and paste it in. So what I have here will return the array only if the array and it will only make the array if it has not been made already. You don't want to remake your accessibilityElements over and over again.
That's expensive and wasteful and VoiceOver will get confused. So you can make an array, keep it around and then just return that array. So my accessibility children is a ivar for the class. We instance with it NSMutableArray and then we return it. So the next question is, how do we make the UIAccessibilityElements and have some code. It's quite a lot that I'm going to paste in but it's not complicated.
A lot of it is just duplicated over and over again. So for my first element, I have a graph element and that will sort of represent the picture of the graph at this point. So I make this element, I initWithAccessibilityContainer self cause self is a container for it. I set the accessibilityLabel to graph at this point. We can do more later if we wanted to. I set the accessibilityTraits to the trait image. You know what, I don't have to OR it with super here because super is just accessibilityElement.
It's not, there's nothing else behind it that gives us information and then I add that object to my list of children. So I add this object first so that VoiceOver will reach it first. Eric demoed where you can flick with your finger to get through the elements in order. Well the order is determined by things like this. So I put the graph first so that the VoiceOver user gets to this object first.
Now, we want to make accessibilityElements for each button. So I have similar type of code, I have button 1, I initWithAccessibilityContainer self and then I set that label for this. And what is the label? Well if you remember, it's something like F of negative pi over 2 and F of 0 and F of pi over 2. So I'll just set that as the accessibilityLabel, F of negative pi over 2.
I'll give this a button trait because that's what we want it to behave like and add it to my list of children. I then do the same thing for button 2 and for button 3. Alright, so we got those buttons made, we stuck them in the array. We're almost there except for one more thing, we have to set the frame so that VoiceOver knows where on screen to find these things.
So once again I will paste a large amount of code in and how I'm going to find this frame is I'm going to use my accessibilityFrame to base my calculations off of it. So we have this graphing view and it's a UIView. We know where it exists on screen and we can find out where it exists on screen by saying self accessibilityFrame and then use that information to set my buttons' frames to the various things.
So I'll set my height and width to something static that I found is appropriate then button 1 accessibilityFrame starts somewhere close to the left side and starts somewhere down on the bottom as width and height. Button 2 starts over in the middle. Button 3 starts over at the end. So I do all that and I just found this by trial and error. I'm sure you can think of more creative ways to do this. Finally, I have the graph accessibilityFrame which starts at the top and then goes down to the buttons.
Alright, so we have all this accessibility information. We'll run it and we'll see what happens. So now when I click here, notice it's only selecting part of the graph. That's because we have an accessibilityElement just for that graph. Notice it also says graph and it's an image just like we said. I can now click her on these buttons.
Here is F of negative pi over 2, F of 0, and F of pi over 2 and as a VoiceOver user I can now click on them and then go here and get the information that a sighted user also gets and I can do that for all the buttons.
So we've taken what was a very custom UIView, one that drew a graph and took NSStrings and drew them at points and we've changed them into the necessary information so that VoiceOver users could get to them. Now, you might think what about the graph? Can we do a better job? I'll leave that as an exercise to the reader.
So that's the Accessibility Container protocol and that is the Accessibility API. That's all there is to it. You can make all your apps accessible using just this API just like we've done with all the Apple internal apps. As you've seen most of the work is already done for you so you probably won't even have to do some of the complicated stuff we did at the end.
Now, there's a few good ideas that you should keep in mind when you're crafting your labels and other information for VoiceOver users. Be concise and short with your labels. Don't be overly expressive and say this button adds a city to the table view. That might be very nice and loquacious but what the user really wants is something short and concise that will get them to do what they want to do.
So say "add city" instead. Don't include the type of information in the label. So you don't need to say "remove city button" because the button is part of the traits, instead just say remove city. Otherwise, the VoiceOver user will hear remove city button button and that's not good for anybody. If you have a hint, there's a few things to remember. First, you don't always need a hint.
When you do need a hint, it's because when you perform an action on this object the result is not obvious based on its context. So a good example I like to think of is in iTunes Store, there's table rows and if you touch on a table row it plays a preview of the song.
So a good hint for that would be "plays a preview." A bad hint will be "pressing here will play a preview of the current song." One because it's not very concise, obviously it will play a preview of the current song that's why you're on it and you also, it's bad because it's defined as "pressing here" and you don't want to tell the VoiceOver user how they will interact with this object because maybe they don't press here maybe they swipe or maybe they do some other gesture.
So instead just give a short overview of what will happen when this object is activated. So to wrap up, accessibility expands this iPhone community that has grown so large to include as many people as possible. Your apps, just like being an important part of the iPhone story, are going to be an important part of the accessibility story.
Already people are talking, will other apps be accessible and it's up to you now to make sure they are. We've shown you that it's not easy, burdensome or hard to do this. So hopefully by at this point through the talk all your apps actually are accessible and you're uploading them to the App Store right now.
I'll be a little bit disappointed if they're not. Once you've done that, make sure to test with Inspector and once you get your new 3GS phone, test it with VoiceOver. I think it'll be pretty fun to see what your app sounds like to someone who can't see and if you're really brave you can close your eyes and see if you can use your app without seeing what's going on. Here's the requisite information about more information. You'll find there's a VoiceOver Manual, there is UIAccessibility programming documents. Hopefully, this example app will be available and all of this will be on the website shortly, if not there now.