DeconstructSeattle, WA - Thu & Fri, Apr 23-24 2020

← Back to 2018 talks

Transcript

(Editor's note: transcripts don't do talks justice. This transcript is useful for searching and reference, but we recommend watching the video rather than reading the transcript alone! For a reader of typical speed, reading this will take 15% less time than watching the video, but you'll miss out on body language and the speaker's slides!)

All right. Hi, everybody. My name is Tea, like the beverage. Hopefully you got a drink during the break. And today, I'm going to talk about what web accessibility is, who it affects, and what you can do about it. And along the way, I'm going to talk about some common myths about accessibility, and we're going to bust them together.

So web accessibility refers to the process of removing barriers that prevent people from using the internet. And what that really means is that web accessibility is about equal access. It's about making sure that everyone can use the internet, even those with disabilities who are often overlooked by designers and developers. Now, if you've never heard about web accessibility until just now, don't worry. It's OK, you're not alone. In fact, I actually just heard about accessibility for the first time a couple of years ago in a kind of embarrassing story.

So I work at a nonprofit called DonorsChoose.org, and it's our mission to make it easy for anyone to give to a classroom in need. So we do that through our crowd-funding platform where teachers can go online and request the experiences and materials that they want for their students, and anyone can go on to give. A couple of years ago, we teamed up with Google.org-- which is Google's nonprofit arm-- on a campaign called #ForEveryKid. And the campaign was aimed at making education inclusive for students with special needs. We were really excited to work on this campaign, and then while we were working on it, Google's accessibility expert pointed out that, well, even though we wanted education to be #ForEveryKid, our website was not #ForEveryKid.

It wasn't even for every person, because we had designed it and developed it in a way that made it impossible to use for people with disabilities. I want to show you just how painful that experience was. So this is what the experience would have been like for someone who was trying to access our site using a screen reader. A screen reader is software that reads aloud web content, and it's often used by people who are blind or who have low vision. It's also used by people with certain learning disabilities like dyslexia so that they can make sense of the content on a site. All right. So this is our search page where donors can go on and kind of browse through classroom projects that speak to them. Here we go.

Find a classroom to support visited link. About us link. Help link. Donate 120.00. U4826532_SM [INAUDIBLE] link. End of text. Search topics, teachers and schools. End of text. End-- City stick. Search [? broaden. ?] 55,382 project ass. Sorted by most urgent. Navigate home. Subject math and science link. Music and the arts link. Literacy and language link. History and civics link. History and civics visited link.

All right. So at that point, I've just applied a search filter, history and civics. And if you can see the screen, you can see that some loading dots have appeared. But if you're just listening to the screen reader, which is what you're likely to do if you're someone who uses a screen reader, you wouldn't have known that anything happened at all. And new projects have loaded on the page, but again, if you're just listening to it, you wouldn't have known. If you even made it to this part of the website, it would have been impossible to use, but most likely you would have been deterred by all that random nonsense at the top. And it was just generally really, really painful.

So, it's 2018, right? Like you have a tiny computer in your pocket, yeah? You probably do too. We have access to so much in the world, and yet, the experience for a lot of people of using the internet is painful. So let's do something about it. In order to actually develop for accessibility, we need to keep these four principles of accessibility in mind, and these come from the Web Content Accessibility Guidelines. So in order to develop for accessibility, we need to make sure that our content is perceivable, operable, understandable, and robust. We're going to dig into each of these four with a couple of examples for each of them, and then talk about three common myths along the way.

So our first principle of accessibility is to make sure that your content is perceivable so you can be like Harry Potter with his glasses fixed. We want to make sure that content is not invisible to all of a user's senses. So that means that they should be made aware that the content is there whether it's through sight, sound, touch, or another sense. For this first example, there are two words on the screen. The first is bad and the second is good. So good is probably a lot easier for you to read than bad, and that is because of color contrast.

So this is a low technical fix, but if you're choosing colors for your site, make sure that the colors are a high enough contrast so that they're easy to read for people with low vision. This is also helpful for anyone who might be using a phone on a bright sunny day. You go outside, high contrast makes it easy to read. I'll share with you a color contrast at the end of this talk that you can check. You can also just Google contrast checker and you'll find one. Now, how do we make sure that images are perceivable for people who have low vision or who are blind? If you remember from the screen reader example earlier, when the screen reader got to that profile photo at the very top, it started reading a random string of numbers and letters, right? And that's because a screen reader, by default, will read an image file name. Not always good.

