iOS has transformed the lives of many users with a range of physical and learning disabilities. Learn how to create apps that leverage the power and simplicity of Apple's assistive technologies to make them accessible to the broadest audience possible. Hear about the latest advancements in iOS accessibility and how you can take advantage of them today.
IAN FISCH: 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
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:
IAN FISCH: 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.
VOICEOVER: weather, clock, map, videos, wallet, stocks,
reminders, two tasks due today.
Double-tap to open.
IAN FISCH: I have a few more things to do today.
So if I take one finger and swipe right,
it will move to the next element.
VOICEOVER: Stocks, double-tap to open.
IAN FISCH: 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.
VOICEOVER: Clock, 9:15 a.m. Double tap to open.
IAN FISCH: Double tap to open.
VOICEOVER: Clock, edit, button.
IAN FISCH: 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.
VOICEOVER: World clock, heading, Cupertino, today,
9:16 a.m. Swipe up or down to select a custom action,
then double-tap to activate.
IAN FISCH: So VoiceOver is telling us the label
and the value.
VOICEOVER: Selected, world clock, tap.
IAN FISCH: 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.
VOICEOVER: Alarm, tab.
Four of four.
IAN FISCH: 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: Voiceover off.
IAN FISCH: 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: VoiceOver on,
QuakeWatch, earthquakes, heading.
IAN FISCH: Earthquakes, heading, so far so good.
VOICEOVER: Favorites, button.
IAN FISCH: Favorites, button, that's pretty good.
So these are standard UIKit controls,
so I get them for free.
Now, I will take my one finger and slide around
and see what we find with the cells.
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.
IAN FISCH: 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 --
VOICEOVER: Earthquake, shows more info, detail.
IAN FISCH: Get to the view.
VOICEOVER: Detail, earthquakes, back button.
Show more info.
Use the rotor to access points of interest.
IAN FISCH: All right.
VOICEOVER: Earthquake, location, 74 kilometers,
felt by zero people, magnitude 1.50.
Dismiss pop up.
Double-tap to --
IAN FISCH: 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: VoiceOver off.
IAN FISCH: 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.
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.
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
That was just a few minutes of work, and that should clean
up quite a few issues.
Let's build and check it out.
Let's triple-tap home to turn VoiceOver back on.
VOICEOVER: VoiceOver on.
FaceTime, QuakeWatch, double-tap to open,
QuakeWatch, earthquakes, heading.
IAN FISCH: The first thing you notice is
that ugly yellow color is finally gone.
So let's swipe around with one finger and see what happens.
VOICEOVER: Favorites, button, 12 kilometers,
Oklahoma, 2015, 10:57 a.m.
IAN FISCH: So earthquake finds the cell now.
That's good if we come to the detail view.
VOICEOVER: Dismiss earthquake, location, heading.
IAN FISCH: Location now has the heading trait,
so it's clear what's happening in the view.
VOICEOVER: 12 kilometers.
Felt by, heading, zero people.
More info, button.
Double-tap to view more information.
IAN FISCH: 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: VoiceOver off.
IAN FISCH: 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,
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
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.
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.
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.
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.
So I will triple-tap Home and start VoiceOver.
VOICEOVER: VoiceOver on.
Double-tap to open.
IAN FISCH: 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.
VOICEOVER: 12 kilometers.
11:10 a.m. Favorite.
IAN FISCH: It says it's a favorite.
So let's add a few more.
First, we have to wait for earthquakes to happen.
Three should be enough.
VOICEOVER: Detail, back button.
IAN FISCH: Let's see what happens
when we swipe around the graph.
IAN FISCH: 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.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.