Hello Chris McMeeking with Deque here, and I'm talking to you today about
accessibility testing for developers. A new process that I've seen in iOS 13
that makes accessibility testing much easier for developers. We need to do
accessibility testing, it has to happen. but it doesn't have to be difficult. So
accessibility testing is important we wanted accessibility test early and
often accessibility defects represent risk to
an organization. The earlier a defect is caught the cheaper it is to fix. We do
not want defects working their way too far down the process, it takes and involves
more individuals and takes developers farther away from the line of code that
they are fixing when they need to fix it. Every time a developer has to go back
reintegrate into that codebase it's expensive for them and the nice thing
about this is we don't have to be perfect to be effective. Every bug that
we catch earlier in that process saves us money. Development is hard, a developer
should want to maximize their time actually writing code, that is what they
are good at that is what they specialize in and that is the one thing that they
are uniquely suited to accomplish. So we should want this as well.
Developers have a lot of the plate already and will rightfully pushback
against further expectations, anything you add on to a developer's plate they
will be hesitant to adopt because they know that they need to continue writing
code. Remaining efficient and this is their job, and most manual accessibility
testing processes are time-consuming. Any manual accessibility testing process
that you ask a developer to do, is going to distract from that thing that they
are good at writing code. The problem is Voiceover testing in development is very
slow. Voiceover testing is a slow process with a thoughtful analysis of an
individual screen taking 15 minutes or more. This is something that we do
not want developers to do. Even the act of turning on Voiceover is expensive
in developer years. If just going on too
screen and doing anything more than glancing at it is an expensive thing for
a developer and in a process where developers want things to cost them
seconds, turning on Voiceover cost minutes. This is an expensive thing and a
distraction from what they should be doing, which is writing code. And not only
that, but there's a question of whether this is a valuable thing to have them do.
Voiceover testing is difficult and requires nuanced expertise that not very
many developers have. We want to keep developers doing the things that they
are good at, and our accessibility experts doing the things that they are
good at right. So how do we marry these two things, how do we take accessibility
and development and combine them together in a way that allows us to
catch these defects early, without asking our experts in their various levels of
expertise to do things that they shouldn't be doing and that is what we
are talking about. The solution is Voice Control testing. This is new in iOS
13. I've got a little screenshot over here, this is just beautiful. In one
glance we get rudimentary coverage of all four WCAG 2.0 categories of
accessibility issues. Perceivability; look I can tell Voice Control and other
accessibility applications, know that all of these things are there.
Understandability; I can see the descriptions of all of them. Operability;
if Voice Control knows that those things are there, they will be operable in Voice
Control, Switch Control and Voiceover. And Robustness; one of the things that
Voiceover testing suffers from, is that everything is focused in
in Voiceover, but Voice Control only puts these great boxes on operable
things. So we know if we see these gray boxes over things, we know that it is not
only accessible in Voice Control but we can also conclude that it will also be
accessible in Voiceover. Question, how do we do it? So let me show you how
this works. So I have this is now not a screen shot anymore but I'm casting my
device. So what I'm going to do is I'm going to turn on Voice Control. I
want to click on this little Settings icon here. I'm going to find oh I'm
already at the Accessibility but if you come down here. New in iOS 13 they've
kind of reorganized their Settings area here, so you'll see that we go in and
Accessibility now has its own little category. So we go to Accessibility and
now we're going to find Voice Control. It's just a little down the list
Physical and Motor, under the heading Physical and Motor we're going to find
Voice Control and turn it on. Right now that this is on see we get this nice
gray overlay. Gonna pop it away. We're gonna find the view that we want to test.
I like testing the App store for testing this stuff out, there's a lot going on.
Basically all we are looking for is that there are these grey boxes over all of
our actionable controls. That's all we need, just the presence of these gray
boxes tell me a ton about the accessibility of my application. Just
from this image alone and glancing at this image which once you
get used to takes you about a second. I can tell that all of my actionable
controls are going to be accessible in Voice Control, Switch Control and if I
look at the text on those actionable controls, I can also see that Voiceover,
they're going to be actionable and in Voiceover as well, and that they have
reasonable descriptions. This is super super powerful. I can, as a developer set
a phone to my side, I don't even have to touch the phone I just go through my
standard process. Once I start interacting with this, notice these
things go away. As a developer it doesn't affect any of the way that I use
my device, it's just there. I can leave this on all the time and
then all I have to do is pause, wait for those little gray boxes to show up, and I
get an awesome view of how accessible my application is. For the amount of time
I've spent to do, it again all you have to do is wait that one or two seconds
for those views to show back up and you're good.
Crazy crazy cool. Benefits of Voice Control testing: Can be left on without
disrupting standard device usage. Significant coverage with just a glance,
seriously in one second you learn a ton. And no disruption to a developer's
workflow. That is pretty much all I have on that.
Here's a list of useful Voice Control commands to reference. I will really
really point out this "show me what to say" thing is
really cool. These are some commands that you could try in
Voice Control. That is all I have, thank you everybody.