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,
*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;
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
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;
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.
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.
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?
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?
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
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...
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.
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,
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,
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."
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.
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,
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;
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*.
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.
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*.
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,
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;
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 –
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.
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".
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.
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.
*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.
*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.
*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,
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.