WEBVTT

00:00:00.000 --> 00:00:30.000
So, let's look at the 10 principles of  accessibility for both web and mobile design.
The first principle is that blindness  gets you 80% of accessibility issues.
Now, there are four major types of disabilities: *blindness*,  and that includes low vision and color blindness,

00:00:30.000 --> 00:01:01.520
*hearing*, *cognitive* and *motor  impairments*.
Now, blindness is
actually across a spectrum; they're  like 22 different types of blindness,
but we basically differentiate between blind – and  there are different levels; like I said, you can be
on the *edge* of blindness – you can still  be legally blind but you can still have some sight;
and then you may require screen  magnification, which would be low vision;

00:01:01.520 --> 00:01:35.040
so, basically your vision  is impaired to whatever percent: 60, 70, 80, 90,
95%, 97% – you know –
but then there's a little  bit of magnification that can help.
So, you'll have low vision users using screen magnifiers to, like, 300% or 400% magnification,
and a lot of those tools, those  magnifiers have a screen reader in them

00:01:35.040 --> 00:02:02.957
as well, so blind users will use just the screen reader. And just like we saw in that last example,
the screen reader is, for example, VoiceOver on the iOS operating system,
which talks – essentially reads to you; that's a screen reader.
So, why blindness of all these different disabilities?
You might think, "Oh! Accessibility –  it's too difficult! There's so many different disabilities;

00:02:02.957 --> 00:02:35.690
how do you tackle the different ones?"
Blindness helps you get almost the whole way there because of keyboard and the screen reader.
So, blind users will use a keyboard so you can test keyboard access, which is what motor/mobility users.
Hearing – so, deafness and hard of hearing is essentially a captioning thing.
So, that's pretty straightforward. And then cognitive issues – they're a little bit more complex.

00:02:35.690 --> 00:03:00.649
They're a little bit more complex to test for.
And there's such a difference – you know – so we're talking about dyslexia, ADD, Asperger's, things like that.
And so, yeah, so blindness is, in terms of core accessibility, the way to get there, in terms of testing.

00:03:00.649 --> 00:03:30.000
So, for example, if you're testing with users,  you can recruit – you know – 80% of your users can
be blind and you'll be getting a really good  understanding of accessibility.
So, *alt-text* is classic on images – classic accessibility can  be summarized with alt-text.
Now, here's a little quick quiz for  you: what alt-text would you give this image?

00:03:30.000 --> 00:04:00.778
Let's take a minute and play here.
So, "ALT..."
So, "Man looking at wall with  complex graphics or infographics."
What did you give it?

00:04:00.778 --> 00:04:35.840
So, the classic issues with alt-text:
you want to describe, not the picture, but you want to describe the *information in the picture*.
So, what's the man doing? Like the fact that  he's wearing a suit or his age or
the type of brick wall it is – it's not  really important, the color of the wall.
You know – "Man staring at wall." It might  be a little non-descriptive; it really depends
on what the *function* of the image is. If this is an image that's required for the user

00:04:35.840 --> 00:05:01.415
to understand the content on the page, then it's  going to have to be a little bit more descriptive.
So, my alt-text: "Man looking  at wall with complex graphics or infographics."
I think should cover it.
If it's too short, like "Man looking at wall." – we talked about that, that might be a little – you know...

00:05:01.415 --> 00:05:30.536
If you add something like "Picture of man looking at wall." – you don't need that; you don't need the "picture".
So, or "photo" or "image" – you don't need
to say "image" – "Image of man looking at wall." You don't need to say that, either.
So, yeah, *alt-text*.
It's classic to accessibility because a lot of people forget it.

00:05:30.536 --> 00:06:01.920
They miss it; it's just classically overlooked.
And alt-text is actually critical to SEO.
So, it's really, really important that alt-text is addressed.
Let's look at the third one, then, so classic on mobile is the *hamburger menu*,
the hamburger menu being the three lines in the top left of the screen.
The easy fix is to just properly  tag it; so, typically those menus, the user,

00:06:01.920 --> 00:06:35.829
their screen reader just skips over them; users don't see them. They can't actually access them.
So, the classic one for mobile there is tagging those  mobile elements when they become responsive.
And the fourth one here is *Content  that gets placed "out of the way"
might not be found on the screen."  And so, what does "out of the way" mean?
Well, think of this, the screen reader reading this screen – this is a map.
So, you're looking for the location of this restaurant. This is from an actual usability or accessibility test,

00:06:35.829 --> 00:07:06.171
and I've included the kind of findings  here; so, the screen reader doesn't see the location list.
That's the important content. The map is not  really important; it's a visual paradigm.
Blind users are not going to see the map. This Google map's not going to be accessible.
It's like a million images that are not tagged; it's just like a big soup.
So, the important thing is the *list of locations that are on the screen* so that you know, "Oh yes, there's a restaurant near me."

00:07:06.171 --> 00:07:30.265
And the location list is after the map, and it should be *before the map* in the code.
So, the way that the screen reader is – the screen reader is parsing, reading the code, and so this is
what we mean by "out of the way content" –  content that's hard to find.

00:07:30.265 --> 00:08:05.600
The fifth principle is that accessibility testing with users – so *actually testing with users* – can reveal huge gaps.
Now, this is a huge revelation  for accessibility, by the way, because a lot of people
think they can handle it with checkers or with code reviews; I used to think that I could do that too.
And I need to tell you after 17 years  of practice of this in business with
my company Experience Dynamics, we've come to the  overwhelming *mandatory* recommendation, conclusion,

