1
00:00:00,000 --> 00:00:07,111
[MUSIC]

2
00:00:07,111 --> 00:00:13,810
It is my absolute pleasure to begin today
with our first speaker, Jordan Smith.

3
00:00:13,810 --> 00:00:16,564
Not only does he share the name of my son,
but

4
00:00:16,564 --> 00:00:21,960
Jordan is a full stack engineer with
a strong focus on mobile applications.

5
00:00:21,960 --> 00:00:27,868
His current role in the industry sees him
tackling some of the largest accessibility

6
00:00:27,868 --> 00:00:32,694
issues and software technology to
make mobile apps more friendly and

7
00:00:32,694 --> 00:00:36,540
more falling under the disability cohort.

8
00:00:36,540 --> 00:00:41,756
Today, speaking on engineering mobile
apps with accessibility in mind,

9
00:00:41,756 --> 00:00:44,880
please welcome Jordan Smith.

10
00:00:44,880 --> 00:00:50,709
>> So I am an accessibility
engineer working on making,

11
00:00:52,193 --> 00:00:56,200
Making apps more accessible
on mobile devices.

12
00:00:57,760 --> 00:01:02,591
Accessibility is the concept of building
products that can be used by everyone

13
00:01:02,591 --> 00:01:05,360
regardless of their abilities.

14
00:01:05,360 --> 00:01:08,525
When building mobile apps,
we often think about the experience for

15
00:01:08,525 --> 00:01:10,740
able bodied individuals.

16
00:01:10,740 --> 00:01:15,251
But [COUGH], over 1 billion people
around the world live with some form

17
00:01:15,251 --> 00:01:19,162
of disability according to
the World Health Organization.

18
00:01:19,162 --> 00:01:22,808
This number is only growing as
populations are living longer and

19
00:01:22,808 --> 00:01:25,880
are more susceptible to
chronic impairments.

20
00:01:25,880 --> 00:01:31,006
You can also think of acute impairments
such as injury or surgery rendering you

21
00:01:31,006 --> 00:01:36,300
incapable of performing all the actions
previously intended by the developer.

22
00:01:39,420 --> 00:01:42,407
When building with accessibility in mind,

23
00:01:42,407 --> 00:01:45,480
we want to remember
the disability cohorts.

24
00:01:45,480 --> 00:01:50,099
Including, but not limited to, deaf and
hard of hearing, those with motor

25
00:01:50,099 --> 00:01:56,560
impairments, cognitive disabilities, and
those who are blind and visually impaired.

26
00:01:56,560 --> 00:01:57,880
By the end of this talk,

27
00:01:57,880 --> 00:02:01,314
I want to give you an idea of
the different ways you can make your

28
00:02:01,314 --> 00:02:05,900
app more accessible by addressing some
of these issues affecting these cohorts.

29
00:02:07,680 --> 00:02:12,643
I also want to mention that Liz has
put in a link at the top of the chat

30
00:02:12,643 --> 00:02:17,260
to make sure that you can follow
along with live captioning.

31
00:02:19,480 --> 00:02:23,670
First, let's talk about pressed states for
your interactive views.

32
00:02:26,300 --> 00:02:31,263
When there's a view in your app that
requires interaction, adding pressed

33
00:02:31,263 --> 00:02:36,550
states helps a user visually understand
that they've activated that element.

34
00:02:38,320 --> 00:02:41,940
Here is the button in a normal
state before interaction.

35
00:02:43,900 --> 00:02:48,161
We switch to the pressed state during the
interaction and let the user know, hey,

36
00:02:48,161 --> 00:02:50,220
we're aware that you're tapping me.

37
00:02:51,420 --> 00:02:55,540
After the interaction,
it's common to go to a loading state or

38
00:02:55,540 --> 00:02:58,740
switch screens or
just back to the normal state.

39
00:03:00,330 --> 00:03:03,721
If a button cannot be activated,
we show that with a third

40
00:03:03,721 --> 00:03:07,974
disabled state qhere the interaction
does not change the UI visually.

41
00:03:10,285 --> 00:03:13,760
For adding pressed states,
the code is super simple.

42
00:03:13,760 --> 00:03:17,177
For Android,
you can make a selector layout and

43
00:03:17,177 --> 00:03:19,746
reference it in your buttons view.

44
00:03:19,746 --> 00:03:23,013
You can see for
each state there is an item for

45
00:03:23,013 --> 00:03:26,026
which you can define a different color.

46
00:03:26,026 --> 00:03:31,571
For IOS, you can change the color
by setting the background for