So instead, what you can do is give an image tag in HTML this attribute called alt text. Some of you might already be using alt text because it also appears if an image fails to load. So good alt text is short and descriptive. These are photos from our careers page. I could have just said, people working in an office. That's short and descriptive, but I think good alt text can also give and convey the feeling that you wanted your images to convey. So I wanted to show how warm and collaborative our work spaces are, so my alt text is, our open office encourages collaboration.

Now, making things perceivable is not just for those who have low vision or who are blind. We also need to keep keyboard accessibility in mind. So sometimes people have perfect vision, 20/20, and they still might need some other help. So if you're somebody who, for instance, has a hand tremor because of MS, or maybe you broke both of your arms playing dodgeball with your teammates, it might be difficult for you to use a mouse or a trackpad. So instead of using a mouse or a trackpad, what you would do is use a keyboard perhaps, to navigate through web pages and so on. Then you can see the screen, but you don't have maybe the help of the little cursor hand that tells you where you are on the screen.

So let's say there's this button on the website, and your tabbing through to figure out where you are on the site and to interact with the site. This is what the button looks like when nothing's happened to the button. And then you hit tab, and you're on the button. Can you tell that anything happened? No. It's because of this bad line of code that I see everywhere. So this is some CSS on the focus style of this button, and it's set outline to none. I see this everywhere because it's in pretty much every single CSS reset and normalized CSS, and the reason for that is that it strips out what a lot of designers think of as like ugly browser outlines. And it's OK to have outline none, but you have to replace it with something else.

So what we want instead is for this to be how the button looks when it's not being affected by anything. And then when you're focused on it or hovering over it, there should be some sort of difference. So with that outline none, what you can do is add some extra styling to differentiate those two states. So in this case, I just added a box shadow that added a turquoise outline. So at this point, we arrive at our first myth. Maybe some of you are thinking, this sounds great, sure. I do care about people with disabilities, but it doesn't affect that many people, right? Like maybe you're resource strapped. You probably are ignoring old versions of Internet Explorer. You're like, I don't even have time for Internet Explorer. I am one person. What can I do?

So look, businesses run on money. I get it. If you need to make this a business case for your stakeholders, your boss, yourself, let's talk about money and numbers. So in the US alone, there are over 60 million people with disabilities. That's a big number. What that comes out to is that about 20% of Americans have some form of disability. That makes people with disabilities the single largest minority in the United States. In the world, that makes it 1.3 billion people with disabilities globally. And if we're just talking about cash money, all of these people control about $2 trillion in income globally. I hope that's enough of a business case. Here's a market that you might be shutting out of your product.

And then, just besides the numbers of it, if you're thinking about accessibility as if it were an edge case, there's just this. People are not edge cases. You know, unlike that weird path on your site that no one's ever going to take to get to that one bug and you can have a workaround for it, if you live with disabilities, you don't get to just change your body or switch out. This is how you interact with the world. And it's not fair to just shut people out, especially as more of our world moves online. So let's do this.

Our second principle of accessibility is to make sure that things are operable so that even our Toy Story friends can open a door. Your content is operable if your users can interact with it and make it do the things that they need it to do. Let's look at this example where a screen reader tries to interact with a pop-up.

Internal link list item. Set up Facebook automatic updates for easy sharing internal link. Make an easy-to-remember teacher page link. Link list item.

All right. So the pop-up popped up. The screen reader was not aware that anything happened. Even if it was, we're stuck in like sad purgatory of this underneath the gray overlay, and you'll just never be able to access this pop-up. Very sad. All right, let's fix that. So here's that pop-up again. So how a screen reader is made aware of things is that one thing that you can do is to force focus on the items that you want the screen reader to read aloud, because a screen reader will always automatically read what is in focus. So whatever code that you have that opens that overlay, let's use some jQuery or JavaScript to target that pop-up. That's this pop-up that I've just highlighted. And then, do dot focus to force a focus on it. Then the screen reader will be aware of it.

Now, in your HTML, you'll also want to change some things because a div by itself is not a naturally focusable or tabbable element unlike links and buttons and inputs. So you'll want to add this attribute called tab index to it, and that just says, hey, this is tabbable. And you can set that to zero, which is like the default. It just says that this doesn't have to be tabbed in any particular order. Just take it as it comes in the DOM. And that's it. Now we can make the screen reader aware that there is a pop-up, and people can interact with it. But like, how do people really interact with pop-ups, right? You see a pop-up, what do you do? You want to close it probably. So if you're going to make it easy for people to close when they see it, like with that little X on the corner if they have a mouse, then you also want to make it easy for people who are using a keyboard to close an overlay. Easy.

