Accessibility

Don Norman has a great quote about that accessability is about making it easier for everyone. I like to say that accessibility is the cousin of usability: they're

sisters, and it's because you're optimizing your code, simplifying your layouts, you know – maybe a little strategically for screen readers; knowing that things like maps are going to get in the way or that a layout is going to impact the way that a screen reader accesses it, and it's the same for – if you've done any SEO or played around with the way Googlebot thinks and parses a page, it's very structured; it's very strategic, and once you realize how it does that, you can think that way when you're designing as well – so,

plain English; consideration for the end user; browser and device compatibility; you know, this is where usability and accessibility are combined with that goal of useful, usable, searchable, you know, and the key is quick and efficiently and painless – really, that's critical: like I said, for accessibility, even more than usability. So, accessibility impacts SEO, and the reason is because the better the experience and time on site is the main

factor for – the Nielsen Net ratings, maybe ten years ago, set the standard from, you know, number of unique visits to time on site, which is why Facebook and other sites try to keep you locked in to view their content, because their advertisers incentivize them with time on site. Well, the more you do that, the more Google's algorithm likes your site. Making graphical information

searchable – all graphical information: Google likes that, so that's a ranking indicator. Screen reader testing can also help you figure out what's missing from your SEO keywords. So, if you look at your Alt text, you can be, like, "Oh, wait a minute; we haven't optimized this." Now, the thing I should say is that if you optimize your usability, it doesn't necessarily impact accessability, and if you optimize SEO, it doesn't

necessarily impact accessibility. So, it's really the other way around: modify, optimize accessibility can improve SEO, can improve usability, right. It's not mutually exclusive. It's not mutually bi-directional – so, look to optimize areas of SEO and accessibility overlap. What are those? So, video transcription, for example, image captioning, Alt attributes, title tags, headers (H1, H2), link anchor

text, on-site sitemaps, table of contents or breadcrumbs, content ordering, size and color contrast of text, semantic HTML. So, this is an example from SEO Moz that, you know – it's like if you went to this page and you're trying to, you know, submit your taxes for tax season, which of these would – which of these – if you didn't see the page, calculate your tax return or online

tax return, tax return estimate, tax return refund / rebate, you know; it's that the screen reader's literally reading all that out, so you're starting to think about, hopefully, the experience – the optimization opportunity as audible, you know, something you hear. So, what does it sound like? What does it sound like? Does it have meaningful descriptive text that's just not going to be a bunch of garbage? A lot of people when they're listening to screen readers,

they get overwhelmed – it's totally overwhelming. It's because it's like "blah-blah-blah-blah-blah": most blind users listen to their voices in a much, much faster pace like that. So, it's like, you know: two, three times as fast – like, it's going like this, and it's like all this information. But the reason why it's overwhelming for, you know, someone who's not familiar with it is because – it's all the garbage that's in

there, all the tags and all that – all this just raw web architecture is revealed through voice, and it's totally nonsensical, and the reality is that screen-reader users have to listen to all that, so they have to listen to, you know, 60 to 80% junk to find the one or two things that're meaningful and valuable to them. Right, so you can help by the way that you order your titles, the way that

you, you know, define your headers, define your title tags, your your Alt tags, your image captions, and so forth and so on.

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.

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.

The thing with access and accessibility is it's  moving more towards being seen as a *human right* internationally and as part of the basic  foundation of good coding and good UX design. Accessibility actually encourages us to do clean  coding and to think about the usability of our sites because you're thinking about the *user*. Anytime you're thinking about the user, you're doing *user advocacy*. User advocacy gets you to *walk in their shoes*. Walking in their shoes generates *empathy*.

Empathy helps you think about the website from the person who's going to use it, not your perspective. Accessibility needs to be the pillar in our optimization strategies. That is part of the launch strategy of any product.