47
00:03:31,571 --> 00:03:35,448
your button specifics highlighted state.

48
00:03:35,448 --> 00:03:39,546
I'm using Objective C here
instead of Swift, but

49
00:03:39,546 --> 00:03:42,480
the same idea happens on Swift too.

50
00:03:42,480 --> 00:03:48,064
It is easy to see how pressed states
help all users understand which elements

51
00:03:48,064 --> 00:03:54,008
they are tapping, especially for those
who have motor and visual impairments.

52
00:03:54,008 --> 00:03:55,053
In the same vein,

53
00:03:55,053 --> 00:03:59,464
let's discuss how big these elements
should be with a look at tap targets.

54
00:04:01,781 --> 00:04:05,826
A tap target is the area for
an interactive view in your app.

55
00:04:07,861 --> 00:04:12,113
IOS and Android have different ideas
about how big tap targets should be.

56
00:04:12,113 --> 00:04:18,328
On Android, it's 48 by 48, this
density and independent pixels, sorry.

57
00:04:18,328 --> 00:04:22,606
And for iOS it's 44 by 44 points.

58
00:04:22,606 --> 00:04:26,845
Users with motor impairments will
benefit most from this improvement.

59
00:04:26,845 --> 00:04:29,776
Tap targets should have
enough space around them for

60
00:04:29,776 --> 00:04:33,706
the fingertip to ensure the user can
tap their desired element without

61
00:04:33,706 --> 00:04:35,980
accidentally selecting another view.

62
00:04:37,880 --> 00:04:42,540
Imagine someone living with Parkinson's
trying to tap a smaller target.

63
00:04:42,540 --> 00:04:47,520
Without precisionm it is nearly
impossible to repeat the same result.

64
00:04:49,230 --> 00:04:52,600
With a larger target,
the results are more reliable.

65
00:04:52,600 --> 00:04:56,604
If you cannot increase the size
of the view for whatever reason,

66
00:04:56,604 --> 00:05:00,995
it is common to increase the size of
the tappable area around the view.

67
00:05:04,275 --> 00:05:06,870
Here's a photo on
Instagram with many people.

68
00:05:06,870 --> 00:05:11,101
The faces in the image are close together,
forcing the user tag of each

69
00:05:11,101 --> 00:05:15,560
person to violate the tap target spacing
rules that we just talked about.

70
00:05:16,870 --> 00:05:18,878
If you have overlapping tap targets,

71
00:05:18,878 --> 00:05:22,090
try offering different ways
to access these interactions.

72
00:05:23,130 --> 00:05:27,958
In this video, you can see that Instagram
gives the alternative to tapping tags

73
00:05:27,958 --> 00:05:30,150
directly in the image.

74
00:05:30,150 --> 00:05:32,753
Instead in the bottom left corner,

75
00:05:32,753 --> 00:05:37,540
you can bring up the list of tagged
users to visit their profiles.

76
00:05:39,110 --> 00:05:43,095
So using tap targets in your app can bring
about really creative considerations.

77
00:05:46,969 --> 00:05:50,246
Next, let's talk about color contrast.

78
00:05:50,246 --> 00:05:53,810
Keeping a good color contrast
between foreground and background

79
00:05:53,810 --> 00:05:58,228
colors gives visually impaired users
a chance to interpret your app's design.

80
00:06:02,809 --> 00:06:09,288
Both Android and IOS recommend the same
minimum 4:5:1 contrast ratio for

81
00:06:09,288 --> 00:06:13,520
normal sized texts, and
3:1 for larger texts.

82
00:06:14,850 --> 00:06:18,566
This is something you want to keep in mind
when making smaller texts for hints or

83
00:06:18,566 --> 00:06:19,140
sub texts.

84
00:06:21,020 --> 00:06:23,780
These are also the same guidelines for
the web.

85
00:06:23,780 --> 00:06:26,560
So if you're building there,
you can use the same colors.

86
00:06:28,480 --> 00:06:33,544
Color contrast is denoted as
a ratio between L1 + 0.05 / L2

87
00:06:33,544 --> 00:06:39,068
+ 0.05 where L1 is the relative
luminance of the lighter color and

88
00:06:39,068 --> 00:06:43,047
L2 is the relative luminance
of the darker color.

89
00:06:43,047 --> 00:06:50,580
The equation for relative luminance
is way too complicated for this talk.

90
00:06:50,580 --> 00:06:52,968
Actually, the whole equation for

91
00:06:52,968 --> 00:06:57,425
color contrast is probably too
complicated for this talk also.

92
00:06:57,425 --> 00:07:00,881
Knowing how to calculate
color contrast is thankfully,