So we'll put a listener on the body in jQuery, and run this function where if [? E dot, ?] which, if the key that is pressed is 27 or the escape key, then we'll write some code to hide that pop-up. So make sure that all of these different pieces, that you're letting your sighted users or your users who are using a mouse or trackpad, like let's make that also easy for people who are using the keyboard. So at this point, you might be thinking, that was a great example, but that's like one line of jQuery or whatever. What if everything is changing on my fantastic awesome dynamic site? I can't just throw focus around. That's very confusing. No one likes that. All right. Yeah, you're right. That would be terrible, so let's not do that. But we can make really exciting dynamic sites accessible, and we can make it work with really extensive JavaScript and screen readers and they can be friends forever.

So this example from our screen reader earlier, where we were on that search page, the projects were updating. How do we make sure a screen reader is aware? So this page is built in React, and so pretty much every single element on this page is either interactive or updates. What you can do is tell screen readers when certain areas are prone to change so that they can pay attention to them. We're going to target this div here that holds all of the different projects. That's the code simplified. So that's the div, inside are the projects. We want the screen reader to know, hey, this section is alive, and we're going to do that using ARIA attributes. ARIA stands for Accessible Rich Internet Applications, and it's a set of attributes that speaks to assistive devices and tells them how the elements are used.

Now, you don't have to install anything to use ARIA. It's already a part of HTML, as is pretty much everything that I'm going to talk about today. It should be easy because you don't have to learn a whole new language. You don't have to install any new libraries. This uses the code that you already know how to use, so just don't break the code. So aria-live is an attribute that says, hey, this section updates. Its alive, pay attention to it. And you can set it to polite, assertive, or off. Polite says, just read this to me when you're finished reading the other stuff. Like the screen reader is not going to interrupt itself if it's reading another part of the site. And in general, we want to be polite, right? So most of the time you'll want to be polite. You can use assertive for things like really loud error messages.

And then the second attribute is aria-busy, and you can set it to true or false. So in this section in this div, the projects update kind of one-by-one, and we don't want the screen reader to read it until it's all done. So what you can do is set aria-busy to true, and the screen reader will not read anything out loud while that section is busy. And then when it's ready, you can set it to false, and then it'll be ready. And then the last attribute is aria-atomic is true. This one basically just says that this whole div should be considered one unified part. And if it's set to false, what will happen is that, as that project's list is updating one-by-one, the screen reader would just continually restart and read them all through, and that's really annoying. We don't want to do that. So set aria-atomic to true and it will read it all together.

All right. That was like literally the most complicated piece of code that you'll ever have to write with accessibility, and I think it's pretty simple. You look like brilliant people. Also, every other talk here is going to be way more complex and require more brain power than this one is. I think this is simple. I believe in you. You can do this. Yeah. It's all code that you already know. So anyway, the rest of this talk, you're going to be like, easy peasy.

Our next principle is to make sure that things are understandable, so you can be like Scott Pilgrim going from not getting it to getting it right away. We want to make sure that content makes sense to users, right? So not only are you aware that it's there and that you can interact with it, but you know how to interact with it and what it means. This first example is just language, so hold your horses. That's a fun phrase. We're fun people. Maybe you know what that means. It means to like wait, right? But for some people, maybe this is the image that you get, a human being actually holding their beloved equine. So who would think this? Well, if you're new to this country for instance, or you're new to the English language, certain idioms don't really have inherent meaning. It doesn't make sense at its face value, so we need to keep people who are like new language learners in mind.

Also, for those who might be on the autism spectrum, some things might be taken more literally. And so something like this, hold your horses, can be confusing. Instead, let's replace it with simpler language like just a moment, just wait. And this is especially helpful for your error messaging, your missing pages sites, especially any time that's already kind of a stressful time for your users. Let's not add to the stress by using confusing language. Now, besides just making language understandable, we also want to make sure that your elements make sense and are understandable to assistive devices. So this is an example from our payments page where a user can choose to pay with a credit card, PayPal, Amazon, or Google Wallet. And this was what it was coded like in the HTML. It was just like a list item, and then, even though these are interactive elements, our developers had made it so that you have to do additional JavaScript and additional styling to make it kind of look like buttons.

But if we look at this payment option again, since you can only choose a credit card or Paypal or Amazon or Google Wallet, you should really be using radios since you're only selecting one. So if each of these is a single li, we should actually replace it with semantic code and turn all of them into inputs that are radios. So this is like the good thing to do. Writing semantic code makes it so that assistive devices can understand what your code means. And not just assistive devices, but also browsers and different user agents. But let's say for some reason that you cannot write the semantic code, you can't use an input. You can still make it understandable by, again, using our ARIA attributes. So we're turning it back into an li. It's getting a reverse makeover, but now, let's add some of those ARIA attributes.

