Heads up! To view this whole video, sign in with your Treehouse account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Engineering Mobile Apps with Accessibility in Mind with Jordan Smith
19:06 with TreehouseLearn about aspects of design that increase the accessibility of your mobile app and the amount of users that will be able to experience your app.
This video doesn't have any notes.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
[MUSIC]
0:00
It is my absolute pleasure to begin today
with our first speaker, Jordan Smith.
0:07
Not only does he share the name of my son,
but
0:13
Jordan is a full stack engineer with
a strong focus on mobile applications.
0:16
His current role in the industry sees him
tackling some of the largest accessibility
0:21
issues and software technology to
make mobile apps more friendly and
0:27
more falling under the disability cohort.
0:32
Today, speaking on engineering mobile
apps with accessibility in mind,
0:36
please welcome Jordan Smith.
0:41
>> So I am an accessibility
engineer working on making,
0:44
Making apps more accessible
on mobile devices.
0:52
Accessibility is the concept of building
products that can be used by everyone
0:57
regardless of their abilities.
1:02
When building mobile apps,
we often think about the experience for
1:05
able bodied individuals.
1:08
But [COUGH], over 1 billion people
around the world live with some form
1:10
of disability according to
the World Health Organization.
1:15
This number is only growing as
populations are living longer and
1:19
are more susceptible to
chronic impairments.
1:22
You can also think of acute impairments
such as injury or surgery rendering you
1:25
incapable of performing all the actions
previously intended by the developer.
1:31
When building with accessibility in mind,
1:39
we want to remember
the disability cohorts.
1:42
Including, but not limited to, deaf and
hard of hearing, those with motor
1:45
impairments, cognitive disabilities, and
those who are blind and visually impaired.
1:50
By the end of this talk,
1:56
I want to give you an idea of
the different ways you can make your
1:57
app more accessible by addressing some
of these issues affecting these cohorts.
2:01
I also want to mention that Liz has
put in a link at the top of the chat
2:07
to make sure that you can follow
along with live captioning.
2:12
First, let's talk about pressed states for
your interactive views.
2:19
When there's a view in your app that
requires interaction, adding pressed
2:26
states helps a user visually understand
that they've activated that element.
2:31
Here is the button in a normal
state before interaction.
2:38
We switch to the pressed state during the
interaction and let the user know, hey,
2:43
we're aware that you're tapping me.
2:48
After the interaction,
it's common to go to a loading state or
2:51
switch screens or
just back to the normal state.
2:55
If a button cannot be activated,
we show that with a third
3:00
disabled state qhere the interaction
does not change the UI visually.
3:03
For adding pressed states,
the code is super simple.
3:10
For Android,
you can make a selector layout and
3:13
reference it in your buttons view.
3:17
You can see for
each state there is an item for
3:19
which you can define a different color.
3:23
For IOS, you can change the color
by setting the background for
3:26
your button specifics highlighted state.
3:31
I'm using Objective C here
instead of Swift, but
3:35
the same idea happens on Swift too.
3:39
It is easy to see how pressed states
help all users understand which elements
3:42
they are tapping, especially for those
who have motor and visual impairments.
3:48
In the same vein,
3:54
let's discuss how big these elements
should be with a look at tap targets.
3:55
A tap target is the area for
an interactive view in your app.
4:01
IOS and Android have different ideas
about how big tap targets should be.
4:07
On Android, it's 48 by 48, this
density and independent pixels, sorry.
4:12
And for iOS it's 44 by 44 points.
4:18
Users with motor impairments will
benefit most from this improvement.
4:22
Tap targets should have
enough space around them for
4:26
the fingertip to ensure the user can
tap their desired element without
4:29
accidentally selecting another view.
4:33
Imagine someone living with Parkinson's
trying to tap a smaller target.
4:37
Without precisionm it is nearly
impossible to repeat the same result.
4:42
With a larger target,
the results are more reliable.
4:49
If you cannot increase the size
of the view for whatever reason,
4:52
it is common to increase the size of
the tappable area around the view.
4:56
Here's a photo on
Instagram with many people.
5:04
The faces in the image are close together,
forcing the user tag of each
5:06
person to violate the tap target spacing
rules that we just talked about.
5:11
If you have overlapping tap targets,
5:16
try offering different ways
to access these interactions.
5:18
In this video, you can see that Instagram
gives the alternative to tapping tags
5:23
directly in the image.
5:27
Instead in the bottom left corner,
5:30
you can bring up the list of tagged
users to visit their profiles.
5:32
So using tap targets in your app can bring
about really creative considerations.
5:39
Next, let's talk about color contrast.
5:46
Keeping a good color contrast
between foreground and background
5:50
colors gives visually impaired users
a chance to interpret your app's design.
5:53
Both Android and IOS recommend the same
minimum 4:5:1 contrast ratio for
6:02
normal sized texts, and
3:1 for larger texts.
6:09
This is something you want to keep in mind
when making smaller texts for hints or
6:14
sub texts.
6:18
These are also the same guidelines for
the web.
6:21
So if you're building there,
you can use the same colors.
6:23
Color contrast is denoted as
a ratio between L1 + 0.05 / L2
6:28
+ 0.05 where L1 is the relative
luminance of the lighter color and
6:33
L2 is the relative luminance
of the darker color.
6:39
The equation for relative luminance
is way too complicated for this talk.
6:43
Actually, the whole equation for
6:50
color contrast is probably too
complicated for this talk also.
6:52
Knowing how to calculate
color contrast is thankfully,
6:57
not important to following
the rules of color contrast.
7:00
When choosing colors,
you can check the contrast and
7:06
their compliance at color.a11y.com by
entering the two hexadecimal colors.
7:10
I also did not speak about choosing colors
that accommodate color blindness, but
7:18
it is also very important to think about
these things during the design stage.
7:23
Next let's talk about labels.
7:31
Labels are a easy way to improve
the accessibility of your app.
7:35
Labels are what is announced by
screen readers when a user focuses on
7:39
a particular area.
7:44
Here are some rules for labeling views.
7:47
Every interactive element
should have a label.
7:54
Labels should be clear and to the point.
7:58
You can imagine long labels take
a long time to announce and
8:01
it can hold up the user experience.
8:04
Labels should describe interactions for
interactive views and visual for
8:09
content views.
8:13
For photos, this would be
adding a label for all texts.
8:14
And for text, it would literally
just be the text that you see.
8:18
Not adding a label means
the viewing your hierarchy
8:24
is not important to the user and
should not be part of your UI.
8:29
Labels should also change when
the state of your UI changes.
8:36
This concept makes a lot of sense
when going from screen to screen,
8:41
but think about toggle buttons.
8:44
In this video, you can see that every
time the user toggles the setting,
8:47
the screen reader announces the new state.
8:52
So you go from check to not checked,
back to check, not checked.
8:56
The code for adding labels,
it's a one liner.
9:04
For Android, you can do this with
the set content description method.
9:08
And for iOS, you can assign the
accessibility label attribute to the view.
9:12
To avoid common mistakes with labels,
incorporate them into your
9:19
common components that you
reuse throughout your app.
9:23
You can also write lint rules
to protect yourself and
9:28
other engineers from building
views that emit labels.
9:33
Last but not least,
let's talk about focus order.
9:40
Assistive technologies navigate
the mobile UI in a specific order.
9:45
Focus is the primary way using
an assistive technology such as a screen
9:51
reader or a braille keyboard.
9:55
It is able to move around the screen.
9:57
Google's TalkBack and
IOS's VoiceOver both handle going to
10:02
the next element on the screen
with a simple right gesture.
10:07
As developers, we get to decide
which element receives focus next.
10:12
IOS and Android try their best to dictate
the order of elements based on the views
10:21
hierarchy.
10:26
The best rule of thumb is having
a focus that follows the natural
10:27
reading order of your view.
10:32
Starting at the top left and
going in a z pattern to the bottom right.
10:34
Rules are made to be broken, so
10:40
feel free to group elements
that make sense together.
10:42
If the element is content, or
10:47
interactable, it should be focusable.
10:51
Again, Again,
using Instagram as the example,
10:58
you can see how the UI,
how focus is versus the UI.
11:05
One important rule that should not be
broken is that you should not move
11:10
focus without user interaction.
11:15
You can imagine listening to text or
a piece of content and
11:18
focus has moved to a pop-up or
an in-app notification.
11:21
These design patterns should be
removed for the accessible experience.
11:25
Here's some code examples of how to make
views focusable on both Android and iOS.
11:31
For Android, you can set the set
focus method on the view.
11:37
And for iOS,
11:42
you will need to set the is accessibility
element that should be on the view.
11:43
Well, okay, we covered a lot.
11:53
So you are now more equipped to
tackle accessibility in your new app.
11:55
But let's review some
of the core concepts.
12:02
Pressed states.
12:07
Pressed states show the user visually
that they've interacted with the app, and
12:10
that the app has registered
that interaction.
12:15
Tap targets, making interactive
views big enough so that users,
12:17
regardless of motor deficiencies,
can tap on the correct element.
12:23
Color contrast, check the contrast
ratios between your foreground and
12:30
backgrounds in the app to make
sure that they are in compliance.
12:34
Labels, label all the things from
interactive views to content.
12:39
And focus order.
12:44
Ensure you're focused on the visually
important elements in your screen and
12:47
follow a order that is natural to
how you would read your screen.
12:52
This is a lot to remember
when building an app.
12:58
The cognitive load for
these considerations can be heavy, but
13:01
making your app accessible should be easy.
13:05
The changes I talked about today
are usually only a few lines for
13:09
if statements.
13:13
Apple and Google have done the heavy
lifting to make the experience as painless
13:15
as possible for developers.
13:20
So when you're coming up on a problem
that breaks accessibility in your app,
13:23
consider that the fix will most likely be
simple and have the biggest impact for
13:28
what can be your most passionate users.
13:32
Thank you for listening.
13:38
I think I have
13:40
a few minutes for
13:44
some questions and
13:49
I'll see them now.
13:55
Okay, sorry, I'm just looking
through the question, okay.
14:09
Yes, so the first question here,
where did you learn about accessibility?
14:18
Was it on the job or
was it in a major focus in your studies?
14:23
Unfortunately, when I
was studying in school,
14:28
accessibility was not
part of the curriculum.
14:32
But I think that schools
should definitely adopt that
14:35
if they haven't already
since I've been in school.
14:41
I did learn it on the job, and there
are a lot of resources online with a very
14:46
vocal community, That will definitely
14:51
give you a lot of feedback on how
to make your views better and
14:56
your apps better for
those who aren't fully able bodied.
15:01
I do focus on accessibility
in my current role,
15:11
working on things like I
just talked about today.
15:16
Okay, another question here from Crystal.
15:27
Is there a website that states
a standard that will be required for
15:31
accessibility such as tab size?
15:36
Yeah, so for Android and iOS,
which I talked about today,
15:39
they both have accessibility
sections on their developer portals,
15:44
which you can get the different
information I talked about.
15:50
But a lot of the accessibility for
mobile apps is still being worked on.
15:55
You can also look at the work
that has been done for the web.
16:01
And if you're unsure about
a certain interaction or
16:08
a certain way your view is being used, you
can check how we would do it on the web.
16:13
Obviously, the interactions
are different using caps, but
16:20
that's a good rule of thumb.
16:23
Would the DB split for
16:28
country's language using right to left?
16:31
Yes, that is a good question.
16:38
I'm not actually sure.
16:41
It's a really good question.
16:42
I'll look into that.
16:47
Most common mistake for
16:55
not looking at accessibility concerns?
16:59
It's hard to pick one, but
17:05
I would say it's the really easy
ones that can be fixed like labels.
17:07
Labels can be put on views so
easily and it's usually like one line.
17:12
And I feel like that can be missed a lot.
17:18
Sometimes when you're building
more complicated views,
17:22
a developer can miss making
that view focusable.
17:28
So that happens a lot when Android and
iOS aren't able
17:33
to interpret that a view is
supposed to be focused on.
17:39
So as an engineer,
make sure that you're going into
17:44
your screen readers and
checking out the app for
17:48
yourself to make sure that
your app is fully accessible.
17:53
Sometimes what I do is I'll go
into the app that I'm building and
17:58
I will close my eyes.
18:04
And I'll just slide through and
make sure it makes sense.
18:07
So, if you're missing anything,
that's a real great way to build empathy.
18:10
I'll do one more here.
18:17
Let's see, should we label
18:29
ourselves as developer [INAUDIBLE].
18:34
Actually, I think that
might be it [LAUGH].
18:44
I think we're at the end of my talk,
but I thank you so much for tuning in.
18:49
I'll try and answer some of the questions
18:56
in the chat after the talk,
and I appreciate
19:01
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up