93
00:07:00,881 --> 00:07:04,340
not important to following
the rules of color contrast.

94
00:07:06,267 --> 00:07:10,954
When choosing colors,
you can check the contrast and

95
00:07:10,954 --> 00:07:18,260
their compliance at color.a11y.com by
entering the two hexadecimal colors.

96
00:07:18,260 --> 00:07:23,283
I also did not speak about choosing colors
that accommodate color blindness, but

97
00:07:23,283 --> 00:07:28,107
it is also very important to think about
these things during the design stage.

98
00:07:31,648 --> 00:07:35,400
Next let's talk about labels.

99
00:07:35,400 --> 00:07:39,864
Labels are a easy way to improve
the accessibility of your app.

100
00:07:39,864 --> 00:07:44,639
Labels are what is announced by
screen readers when a user focuses on

101
00:07:44,639 --> 00:07:46,077
a particular area.

102
00:07:47,961 --> 00:07:50,426
Here are some rules for labeling views.

103
00:07:54,374 --> 00:07:56,720
Every interactive element
should have a label.

104
00:07:58,010 --> 00:08:00,060
Labels should be clear and to the point.

105
00:08:01,760 --> 00:08:04,994
You can imagine long labels take
a long time to announce and

106
00:08:04,994 --> 00:08:06,980
it can hold up the user experience.

107
00:08:09,440 --> 00:08:13,453
Labels should describe interactions for
interactive views and visual for

108
00:08:13,453 --> 00:08:14,960
content views.

109
00:08:14,960 --> 00:08:18,900
For photos, this would be
adding a label for all texts.

110
00:08:18,900 --> 00:08:22,170
And for text, it would literally
just be the text that you see.

111
00:08:24,250 --> 00:08:29,454
Not adding a label means
the viewing your hierarchy

112
00:08:29,454 --> 00:08:35,637
is not important to the user and
should not be part of your UI.

113
00:08:36,653 --> 00:08:40,180
Labels should also change when
the state of your UI changes.

114
00:08:41,570 --> 00:08:44,544
This concept makes a lot of sense
when going from screen to screen,

115
00:08:44,544 --> 00:08:46,040
but think about toggle buttons.

116
00:08:47,320 --> 00:08:52,291
In this video, you can see that every
time the user toggles the setting,

117
00:08:52,291 --> 00:08:56,020
the screen reader announces the new state.

118
00:08:56,020 --> 00:09:01,386
So you go from check to not checked,
back to check, not checked.

119
00:09:04,853 --> 00:09:08,750
The code for adding labels,
it's a one liner.

120
00:09:08,750 --> 00:09:12,790
For Android, you can do this with
the set content description method.

121
00:09:12,790 --> 00:09:18,370
And for iOS, you can assign the
accessibility label attribute to the view.

122
00:09:19,410 --> 00:09:23,249
To avoid common mistakes with labels,
incorporate them into your

123
00:09:23,249 --> 00:09:26,480
common components that you
reuse throughout your app.

124
00:09:28,620 --> 00:09:33,196
You can also write lint rules
to protect yourself and

125
00:09:33,196 --> 00:09:38,090
other engineers from building
views that emit labels.

126
00:09:40,130 --> 00:09:43,166
Last but not least,
let's talk about focus order.

127
00:09:45,717 --> 00:09:51,179
Assistive technologies navigate
the mobile UI in a specific order.

128
00:09:51,179 --> 00:09:55,532
Focus is the primary way using
an assistive technology such as a screen

129
00:09:55,532 --> 00:09:57,463
reader or a braille keyboard.

130
00:09:57,463 --> 00:09:59,930
It is able to move around the screen.

131
00:10:02,348 --> 00:10:07,477
Google's TalkBack and
IOS's VoiceOver both handle going to

132
00:10:07,477 --> 00:10:12,415
the next element on the screen
with a simple right gesture.

133
00:10:12,415 --> 00:10:16,984
As developers, we get to decide
which element receives focus next.

134
00:10:21,825 --> 00:10:26,723
IOS and Android try their best to dictate
the order of elements based on the views

135
00:10:26,723 --> 00:10:27,535
hierarchy.

136
00:10:27,535 --> 00:10:32,292
The best rule of thumb is having
a focus that follows the natural

137
00:10:32,292 --> 00:10:34,459
reading order of your view.

138
00:10:34,459 --> 00:10:40,271
Starting at the top left and
going in a z pattern to the bottom right.

139
00:10:40,271 --> 00:10:42,780
Rules are made to be broken, so