00:08:05.600 --> 00:08:31.476
revelation that *you have to accessibility test* – you  have to test with actual users.
It shouldn't be a surprise. In usability, you test with users. You don't just try and guess or follow a guideline.
It's the same with accessibility testing;  it's *even more important* I think because
*accessibility is twice as risky as usability*. Here, you see a usability test on the left;

00:08:31.476 --> 00:09:00.502
and on the right, you see an accessibility test with blind users completing the same task.
So, you see task 3 here and we have just – you know –
it's almost three times as easy for users who are sighted than users who are blind to complete this task.
The sixth principle is that *disabling zoom on mobile makes it inaccessible*.

00:09:00.502 --> 00:09:30.903
So, low vision users using screen magnifiers
won't be able to actually do the zooming if you disable it.
So, a lot of people will disable that on mobile, and it locks users out.
This is an image of a 400 times magnification by a user with low vision,
and that's literally how the screen is being digested.

00:09:30.903 --> 00:10:06.406
The seventh principle is that *accessibility is easily learned*. Remember that close to 20%
of the US population and 10% of men are colorblind, by the way.
So, clean coding can be learned with a little practice.
Accessibility is actually cheaper if you do it upfront compared to if you try and do it later.
So, it should be part of your coding, but also it should be part of your UX design strategy too.
So, the next principle is  *accessibility doesn't mean ugly*.

00:10:06.406 --> 00:10:31.680
It may require you to rethink kind of the layout – again,  this is where UX design can be very helpful.
But one of the things I've realized is that *visual  bias is your worst enemy*;
that because you're so familiar with seeing  things and the layout of a screen – you know –
the more creative you are, the more of a designer you are; the more creative designer, visual designer,

00:10:31.680 --> 00:11:05.770
the more biased you're going to be because you can *handle*, just like you can handle gray on gray and
– you know – clean UIs that people that need very high contrast, very definite articulation of UI elements are requiring,
and for you, it's fine if they're not there.
The ninth one here is to *check mobile accessibility separately* – we've talked about a few mobile accessibility issues here.
This is the same accessibility test where the link is underneath the map;

00:11:05.770 --> 00:11:33.397
for some reason, the responsive view pushes the search UI to a link
underneath the map into a collapse, and then you're  supposed to click on that link and open it up.
Now, it's even hard to see for sighted users. Even when I was observing it, I barely noticed this link.
What was happening with our blind users was it was skipping right past it; so, it was reading the screen – you know –

00:11:33.397 --> 00:12:05.825
so, it was like *search results, a map, edit search*, and then... and then it was continuing on.
And it was just the fact that it said "edit search",
here you're seeing the user was turning down her speaking rate because she thought – she went over it like five times
and didn't catch it.
It actually was there. I thought it wasn't there; I thought it wasn't being picked up, but it was there.
When she turned down her speaking rate, you could hear it being said, but it was sort of mashed in.

00:12:05.825 --> 00:12:32.208
And the question was – this is like  definitely a usability question and a
responsive design decision is: *Why would you need to collapse it?*
Why not just have the UI – you know – *above the map would be better*, so you have it where it was before?
Even below – if it was there – the actual just UI as opposed to collapsing it and making it a link that said "edit search".

00:12:32.208 --> 00:13:01.990
So, you can see here really where usability in UX plays into accessibility when you're thinking about it.
It actually requires you – in the same way that SEO responsive web design,
accessibility requires you to be thinking about things the way a screen reader,
the way a user accessing this website with a screen reader would think about it.
And it's really tricky to think that way – I need to tell you this.

00:13:01.990 --> 00:13:30.400
It's super tricky to think that way, because you're *not used to it*.
You know – you're used to your visual bias; you're like, "Well, I can see the link... what's the problem?"
And so, this is where accessibility testing can help you get to that last mile of insight.
So, the tenth principle here is *embrace the access attitude*.
It's *People First* – design for differences.

00:13:30.400 --> 00:14:01.378
*Clear Purpose* – so, well-defined goals, and  that means understanding your audience.
So, we'll be talking about personas later on in this course.
*Solid Structure* – so building to standards; there are great standards. Accessibility is based on good clean coding.
So, just like alt-text, every image  needs an alt tag – *every single image*.
That's just part of clean coding, and it'll make things accessible and Googlebot will be happy as well.

00:14:01.378 --> 00:14:35.345
*Easy Interactions* – everything works across devices. Interoperability baked right in.
*Helpful Wayfinding* – so, it's navigation: clear navigation.
One of the things with accessibility is a lot of sites and web apps make it hard for users to navigate.
So, just like we saw with that comparison of the  usability test versus the accessibility test,
it's like twice as hard / three times as hard to navigate  a site if you're using a screen reader, for example.

00:14:35.345 --> 00:15:00.675
*Clean Presentation* – supporting meaning; that's a huge one: supporting meaning.
*Plain Language* – plain language is really important, especially for the cognitive disabilities such as dyslexia or ADD or ADHD.
And then, finally, *Accessible  Media* – so, supporting all the senses.
So, offering captioning for deaf and hard of hearing users,

00:15:00.675 --> 00:15:14.780
offering alternative formats – for example, if the media or if the image is too complex
or the table is too complex, you'll need to offer a  different way for users to get to it.