So the first is role=radio. Role is an ARIA attribute, but it's the only one that doesn't have aria in front of it, kind of confusing. And radio just says that even though this is an li, it behaves like a radio. So the screen reader gets to this li, it will read it as credit card radio instead of just reading credit card. So now a user knows that they can interact with it the way they would interact with a radio element. Our second thing is adding a tab index because an li is not a naturally tabbable element, again, like links and buttons and inputs. And then our last thing I'm adding is this class called click helper. I wrote this class, and basically, what it does is it makes elements on our site that are right now using the onclick JavaScript like listener, and it's going to make it work for keyboards and keyboard accessibility.

So click helper I've defined elsewhere, and this is some JavaScript. But we basically are saying that, listen to the document for a key press. Anything that has a class of click helper, we're going to run this code. First, check if that button that is pressed is the enter key. And if so, stop it from refreshing the page, et cetera. And we're going to target that element that has the click helper class on it, and we're going to force it to click close. That's it. It's pretty simple. Feel free to crib this. I won't tell.

Our final principle of accessibility is to make sure that your content is robust and can withstand the heat of the flames just like the T-1000 did in the film Terminator 2, one of the best movies ever. OK. So your content is robust if it works on a variety of user agents like browsers, assistive devices now and moving into the future. That means you should care about these guys, even Internet Explorer, which I know we want to hate on, but don't. And you want it to work for a variety of assistive devices, and this is done through really good testing and writing semantic code. So I mentioned earlier, if you have code and you want it to be a button, instead of using a span tag which does not tell you what it is-- don't do that-- use a button tag. Semantic code basically means that you're coding in like HTML in a way that tells user agents how to actually interpret your code, and this will future proof your code. So do that.

And that's it. So those were the four principles of accessibility. We did it together. Great job. You too, really good. These were the four, perceivable, operable, understandable, and robust. If you keep those things in mind with your content, you will make your work accessible. This is our last myth. You might, at this point, be thinking, that was a lot, Tea. What? That was like 20 minutes. That's a lot. There's too much to do. I can't get started. I'm not doing it. All right. You don't have to do all of that. You don't have to remember all of that. Just do these three things. This is all I want you to do today. After the party and you get back to your hotel, this is all you have to do.

So the first is do a tab test. So go onto the website that you're working on or your favorite web site, and see if you can navigate through it with just your keyboard. If you can't, it's not accessible and you have some easy fixes that you can do that we talked about today. Do a tab test. The second thing to do is check your color contrast, which is super simple. You can Google for a contrast checker, or you can write this URL down if you really want to. But really, just Google contrast checker because this was like the first thing that pops up. Contrast checker, you can put in two different color codes and it'll tell you if your colors are a high enough contrast to be read by people with low vision.

And the last and final thing that you need to do is, you can download a free screen reader. The one that I was using was called ChromeVox. It sits on top of Chrome and then reads stuff out loud to you. It's really easy to learn. If you don't want to download one, your computer automatically already has a screen reader that you can turn on in your settings. Also, your phone does too. So if you have an iPhone or an Android, you can go into the settings and turn on your accessibility tool and it'll lead you through it. It'll like teach you how to use it, and that's it. Like, that's all you really have to do.

So all of this combined, I just wanted to show you that we did some more work on our site, and hopefully it doesn't suck as much. So I'm going to show you this run-through again really quickly with just the new screen reader. And you'll notice also, at the top of the beginning, there's this like link that comes down that says skip to main content. And that's so that, for people who are using the site over and over again, they can skip that header and just get to the main stuff.

[INAUDIBLE] to support. Skip to main content internal link. DonorsChoose.org visited link. Find a classroom to support visited link. About us link. Help link. Account credits button. Your profile photo [? NS ?] hello link. Classroom projects heading one. End of text. Search topics, teachers and schools. End of text. L-A-P-T-O-P-S return. Project list laptops for learning my students need two HP Chromebooks to enhance their daily--

All right, yea! OK. Aw, thanks. Yeah, so the projects list updated, and if you're using a screen reader, you know what's up. Things were working a little better now, and hopefully, if you just start doing those three things that I said-- do a tab test, check your contrast, learn how to use a screen reader-- those things will inspire you to continue down the path and work towards accessibility so we can make the internet work for everyone. And just one last thing. As you can tell, the voice of the screen reader is still not the nicest. So if anyone is like close friends with Morgan Freeman, let's get him on board too. All right, that's it. Thank you so much.