140
00:10:42,780 --> 00:10:47,229
feel free to group elements
that make sense together.

141
00:10:47,229 --> 00:10:51,970
If the element is content, or

142
00:10:51,970 --> 00:10:58,614
interactable, it should be focusable.

143
00:10:58,614 --> 00:11:05,034
Again, Again,
using Instagram as the example,

144
00:11:05,034 --> 00:11:09,250
you can see how the UI,
how focus is versus the UI.

145
00:11:10,590 --> 00:11:15,201
One important rule that should not be
broken is that you should not move

146
00:11:15,201 --> 00:11:18,060
focus without user interaction.

147
00:11:18,060 --> 00:11:21,756
You can imagine listening to text or
a piece of content and

148
00:11:21,756 --> 00:11:25,460
focus has moved to a pop-up or
an in-app notification.

149
00:11:25,460 --> 00:11:29,300
These design patterns should be
removed for the accessible experience.

150
00:11:31,610 --> 00:11:37,751
Here's some code examples of how to make
views focusable on both Android and iOS.

151
00:11:37,751 --> 00:11:42,976
For Android, you can set the set
focus method on the view.

152
00:11:42,976 --> 00:11:43,995
And for iOS,

153
00:11:43,995 --> 00:11:49,938
you will need to set the is accessibility
element that should be on the view.

154
00:11:53,590 --> 00:11:55,940
Well, okay, we covered a lot.

155
00:11:55,940 --> 00:12:02,602
So you are now more equipped to
tackle accessibility in your new app.

156
00:12:02,602 --> 00:12:07,675
But let's review some
of the core concepts.

157
00:12:07,675 --> 00:12:10,268
Pressed states.

158
00:12:10,268 --> 00:12:15,150
Pressed states show the user visually
that they've interacted with the app, and

159
00:12:15,150 --> 00:12:17,992
that the app has registered
that interaction.

160
00:12:17,992 --> 00:12:23,188
Tap targets, making interactive
views big enough so that users,

161
00:12:23,188 --> 00:12:28,590
regardless of motor deficiencies,
can tap on the correct element.

162
00:12:30,100 --> 00:12:34,110
Color contrast, check the contrast
ratios between your foreground and

163
00:12:34,110 --> 00:12:37,670
backgrounds in the app to make
sure that they are in compliance.

164
00:12:39,840 --> 00:12:43,400
Labels, label all the things from
interactive views to content.

165
00:12:44,520 --> 00:12:45,490
And focus order.

166
00:12:47,258 --> 00:12:52,118
Ensure you're focused on the visually
important elements in your screen and

167
00:12:52,118 --> 00:12:56,167
follow a order that is natural to
how you would read your screen.

168
00:12:58,390 --> 00:13:01,440
This is a lot to remember
when building an app.

169
00:13:01,440 --> 00:13:05,610
The cognitive load for
these considerations can be heavy, but

170
00:13:05,610 --> 00:13:08,530
making your app accessible should be easy.

171
00:13:09,800 --> 00:13:13,709
The changes I talked about today
are usually only a few lines for

172
00:13:13,709 --> 00:13:14,750
if statements.

173
00:13:15,930 --> 00:13:20,778
Apple and Google have done the heavy
lifting to make the experience as painless

174
00:13:20,778 --> 00:13:23,480
as possible for developers.

175
00:13:23,480 --> 00:13:28,003
So when you're coming up on a problem
that breaks accessibility in your app,

176
00:13:28,003 --> 00:13:32,597
consider that the fix will most likely be
simple and have the biggest impact for

177
00:13:32,597 --> 00:13:34,980
what can be your most passionate users.

178
00:13:38,320 --> 00:13:40,571
Thank you for listening.

179
00:13:40,571 --> 00:13:44,487
I think I have

180
00:13:44,487 --> 00:13:49,471
a few minutes for

181
00:13:49,471 --> 00:13:55,167
some questions and

182
00:13:55,167 --> 00:14:01,220
I'll see them now.

183
00:14:09,575 --> 00:14:14,044
Okay, sorry, I'm just looking
through the question, okay.

184
00:14:18,011 --> 00:14:23,755
Yes, so the first question here,
where did you learn about accessibility?

185
00:14:23,755 --> 00:14:28,578
Was it on the job or
was it in a major focus in your studies?

186
00:14:28,578 --> 00:14:32,298
Unfortunately, when I
was studying in school,

187
00:14:32,298 --> 00:14:35,938
accessibility was not
part of the curriculum.

188
00:14:35,938 --> 00:14:41,329
But I think that schools
should definitely adopt that

189
00:14:41,329 --> 00:14:46,733
if they haven't already
since I've been in school.

190
00:14:46,733 --> 00:14:51,860
I did learn it on the job, and there
are a lot of resources online with a very

191
00:14:51,860 --> 00:14:56,882
vocal community, That will definitely

192
00:14:56,882 --> 00:15:01,785
give you a lot of feedback on how
to make your views better and

193
00:15:01,785 --> 00:15:06,610
your apps better for
those who aren't fully able bodied.

194
00:15:11,477 --> 00:15:16,623
I do focus on accessibility
in my current role,

195
00:15:16,623 --> 00:15:22,037
working on things like I
just talked about today.

196
00:15:27,819 --> 00:15:31,070
Okay, another question here from Crystal.

197
00:15:31,070 --> 00:15:36,515
Is there a website that states
a standard that will be required for

198
00:15:36,515 --> 00:15:39,350
accessibility such as tab size?

199
00:15:39,350 --> 00:15:44,350
Yeah, so for Android and iOS,
which I talked about today,

200
00:15:44,350 --> 00:15:50,151
they both have accessibility
sections on their developer portals,

201
00:15:50,151 --> 00:15:55,267
which you can get the different
information I talked about.

202
00:15:55,267 --> 00:16:01,130
But a lot of the accessibility for
mobile apps is still being worked on.

203
00:16:01,130 --> 00:16:08,710
You can also look at the work
that has been done for the web.

204
00:16:08,710 --> 00:16:13,380
And if you're unsure about
a certain interaction or

205
00:16:13,380 --> 00:16:20,550
a certain way your view is being used, you
can check how we would do it on the web.

206
00:16:20,550 --> 00:16:23,931
Obviously, the interactions
are different using caps, but

207
00:16:23,931 --> 00:16:25,563
that's a good rule of thumb.

208
00:16:28,919 --> 00:16:31,846
Would the DB split for

209
00:16:31,846 --> 00:16:38,320
country's language using right to left?

210
00:16:38,320 --> 00:16:40,150
Yes, that is a good question.

211
00:16:41,590 --> 00:16:42,956
I'm not actually sure.

212
00:16:42,956 --> 00:16:45,046
It's a really good question.

213
00:16:47,586 --> 00:16:50,153
I'll look into that.

214
00:16:55,585 --> 00:16:59,339
Most common mistake for

215
00:16:59,339 --> 00:17:05,912
not looking at accessibility concerns?

216
00:17:05,912 --> 00:17:07,916
It's hard to pick one, but

217
00:17:07,916 --> 00:17:12,892
I would say it's the really easy
ones that can be fixed like labels.

218
00:17:12,892 --> 00:17:18,600
Labels can be put on views so
easily and it's usually like one line.

219
00:17:18,600 --> 00:17:22,430
And I feel like that can be missed a lot.

220
00:17:22,430 --> 00:17:28,630
Sometimes when you're building
more complicated views,

221
00:17:28,630 --> 00:17:33,910
a developer can miss making
that view focusable.

222
00:17:33,910 --> 00:17:39,040
So that happens a lot when Android and
iOS aren't able

223
00:17:39,040 --> 00:17:44,180
to interpret that a view is
supposed to be focused on.

224
00:17:44,180 --> 00:17:48,956
So as an engineer,
make sure that you're going into

225
00:17:48,956 --> 00:17:53,301
your screen readers and
checking out the app for

226
00:17:53,301 --> 00:17:58,590
yourself to make sure that
your app is fully accessible.

227
00:17:58,590 --> 00:18:04,422
Sometimes what I do is I'll go
into the app that I'm building and

228
00:18:04,422 --> 00:18:06,370
I will close my eyes.

229
00:18:07,450 --> 00:18:10,420
And I'll just slide through and
make sure it makes sense.

230
00:18:10,420 --> 00:18:14,340
So, if you're missing anything,
that's a real great way to build empathy.

231
00:18:17,330 --> 00:18:24,301
I'll do one more here.

232
00:18:29,962 --> 00:18:34,969
Let's see, should we label

233
00:18:34,969 --> 00:18:41,445
ourselves as developer [INAUDIBLE].

234
00:18:44,321 --> 00:18:49,721
Actually, I think that
might be it [LAUGH].

235
00:18:49,721 --> 00:18:56,680
I think we're at the end of my talk,
but I thank you so much for tuning in.

236
00:18:56,680 --> 00:19:01,305
I'll try and answer some of the questions

237
00:19:01,305 --> 00:19:06,207
in the chat after the talk,
and I appreciate