Why We Never Get to Web Accessibility 102
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Certa, Liz
Creating truly 100% accessible websites often requires specialized knowledge of the ins and outs of screen reader settings, browser defaults and HTML quirks, yet most of us still need to google how to turn on a screen reader. We attend "Web Accessibility 101" seminars and workshops over and over but very few of us end up with the kind of specialized knowledge necessary to make truly accessible websites. In this talk, we'll discuss why this is, and how we can eventually get to accessibility 102.
 Okay, let's get started. I'm starting right away because again we've got a lot of ground to cover. Hi everybody, welcome to my talk. My name is Liz. I work at Vitals. That's my Twitter handle. If there are warning, it's a lot of Star Trek and Dungeons and Dragons if you choose to follow me, but if you do, great. Today we're going to talk about why we never get to Web Accessibility 102. Now before I start, I have a couple disclaimers that I need to cover. For one, I do not identify as disabled. I am coming at this from the perspective of an able-bodied person who works a lot in accessible development. There's a lot of great disabled developers and internet users who have said a lot of the things I'm going to say today. I'm going to give you some resources at the end of this talk so you can go find them yourselves and read what they have to say. Disclaimer number two, I'm going to touch very briefly on some legal stuff here, but in case it's not obvious, I am not a lawyer. Even if I were, I am not your lawyer. You should not be taking legal advice from me. Disclaimer number three, this is going to be a very US-focused talk. I'm cognizant. There's people here from other countries, but I'm not as familiar with other countries as I am with the Americans with Disabilities Act. So although I hope there's still some things I'll be talking about today that apply pretty widely. And then finally, there's currently a debate in the disabled community over the terminology, specifically disabled people versus people with disabilities. I'm going to be using both interchangeably because I've met people who feel strongly both one way and the other. I'm not here to pick a side on that issue, but if I say a term that's not your preferred term, then if you identify disabled, I apologize. Okay, so let's start with why I'm here. Like many of you, I saw this tweet back in December opening the RailsConf call for proposals and I thought, okay, am I working on anything cool that I think the Rails community might want to see? And over the past year and a half, I've been really ramping up into accessible development at my company. So I thought, okay, how about I talk about that? In fact, how about I give a presentation I've already given at my company to various teams in various settings? And that presentation goes like this. Welcome to Accessibility 101. Disabled people use your website. Some use screen readers. Some are colorblind. Try out your website using just the keyboard. You get the idea. But before I was in software development, my background was in academia. And one of the cardinal rules of academia is try not to say things that other people have already said. And while this is an important topic, and I'm sure there's people here who could learn something from it, this is definitely already been said. And not just in general at this conference. You can see it in 2017, 2015, 2014, all the way back to 2006. Now I'm not trying to imply that these are needlessly repetitive. I watched all of these in prep for this talk. Just the different perspectives alone that the different developers came with towards this topic makes it worth your while to check them out. Also it's not necessarily a bad thing to say the same thing at a conference. I mean, heaven knows we get to talk like this about once a year. How Docker improved my Rails app, cured my acne, saved my marriage, broken world peace. But here's the thing. Take Docker as an example. Yes, we get to talk like this pretty frequently. But it's complemented by talks like this. Deep dive into Docker containers for Rails developers. Notice the words one, deep dive, and two, four, Rails developers. So something that's very specific and that requires your own, a lot of expertise into a subject. And also something tailored toward a particular audience. And when we just teach one-to-one over and over again, we don't seem to get talks like this that are catered to our audiences and that go into sort of deep, divey things. And what kinds of talks am I talking about? How about accessible syntax? Where it lives, what it looks like. Did you know that if you have a strike, if you need a strike through somewhere on your website, if you put that strike, make that strike through happen through DEL tags or make that strike through happen through text decoration line through in your CSS, it can impact how certain screen reader browser combinations read it. Which is important if you've got anything like this on your website, where it's really important that the screen reader says what's got a line through in it, what's the real price of whatever it is you're working on. Okay, but Liz, this is RailsConf. How about a Rails specific talk? Okay. How I hacked NVDA into loving Rails and Rails into loving NVDA. NVDA is the only widely used open source screen reader. So you can crack it open, get an idea of both how NVDA works and how your average screen reader works too. So you can totally submit a pull request. Let's say you happen to have a lot of specialized knowledge about a certain extremely popular framework. You can submit a PR to NVDA to make it work better with your framework or a PR to Rails to make it work better with NVDA or screen readers in general. But we don't seem to get specific talks like this. And you know, when I, I'm sorry. So my first idea of this talk was to say, oh well, it's time to throw off 101 and start getting into 102. And then I sat down with Tim Springer. Tim Springer is the CEO of a company called Level Access. They do a lot of stuff. They will audit your company website for accessibility. They have great training programs, educational materials. They're great. You should check them out after this talk. And I said, you know, Tim, don't you think it's time to just stop doing 101? And for starters, he pointed out for one, it's not important for everybody to have 102-level knowledge, which is fair. You know, not everybody who uses Docker can give a talk at RailsConf about Docker. But also, when you go into a website, the top 10 out of the 100 most prevalent accessibility related bugs that an organization has, usually 80% of the access, are going to be 80% of the accessibility issues in total. And it's the stuff you know about providing labels for form fields, providing image alt attributes. So clearly, we keep giving these 101 talks, but we're not implementing that 101 knowledge. So this is where the liberal arts part of my brain sort of kicks into overdrive because if we're, my background was in English and also education. And if we're trying to pass on knowledge and we're not doing it successfully, it's like, you know, why? Why is this happening? And I found a fairly simple answer to this, which is that we develop expertise in the things we work on. And we're just not sort of putting in the work into accessible development. Okay, now we got to the bottom of that. Thank you so much for coming to my talk. Oh, man. Oh, darn, I've got 32 minutes left. Okay. So I guess we can go into the second question this led me to. Why aren't we doing the work to get better at accessible development? And this turned out to be a bit of a complicated question with a lot of different factors coming into it. And I'm going to start with the least comfortable one so it gets better from here on out. And that is ableism. Every single person in this room, without exception, and anybody watching this video later, is, grew up in an ableist society. None of us chose to do that, but we can have a say in how ableist our society is going forward, but we can get to that later. One of the most pernicious ways that ableism impacts all of us is that it erases disabled people. It erases their presence. It erases their voices, their stories, their perspectives, their needs, even, again, their presence. And we're going to do a quick experiment. The 2010 census asked the people who took it if they identified as having a disability. Now to be clear, this is just people who self-identify as having a disability and are comfortable writing that on a census, which is in itself a bit problematic, which we'll get to in a second. And we're going to do an experiment. I want you to raise your hand if the number that I say to you sounds too low, and then put it down if you think it sounds too high. Ready? Let's start with one in 100. Does that sound too low? Raise your hand. Okay, one in 50. One in 10. One in five. If your hand's down now, you're finally right. Nineteen percent of people in America identify as having a disability. And that's probably an undercount. So for one, of course, there's people who just don't feel comfortable disclosing on a form that they have a disability. Certain disabilities are chronically undercounted in certain communities. Autism is very, very undercounted in girls and women. And there's also just people who say, yes, you know, it's hard to get out of bed every day because my pain is so bad, but, you know, I'm not like disabled. Also, I'm sure there's people at this conference, possibly in this room, who are colorblind and might not consider themselves disabled, even though that's considered a disability that we have to work on in accessible development. But we're going to stick with 19 percent because that's a nice, hard meeting number that we can hold on to for later. Bearing that in mind, I'm just going to go through two aspects of the society that we went into, and they're very formative aspects, that's stuff that we grew up with, to give you an idea of how ableism works. So let's start with entertainment. In the 2017-2018 primetime television season of the regular recurring characters, 1.8 percent had a disability. Furthermore, according to the Washington Post, all the characters that we see in television and in movies who have a disability, I think it was 95 percent, are played by actors who don't have a disability. Let's also talk a bit about education. I am sure many of us here learned about Helen Keller in school, and you probably learned that FDR used a wheelchair. Did you know that Harriet Tubman had a seizure disorder? Did you know that if you learned in science class about, oh, a star's color corresponds to its age, and we have different kinds of stars that are different colors, also we can tell how far away stars are, you've got two awesome women scientists to thank for that. Henrietta Swan Levitt and Annie Jump Cannon, both awesome women of STEM in our history, also both deaf. I could go on and on about disabled histories, there's so much incredible stuff that disabled people have done and contributed to the history of the United States, but we don't seem to be learning it in school. And again, these are just two aspects of our society. I could go on about our sports, our news, our politics, but we'll just stick with that. What about tech? So I tried hard to find some hard numbers on what percent of tech workers identify as having a disability. And they're very hard to find, I did find one major tech company that did ask its employees who, if they identified as having a disability, and that was Slack. And before I go forward, thank you Slack for doing this. Now because you asked this question of your employees, we can have a conversation like this and use these numbers to move forward. 1.7% of Slack's workers identify as having a disability. Again, compare that to 19% as we see in the census. I'm not saying 19% is necessarily what we have to shoot for because many people who are disabled are very old and retired. Some of them have disabilities that won't let them work, but surely we can do better than under 2% in all of these situations. Given that disabled people are so erased from our culture, is it really so surprising they get erased from the work that we do? Is it really so surprising that they get erased from what our companies and teams prioritize? Now I'm going to move on from this though because I don't think this problem is quite as simple as if you're not doing accessible development, then it's because of ableism. There's some other reasons too. When I sat down again with Tim Springer, he said that a lot of the companies that he audits tend to have this sort of fix break mindset for accessible development. I've also seen some companies that sort of have a feature mindset where it's like, okay, on Monday we're going to make the home page screen reader readable and then on Tuesday we're going to work on something else or in a fix break mindset, okay, this link isn't coming up, we'll fix it and then we'll move on with our lives. I've got Tim to thank for this analogy. Accessibility is really more like security, which is that at no point do you reach a, do you get to the point where you're like, okay, site's secure, time to move on with our lives. It's something you've got to integrate into your workflow and it's always changing. You've got to keep thinking about it. But instead when we have this sort of short burst mindset where we deal with it and then we move on, you get situations where for instance about once every three years you go, oh shoot, our site's not accessible, let's outsource it to a third party. Thank you third party for taking care of this. Let's go on with our lives. I've also seen some companies do an accessibility hackathon. Hackathons are great if you've got like some kind of hair brained idea and you just want to see if it can work. Hackathons aren't super great if you're trying to make your site accessible for people with disabilities and do that kind of long term work that requires changing your workflow. Even accessibility hackathons where you're trying to make a new, existing technology is not super great because again from the first place, only 1.7% of people working in tech if we take Slack's numbers as an average, which is the best we can really do for now, then you're not going to be consulting very much with people with disabilities on what they need. I know this because about a few years ago I started learning sign language and one of the side effects I found out from learning ASL is that once a year someone sends you an article about somebody inventing sign language reading gloves. You could set your calendar to it to be honest. Once a year someone's going to send me this article about someone inventing this and they always want to know what I think and I can always point out to what deaf people have already said on the subject, which is that it's cool technology, it's a neat trick, it can't do anything that a piece of paper and a pen can do much faster, much more accurately and much cheaper. And again, stakeholders tend to have the same sort of short brisk mindset too. If your stakeholders only come to you once a year saying, by the way, is everything accessible, then suddenly, oh shoot, it's important, we have to work on it. If they're not going, usually not going to come to you every week and say, cool new feature, is it accessible? Cool new feature, is it accessible? So this is just sort of a structural thing that's in place that's keeping us from working on this stuff. There's also what we prioritize as developers. So I know I have some say in the tickets I can take on in my company, I imagine that's a common thing where, you know, for implementing some kind of new technology I might volunteer and say like, oh yeah, let me work on that so I can get familiar with it. And I got a lot of say in the stuff I do in my personal projects and usually the things I work on, before I work on it, it fits one of these three categories. One, it personally makes my life easier. It's so much fun to come to Sprint Review and be like, hey everybody, remember how we used to have to push to three different repos and wait for two different deploys and then we would see if what we're working on is working at all in the first place? Well, guess what? Now we can just test it locally. It's always great because the stakeholders are like, oh yeah, that's cool, you can work faster and all your teammates are like, whoa! Yes! All the high fives! Second, does it have a big impact? Does it shave a half second of time off the page load of your site? And last, does it look cool? You know, hey, I implemented a new dropdown, it's got a smooth animation, it fits in with the aesthetic of our website and this is also, this is, I found, is the reverse of what I said before. Your teammates go, oh yeah, that's pretty cool, good job Liz and all the stakeholders go, whoa! Awesome! Unfortunately, accessible development doesn't really take any of these boxes. Does it personally make our lives easier if only 1.7% of us identify as having a disability? Usually it's not going to be making our lives easier. Does it have a big impact? Even though we have disabled users for the internet and our site, we often don't because again, ableism tends to erase the perspectives of disabled people, we tend to not feel that kind of impact. And does it look cool? If anything, it unticks this box sometimes. I had to have a conversation with my team last year where I said, listen, sorry, I know we were really excited about this new tooltip feature that we wanted to implement, but it doesn't work with a screen reader so unfortunately we have to keep using our old clunky tooltips. And then finally, there's some structural problems in the way that we work that I want to address for starters. There's front end versus back end nonsense. If you are new enough to this industry to have avoided this, I am sorry for the nonsense I'm about to introduce into your life, but there is a perception in some corners of programming that unless you are personally building your code with 1s and 0s, you're not doing real code. You know, all that silly stuff we do in the front end with the HTML and the CSS, anybody can do that. It's super easy. Oh, my God, do I wish that were true? I say this as a front end dev. Because if this were true, every site on the internet would be 100% accessible. But you know, when you look at front end as like the easy stuff that we don't think about and that, you know, the less talented developers deal with, then you're less likely to prioritize it and that is where a lot of accessible development lives. There's also one last thing that I want to note that's just an interesting trend I found while I was researching this talk. We're going to do a quick experiment. Everybody close your eyes. Now I want you to raise your hand if sometime during your career you have ever copied and pasted a snippet of code from a tutorial or stack overflow into whatever it is you're working on. Just to build off it even. Keep your hand raised if you've done this in the past month. Okay, everybody look around. You're in good company. It's something we all do. It's something we've all done. And I've got an example up here of how an each-do loop works in the ER Bay that's an example of something when you're learning something, you might copy and paste it into your code. But if you look at that, you'll notice the HTML tags that get used in it are ULLI. And that's about as complicated as it usually gets in tutorials and stack overflow answers. Good semantic HTML is absolutely critical to having a good accessible website. And yet when all of the examples that we're looking at and that we're copying, pasting, and building off of are at their most complicated ULLs and LIs, then you're not going to have good semantic HTML on your website and you're not going to internalize in your mind that good code looks like proper semantic HTML. Okay, enough of that. Let's go into how we fix this. How do we move forward? And coming to this question, my first thought is, okay, well, who does this well? What industries are very good at accommodating people with disabilities? The unfortunate answer to that is pretty much nobody. So it's like, okay, well, who does this okay? And I could think of two major industries. One of them was architecture. The other one was education. There's a reason why public buildings that have been made after 1990 have hallways that are wide enough for wheelchairs to go through. There's a reason why if your child has a disability, you can go to their public school and say, I need this disability accommodated and you should be able to get that disability properly accommodated. Again, there's a difference between how things should be and the reality of how things are, but at least there's the expectation in both fields that it should happen this way. What do these two fields have in common? Well, for architecture, it's the Americans with Disabilities Act for education. The individuals with Disabilities Education Act. Big regulations that got passed that said this is the way things have to be done in this industry or there can be consequences, which leads to my first suggestion. Lobby for laws and policies that apply the ADA consistently across the Internet. I understand there might be a conception here that I'm wading into controversial territory since laws and policies and regulations, people tend to have strong feelings about how many is too many, but believe it or not, this is actually something that people from all corners of the political spectrum have been begging for for a long time and yet haven't gotten. Let me back up and explain why. In 1990, the Americans with Disabilities Act passes and about a couple years later, the Internet starts taking off in a big way. Since then, we really haven't been sure how to apply the ADA to the Internet. Let me just give you one taste of some of the complications that arise. One of the big key features of the Americans with Disabilities Act is that places of public accommodation, that's the quote, must be made accessible for people with disabilities. Well, where is the physical place when we talk about the Internet? So let's say I'm a disabled person on vacation in France and I'm going to use RailsConf as my example. I don't know if their website is accessible or not. I didn't check. RailsConf says, our tickets are on sale. Go buy them. And I try to buy them, but because the site's inaccessible, I can't and all the tickets sell out. Because I was in France, does the ADA still apply to me? Okay. If it's not the physical location of the computer, is it where the servers are located? If I am on my phone scrolling through it and walking down the street, does the place of public accommodation move with me? We're really not sure. So there's been industry leaders went to, first they went to Congress and said, please, just tell us, pass a law that tells us how the ADA should apply to the Internet. And you'll be shocked to hear Congress did not succeed in doing that. So they went to the DOJ and said, just give us your best guess about how the ADA should be applied to the Internet. And the Obama administration, a DOJ, said, okay, yeah, we'll do that. But then they didn't. I think a couple of things happened. For one, the DOJ found that, oh, wow, this is very technical stuff. It's hard to write. Oh, wow, the Internet changes a lot every couple of years, so it's hard to write consistent regulations and also it just got put on the back burner. Anyway, an administration change happened and for a while they were still committed to doing this, but last year they said, you know, we're giving up. We're not really sure how the ADA applies to the Internet. You're on your own. So please, after this talk, call your member of Congress or possibly the DOJ and say, give us some guidelines for how the ADA should apply to the Internet because right now we don't really know. Also while you're at it, ask your representatives to have literally any policy whatsoever on disabled people on their website. In the 2016 election of the four major candidates in the final election, only one had a section on their website about their policies for people with disabilities. I'm not going to say who because that's not important. The important is you had three major candidates who had nothing on their website about 19% of America and again, to put that number in perspective, our best guesses as far as we can tell for the number of people in America who are undocumented is 3% to 4%. And yet every candidate has something to say about what should be done about undocumented immigrants. This is again across country, across county, oh goodness, cross party and also multi-country part problem. So your representative almost certainly doesn't have a section on their website about people with disabilities. Call them and ask for it because having something, anything, gives reporters something to ask questions about. It gives activists something to hold them accountable to even if it's not a very good thing. Maybe then once we have these in place, we can start being an industry that's more like architecture or education where there's the expectation that of course we're going to be building accessible stuff. Okay, at the company level, it can be difficult to convince your bosses that we need to work on accessibility related work, so let's start with the first one, which is a carrot. Accessibility will almost always improve your SEO. Google's bots do not have eyes. They do not have hands to use a mouse. All they can do is parse through your HTML, CSS, possibly your JavaScript that comes up on your website and make their best guess as to what's there. And if none of your images have alt attributes, they don't know what's in them. So if you do this work, you will almost certainly see a bump up in your SEO. You can also use a mission statement. Almost every company has a mission statement with the words everybody or our users in it. So if you come to them and say, do we really mean everybody or do we mean 81% of everybody? Also this is another tip from Tim. He said reference a real user experience. When you say, oh, our homepage is in screen reader accessible, that kind of feels sterile. If you say, we have users out there who use assistive technology and they can't access our homepage. There's no reason this should be a thing. We can do something about it. It feels a lot more real. Use a real user story. And then finally, we're going to talk about the legal boogeyman. We've exhausted carrots. Let's go to sticks. About five years ago, a surf by lawsuit, as I heard a lawyer call it once, for accessibility was pretty rare. They are picking up in frequency, which is where someone sends an automated screen reader through your site. It gets caught in a keyboard trap or something. And they go up to you and say, give us this amount of money or we're going to sue you. Usually you settle, they go away. You can preempt that. And again, these are becoming more and more common if you have an accessible website to begin with. Also, let's talk a little bit about the Unruh Act. I don't have as much time as I want to to go into this in depth. But California passed a law that's called the Unruh Act that does a lot of things. But one of the big things that does is it says anything touching commerce in the state of California cannot discriminate against people with disabilities. So let me ask you, your company, its website, doesn't get used by people in the state of California? If the answer is yes and it's not accessible, you might be liable for problems under the Unruh Act. And what makes the Unruh Act unique is it allows for monetary damages per infraction. So let me ask you something. Could you afford to, it's up to $5,000. Could you afford to pay $5,000 to everybody in California who can't use your website? The answer is no. You might want to look into stuff. Just as a side note, pretty much any example you've ever heard of of a company getting in trouble for not having an accessible website, they weren't in trouble with the ADA. They were in trouble with the Unruh Act. That's what happened to Target. It's a really cool story, but I don't have time to go into it. At the team level, keyboard-only Tuesday is an absolute must, or Wednesday or whenever it works for you. If you can make these problems personally inconvenient to you, you will find that they get prioritized a lot more. To the managers in the room, praise and incentivize accessibility-related work. It kind of stinks when you're at Sprint Review and someone's like, I made a cool new dropdown. I shaved a half second off the site time. And you're like, a screen reader can now get through our home page and read it intelligibly. I can't tell you what it's meant to me when I've had managers say, Liz, that is so awesome and I know it's really hard work. I'm so glad you did it. If you do that, you're more likely to see this work continue to happen. Put seniors in charge of teaching A11y to juniors. Anybody here who has ever volunteered at a boot camp will tell you one of the best ways to learn something is to teach it. You can do this on your team. If you put your seniors, if you make your seniors responsible for when your juniors submit a pull request that's not up to stuff in accessibility, then I think you will find that the whole team's knowledge goes up. And then finally, go to, I'm sorry, not finally, go to an A11y conference. This is the part of the talk where I admit I've been a little sneaky. Remember those talks I said at the start of this talk ages and ages ago? Accessible syntax where it lives, what it looks like, how I hacked NVDA into living rails? Well, I know these are good talks because I saw versions of them at a conference I went to last year called Accessing Higher Ground. Now this conference has a very heavy education bit because, again, education is one of the fields where accessibility gets taken more seriously. But you can totally, they're still talking about a ton of things that are pertinent to the stuff we do. You know that great feeling when you go to a conference and your brain's just spilling out of your ears because you learned so much? That's totally how I felt last year. If you send somebody to this conference, I think you will find that they learn a lot and it's very useful. Also look into automated testing and linting. It's easy to do accessibility related work if a machine's doing it for you. If you just say the stuff that goes on our website, if it has an image, it needs to have an alt attribute and it just gets caught in the linter before you can put a pull request, you will find that images with alt attributes go way up. Okay. Last, I want to talk about at the personal level, expand by Twitter. Like I said, one of the most pernicious ways that ableism impacts all of us is that it erases disabled people. Well, guess what? There's things that you can do to undo some of that damage. All of these are organizations that deal a lot with disability rights or accessible development. There's also a lot of activists out there, individual activists who work for rights for disabled people. I didn't want to put them up here in case this talk ends up on some of the less pleasant places of the internet and I didn't want them harassed, but they're easy to find if you look for them. Also get out into meat space out here with the rest of us. Anybody here ever been to an ASL poetry slam? They're amazing. They are just the coolest thing you can possibly imagine. And they're usually interpreted so you probably won't feel as left out as you think. Just bring a piece of paper and a pencil and you'll find you can communicate with people next to you if you want to. A11 Y meetups are also great. We have them in New York City. I imagine that's probably true of other major metropolitan areas. Even if it's something that's not related to what you do, like, hey, I invented a new Braille reader. Go, learn something. It's really neat. By the way, everything that I'm talking about right now does not just apply to people with disabilities. Get people who are not like you into your online presence and into your life. And I think you will find that you are a better person and also a better developer. You'll start catching things like, for example, oh, our company only has fire sales that start and end on the same day on Saturdays. You know what? None of my Orthodox Jewish friends are ever going to be able to take advantage of these sales. Maybe we should vary the day. Or hey, we've got all these avatars for people to use on our website. But you know what? Not one of them wears hijab or a hearing aid. Maybe we can add a few more so that everybody can see themselves. You're going to start catching these things if you have people who are not like you in your life. Okay. Finally, I'm cognizant that I am at RailsConf. And so I am probably talking to some of the foremost Rails podcasters, Rails bloggers, Rails vloggers out there. So let me ask you something. Accessible development starts at home. If you run a podcast, do you post a transcript of that podcast after the fact so that dev developers can take advantage of it? If you run a, put videos on YouTube of coding, do you put captions on those videos or do you rely on the automatic generated ones of YouTube that are commonly called craptions by the dev community to give you an idea of how good they are? If you run a blog, one last time you did an accessibility check on your site, even if you, oh, and also the examples that you used, like I said before, do they use different kinds of semantic HTML or is it all divs and spans? Even if you just tweet about code, I can't tell you the number of times I've been working. I'm super frustrated. Take a break, go on Twitter, and it's like, oh, man, somebody else is having the same problems I have. In this case, oh, those merge, those Git merge feels, I think we all know those Git merge feels. You push to a base branch, but when you're cleaning a merge conflict, but somebody else pushed to it too and now you've got a second merge conflict, it's like, anyway, you can totally, so I, okay, getting ahead of myself. It's made me feel like, oh, other people have these problems too. I still belong in this industry. It's not because I'm stupid that I'm having these problems or what have you. Disabled developers want to feel that same kind of inclusion too. And did you know Twitter has image descriptions? They don't, they're not turned on by default. You have to go into settings to turn them on, but you can totally write an image description on anything you tweet about and make the Internet a more accessible place in your home, in your own backyard. Okay, I'm going to end with some quick resources. I thought about doing a gigantic resources slide, but really, you only need these three. One is Google.com. Anything I am talking about, you can find on Google, and I know this because I use Google to find a lot of the things I'm talking about today. So like I said, there is no legal consensus on what an ADA compliant Internet should be, but the guideline that's commonly accepted by our industry is the WCAG 2.0 guidelines. They recently put out the WCAG 2.1, but it's probably going to be about a year before that's adopted as a standard, and this has a lot more documentation to it. So that's at www.w3.org. WCAG 2.0. And then finally, this last resource is a monster list of every single kind of accessible development related topic you can think of. The topic of this talk that I'm giving today is actually a little deceptive because in reality, there are some people doing accessibility 102 because there are people who are programming the screen readers and making sure Chrome doesn't break when you hit a keyboard button. And a lot of them have blogs and Twitter where they talk about the work they do. Again, this is a gigantic last list. It's pauljadam.com. It's resources.html, you can spend days getting lost in here. I know this because I have. Check it out and see some of the amazing work people are doing. Okay, that actually is the end of my talk. Thank you so much. I'll see you later afterwards if anybody has any questions, but thank you for coming.
 Okay, let's get started.  I'm starting right away because again we've got a lot of ground to cover.  Hi everybody, welcome to my talk.  My name is Liz.  I work at Vitals.  That's my Twitter handle.  If there are warning, it's a lot of Star Trek and Dungeons and Dragons if you choose to  follow me, but if you do, great.  Today we're going to talk about why we never get to Web Accessibility 102.  Now before I start, I have a couple disclaimers that I need to cover.  For one, I do not identify as disabled.  I am coming at this from the perspective of an able-bodied person who works a lot in  accessible development.  There's a lot of great disabled developers and internet users who have said a lot of  the things I'm going to say today.  I'm going to give you some resources at the end of this talk so you can go find them yourselves  and read what they have to say.  Disclaimer number two, I'm going to touch very briefly on some legal stuff here, but  in case it's not obvious, I am not a lawyer.  Even if I were, I am not your lawyer.  You should not be taking legal advice from me.  Disclaimer number three, this is going to be a very US-focused talk.  I'm cognizant.  There's people here from other countries, but I'm not as familiar with other countries  as I am with the Americans with Disabilities Act.  So although I hope there's still some things I'll be talking about today that apply pretty  widely.  And then finally, there's currently a debate in the disabled community over the terminology,  specifically disabled people versus people with disabilities.  I'm going to be using both interchangeably because I've met people who feel strongly  both one way and the other.  I'm not here to pick a side on that issue, but if I say a term that's not your preferred  term, then if you identify disabled, I apologize.  Okay, so let's start with why I'm here.  Like many of you, I saw this tweet back in December opening the RailsConf call for proposals  and I thought, okay, am I working on anything cool that I think the Rails community might  want to see?  And over the past year and a half, I've been really ramping up into accessible development  at my company.  So I thought, okay, how about I talk about that?  In fact, how about I give a presentation I've already given at my company to various teams  in various settings?  And that presentation goes like this.  Welcome to Accessibility 101.  Disabled people use your website.  Some use screen readers.  Some are colorblind.  Try out your website using just the keyboard.  You get the idea.  But before I was in software development, my background was in academia.  And one of the cardinal rules of academia is try not to say things that other people  have already said.  And while this is an important topic, and I'm sure there's people here who could learn  something from it, this is definitely already been said.  And not just in general at this conference.  You can see it in 2017, 2015, 2014, all the way back to 2006.  Now I'm not trying to imply that these are needlessly repetitive.  I watched all of these in prep for this talk.  Just the different perspectives alone that the different developers came with towards  this topic makes it worth your while to check them out.  Also it's not necessarily a bad thing to say the same thing at a conference.  I mean, heaven knows we get to talk like this about once a year.  How Docker improved my Rails app, cured my acne, saved my marriage, broken world peace.  But here's the thing.  Take Docker as an example.  Yes, we get to talk like this pretty frequently.  But it's complemented by talks like this.  Deep dive into Docker containers for Rails developers.  Notice the words one, deep dive, and two, four, Rails developers.  So something that's very specific and that requires your own, a lot of expertise into  a subject.  And also something tailored toward a particular audience.  And when we just teach one-to-one over and over again, we don't seem to get talks like  this that are catered to our audiences and that go into sort of deep, divey things.  And what kinds of talks am I talking about?  How about accessible syntax?  Where it lives, what it looks like.  Did you know that if you have a strike, if you need a strike through somewhere on your  website, if you put that strike, make that strike through happen through DEL tags or  make that strike through happen through text decoration line through in your CSS, it can  impact how certain screen reader browser combinations read it.  Which is important if you've got anything like this on your website, where it's really  important that the screen reader says what's got a line through in it, what's the real  price of whatever it is you're working on.  Okay, but Liz, this is RailsConf.  How about a Rails specific talk?  Okay.  How I hacked NVDA into loving Rails and Rails into loving NVDA.  NVDA is the only widely used open source screen reader.  So you can crack it open, get an idea of both how NVDA works and how your average screen  reader works too.  So you can totally submit a pull request.  Let's say you happen to have a lot of specialized knowledge about a certain extremely popular  framework.  You can submit a PR to NVDA to make it work better with your framework or a PR to Rails  to make it work better with NVDA or screen readers in general.  But we don't seem to get specific talks like this.  And you know, when I, I'm sorry.  So my first idea of this talk was to say, oh well, it's time to throw off 101 and start  getting into 102.  And then I sat down with Tim Springer.  Tim Springer is the CEO of a company called Level Access.  They do a lot of stuff.  They will audit your company website for accessibility.  They have great training programs, educational materials.  They're great.  You should check them out after this talk.  And I said, you know, Tim, don't you think it's time to just stop doing 101?  And for starters, he pointed out for one, it's not important for everybody to have  102-level knowledge, which is fair.  You know, not everybody who uses Docker can give a talk at RailsConf about Docker.  But also, when you go into a website, the top 10 out of the 100 most prevalent accessibility  related bugs that an organization has, usually 80% of the access, are going to be 80% of  the accessibility issues in total.  And it's the stuff you know about providing labels for form fields, providing image alt  attributes.  So clearly, we keep giving these 101 talks, but we're not implementing that 101 knowledge.  So this is where the liberal arts part of my brain sort of kicks into overdrive because  if we're, my background was in English and also education.  And if we're trying to pass on knowledge and we're not doing it successfully, it's like,  you know, why?  Why is this happening?  And I found a fairly simple answer to this, which is that we develop expertise in the  things we work on.  And we're just not sort of putting in the work into accessible development.  Okay, now we got to the bottom of that.  Thank you so much for coming to my talk.  Oh, man.  Oh, darn, I've got 32 minutes left.  Okay.  So I guess we can go into the second question this led me to.  Why aren't we doing the work to get better at accessible development?  And this turned out to be a bit of a complicated question with a lot of different factors coming  into it.  And I'm going to start with the least comfortable one so it gets better from here on out.  And that is ableism.  Every single person in this room, without exception, and anybody watching this video  later, is, grew up in an ableist society.  None of us chose to do that, but we can have a say in how ableist our society is going  forward, but we can get to that later.  One of the most pernicious ways that ableism impacts all of us is that it erases disabled  people.  It erases their presence.  It erases their voices, their stories, their perspectives, their needs, even, again, their  presence.  And we're going to do a quick experiment.  The 2010 census asked the people who took it if they identified as having a disability.  Now to be clear, this is just people who self-identify as having a disability and are comfortable  writing that on a census, which is in itself a bit problematic, which we'll get to in  a second.  And we're going to do an experiment.  I want you to raise your hand if the number that I say to you sounds too low, and then  put it down if you think it sounds too high.  Ready?  Let's start with one in 100.  Does that sound too low?  Raise your hand.  Okay, one in 50.  One in 10.  One in five.  If your hand's down now, you're finally right.  Nineteen percent of people in America identify as having a disability.  And that's probably an undercount.  So for one, of course, there's people who just don't feel comfortable disclosing on  a form that they have a disability.  Certain disabilities are chronically undercounted in certain communities.  Autism is very, very undercounted in girls and women.  And there's also just people who say, yes, you know, it's hard to get out of bed every  day because my pain is so bad, but, you know, I'm not like disabled.  Also, I'm sure there's people at this conference, possibly in this room, who are colorblind  and might not consider themselves disabled, even though that's considered a disability  that we have to work on in accessible development.  But we're going to stick with 19 percent because that's a nice, hard meeting number  that we can hold on to for later.  Bearing that in mind, I'm just going to go through two aspects of the society that we  went into, and they're very formative aspects, that's stuff that we grew up with, to give  you an idea of how ableism works.  So let's start with entertainment.  In the 2017-2018 primetime television season of the regular recurring characters, 1.8 percent  had a disability.  Furthermore, according to the Washington Post, all the characters that we see in television  and in movies who have a disability, I think it was 95 percent, are played by actors who  don't have a disability.  Let's also talk a bit about education.  I am sure many of us here learned about Helen Keller in school, and you probably learned  that FDR used a wheelchair.  Did you know that Harriet Tubman had a seizure disorder?  Did you know that if you learned in science class about, oh, a star's color corresponds  to its age, and we have different kinds of stars that are different colors, also we can  tell how far away stars are, you've got two awesome women scientists to thank for that.  Henrietta Swan Levitt and Annie Jump Cannon, both awesome women of STEM in our history,  also both deaf.  I could go on and on about disabled histories, there's so much incredible stuff that disabled  people have done and contributed to the history of the United States, but we don't seem to  be learning it in school.  And again, these are just two aspects of our society.  I could go on about our sports, our news, our politics, but we'll just stick with that.  What about tech?  So I tried hard to find some hard numbers on what percent of tech workers identify as having  a disability.  And they're very hard to find, I did find one major tech company that did ask its employees  who, if they identified as having a disability, and that was Slack.  And before I go forward, thank you Slack for doing this.  Now because you asked this question of your employees, we can have a conversation like  this and use these numbers to move forward.  1.7% of Slack's workers identify as having a disability.  Again, compare that to 19% as we see in the census.  I'm not saying 19% is necessarily what we have to shoot for because many people who are  disabled are very old and retired.  Some of them have disabilities that won't let them work, but surely we can do better  than under 2% in all of these situations.  Given that disabled people are so erased from our culture, is it really so surprising they  get erased from the work that we do?  Is it really so surprising that they get erased from what our companies and teams prioritize?  Now I'm going to move on from this though because I don't think this problem is quite  as simple as if you're not doing accessible development, then it's because of ableism.  There's some other reasons too.  When I sat down again with Tim Springer, he said that a lot of the companies that he audits  tend to have this sort of fix break mindset for accessible development.  I've also seen some companies that sort of have a feature mindset where it's like, okay,  on Monday we're going to make the home page screen reader readable and then on Tuesday  we're going to work on something else or in a fix break mindset, okay, this link isn't  coming up, we'll fix it and then we'll move on with our lives.  I've got Tim to thank for this analogy.  Accessibility is really more like security, which is that at no point do you reach a,  do you get to the point where you're like, okay, site's secure, time to move on with  our lives.  It's something you've got to integrate into your workflow and it's always changing.  You've got to keep thinking about it.  But instead when we have this sort of short burst mindset where we deal with it and then  we move on, you get situations where for instance about once every three years you go, oh shoot,  our site's not accessible, let's outsource it to a third party.  Thank you third party for taking care of this.  Let's go on with our lives.  I've also seen some companies do an accessibility hackathon.  Hackathons are great if you've got like some kind of hair brained idea and you just want  to see if it can work.  Hackathons aren't super great if you're trying to make your site accessible for people with  disabilities and do that kind of long term work that requires changing your workflow.  Even accessibility hackathons where you're trying to make a new, existing technology  is not super great because again from the first place, only 1.7% of people working in  tech if we take Slack's numbers as an average, which is the best we can really do for now,  then you're not going to be consulting very much with people with disabilities on what  they need.  I know this because about a few years ago I started learning sign language and one of  the side effects I found out from learning ASL is that once a year someone sends you  an article about somebody inventing sign language reading gloves.  You could set your calendar to it to be honest.  Once a year someone's going to send me this article about someone inventing this and they  always want to know what I think and I can always point out to what deaf people have  already said on the subject, which is that it's cool technology, it's a neat trick, it  can't do anything that a piece of paper and a pen can do much faster, much more accurately  and much cheaper.  And again, stakeholders tend to have the same sort of short brisk mindset too.  If your stakeholders only come to you once a year saying, by the way, is everything accessible,  then suddenly, oh shoot, it's important, we have to work on it.  If they're not going, usually not going to come to you every week and say, cool new feature,  is it accessible?  Cool new feature, is it accessible?  So this is just sort of a structural thing that's in place that's keeping us from working  on this stuff.  There's also what we prioritize as developers.  So I know I have some say in the tickets I can take on in my company, I imagine that's  a common thing where, you know, for implementing some kind of new technology I might volunteer  and say like, oh yeah, let me work on that so I can get familiar with it.  And I got a lot of say in the stuff I do in my personal projects and usually the things  I work on, before I work on it, it fits one of these three categories.  One, it personally makes my life easier.  It's so much fun to come to Sprint Review and be like, hey everybody, remember how we  used to have to push to three different repos and wait for two different deploys and then  we would see if what we're working on is working at all in the first place?  Well, guess what?  Now we can just test it locally.  It's always great because the stakeholders are like, oh yeah, that's cool, you can work  faster and all your teammates are like, whoa!  Yes!  All the high fives!  Second, does it have a big impact?  Does it shave a half second of time off the page load of your site?  And last, does it look cool?  You know, hey, I implemented a new dropdown, it's got a smooth animation, it fits in with  the aesthetic of our website and this is also, this is, I found, is the reverse of what I  said before.  Your teammates go, oh yeah, that's pretty cool, good job Liz and all the stakeholders  go, whoa!  Awesome!  Unfortunately, accessible development doesn't really take any of these boxes.  Does it personally make our lives easier if only 1.7% of us identify as having a disability?  Usually it's not going to be making our lives easier.  Does it have a big impact?  Even though we have disabled users for the internet and our site, we often don't because  again, ableism tends to erase the perspectives of disabled people, we tend to not feel that  kind of impact.  And does it look cool?  If anything, it unticks this box sometimes.  I had to have a conversation with my team last year where I said, listen, sorry, I know  we were really excited about this new tooltip feature that we wanted to implement, but it  doesn't work with a screen reader so unfortunately we have to keep using our old clunky tooltips.  And then finally, there's some structural problems in the way that we work that I want  to address for starters.  There's front end versus back end nonsense.  If you are new enough to this industry to have avoided this, I am sorry for the nonsense  I'm about to introduce into your life, but there is a perception in some corners of programming  that unless you are personally building your code with 1s and 0s, you're not doing real  code.  You know, all that silly stuff we do in the front end with the HTML and the CSS, anybody  can do that.  It's super easy.  Oh, my God, do I wish that were true?  I say this as a front end dev.  Because if this were true, every site on the internet would be 100% accessible.  But you know, when you look at front end as like the easy stuff that we don't think about  and that, you know, the less talented developers deal with, then you're less likely to prioritize  it and that is where a lot of accessible development lives.  There's also one last thing that I want to note that's just an interesting trend I found  while I was researching this talk.  We're going to do a quick experiment.  Everybody close your eyes.  Now I want you to raise your hand if sometime during your career you have ever copied and  pasted a snippet of code from a tutorial or stack overflow into whatever it is you're  working on.  Just to build off it even.  Keep your hand raised if you've done this in the past month.  Okay, everybody look around.  You're in good company.  It's something we all do.  It's something we've all done.  And I've got an example up here of how an each-do loop works in the ER Bay that's an  example of something when you're learning something, you might copy and paste it into  your code.  But if you look at that, you'll notice the HTML tags that get used in it are ULLI.  And that's about as complicated as it usually gets in tutorials and stack overflow answers.  Good semantic HTML is absolutely critical to having a good accessible website.  And yet when all of the examples that we're looking at and that we're copying, pasting,  and building off of are at their most complicated ULLs and LIs, then you're not going to have  good semantic HTML on your website and you're not going to internalize in your mind that  good code looks like proper semantic HTML.  Okay, enough of that.  Let's go into how we fix this.  How do we move forward?  And coming to this question, my first thought is, okay, well, who does this well?  What industries are very good at accommodating people with disabilities?  The unfortunate answer to that is pretty much nobody.  So it's like, okay, well, who does this okay?  And I could think of two major industries.  One of them was architecture.  The other one was education.  There's a reason why public buildings that have been made after 1990 have hallways that  are wide enough for wheelchairs to go through.  There's a reason why if your child has a disability, you can go to their public school and say,  I need this disability accommodated and you should be able to get that disability properly  accommodated.  Again, there's a difference between how things should be and the reality of how things are,  but at least there's the expectation in both fields that it should happen this way.  What do these two fields have in common?  Well, for architecture, it's the Americans with Disabilities Act for education.  The individuals with Disabilities Education Act.  Big regulations that got passed that said this is the way things have to be done in  this industry or there can be consequences, which leads to my first suggestion.  Lobby for laws and policies that apply the ADA consistently across the Internet.  I understand there might be a conception here that I'm wading into controversial territory  since laws and policies and regulations, people tend to have strong feelings about how many  is too many, but believe it or not, this is actually something that people from all corners  of the political spectrum have been begging for for a long time and yet haven't gotten.  Let me back up and explain why.  In 1990, the Americans with Disabilities Act passes and about a couple years later, the  Internet starts taking off in a big way.  Since then, we really haven't been sure how to apply the ADA to the Internet.  Let me just give you one taste of some of the complications that arise.  One of the big key features of the Americans with Disabilities Act is that places of public  accommodation, that's the quote, must be made accessible for people with disabilities.  Well, where is the physical place when we talk about the Internet?  So let's say I'm a disabled person on vacation in France and I'm going to use RailsConf as  my example.  I don't know if their website is accessible or not.  I didn't check.  RailsConf says, our tickets are on sale.  Go buy them.  And I try to buy them, but because the site's inaccessible, I can't and all the tickets  sell out.  Because I was in France, does the ADA still apply to me?  Okay.  If it's not the physical location of the computer, is it where the servers are located?  If I am on my phone scrolling through it and walking down the street, does the place of  public accommodation move with me?  We're really not sure.  So there's been industry leaders went to, first they went to Congress and said, please,  just tell us, pass a law that tells us how the ADA should apply to the Internet.  And you'll be shocked to hear Congress did not succeed in doing that.  So they went to the DOJ and said, just give us your best guess about how the ADA should  be applied to the Internet.  And the Obama administration, a DOJ, said, okay, yeah, we'll do that.  But then they didn't.  I think a couple of things happened.  For one, the DOJ found that, oh, wow, this is very technical stuff.  It's hard to write.  Oh, wow, the Internet changes a lot every couple of years, so it's hard to write consistent  regulations and also it just got put on the back burner.  Anyway, an administration change happened and for a while they were still committed  to doing this, but last year they said, you know, we're giving up.  We're not really sure how the ADA applies to the Internet.  You're on your own.  So please, after this talk, call your member of Congress or possibly the DOJ and say, give  us some guidelines for how the ADA should apply to the Internet because right now we  don't really know.  Also while you're at it, ask your representatives to have literally any policy whatsoever on  disabled people on their website.  In the 2016 election of the four major candidates in the final election, only one had a section  on their website about their policies for people with disabilities.  I'm not going to say who because that's not important.  The important is you had three major candidates who had nothing on their website about 19%  of America and again, to put that number in perspective, our best guesses as far as we  can tell for the number of people in America who are undocumented is 3% to 4%.  And yet every candidate has something to say about what should be done about undocumented  immigrants.  This is again across country, across county, oh goodness, cross party and also multi-country  part problem.  So your representative almost certainly doesn't have a section on their website about people  with disabilities.  Call them and ask for it because having something, anything, gives reporters something to ask  questions about.  It gives activists something to hold them accountable to even if it's not a very good  thing.  Maybe then once we have these in place, we can start being an industry that's more like  architecture or education where there's the expectation that of course we're going to  be building accessible stuff.  Okay, at the company level, it can be difficult to convince your bosses that we need to work  on accessibility related work, so let's start with the first one, which is a carrot.  Accessibility will almost always improve your SEO.  Google's bots do not have eyes.  They do not have hands to use a mouse.  All they can do is parse through your HTML, CSS, possibly your JavaScript that comes  up on your website and make their best guess as to what's there.  And if none of your images have alt attributes, they don't know what's in them.  So if you do this work, you will almost certainly see a bump up in your SEO.  You can also use a mission statement.  Almost every company has a mission statement with the words everybody or our users in it.  So if you come to them and say, do we really mean everybody or do we mean 81% of everybody?  Also this is another tip from Tim.  He said reference a real user experience.  When you say, oh, our homepage is in screen reader accessible, that kind of feels sterile.  If you say, we have users out there who use assistive technology and they can't access  our homepage.  There's no reason this should be a thing.  We can do something about it.  It feels a lot more real.  Use a real user story.  And then finally, we're going to talk about the legal boogeyman.  We've exhausted carrots.  Let's go to sticks.  About five years ago, a surf by lawsuit, as I heard a lawyer call it once, for accessibility  was pretty rare.  They are picking up in frequency, which is where someone sends an automated screen reader  through your site.  It gets caught in a keyboard trap or something.  And they go up to you and say, give us this amount of money or we're going to sue you.  Usually you settle, they go away.  You can preempt that.  And again, these are becoming more and more common if you have an accessible website to  begin with.  Also, let's talk a little bit about the Unruh Act.  I don't have as much time as I want to to go into this in depth.  But California passed a law that's called the Unruh Act that does a lot of things.  But one of the big things that does is it says anything touching commerce in the state  of California cannot discriminate against people with disabilities.  So let me ask you, your company, its website, doesn't get used by people in the state of  California?  If the answer is yes and it's not accessible, you might be liable for problems under the  Unruh Act.  And what makes the Unruh Act unique is it allows for monetary damages per infraction.  So let me ask you something.  Could you afford to, it's up to $5,000.  Could you afford to pay $5,000 to everybody in California who can't use your website?  The answer is no.  You might want to look into stuff.  Just as a side note, pretty much any example you've ever heard of of a company getting  in trouble for not having an accessible website, they weren't in trouble with the ADA.  They were in trouble with the Unruh Act.  That's what happened to Target.  It's a really cool story, but I don't have time to go into it.  At the team level, keyboard-only Tuesday is an absolute must, or Wednesday or whenever  it works for you.  If you can make these problems personally inconvenient to you, you will find that they  get prioritized a lot more.  To the managers in the room, praise and incentivize accessibility-related work.  It kind of stinks when you're at Sprint Review and someone's like, I made a cool new dropdown.  I shaved a half second off the site time.  And you're like, a screen reader can now get through our home page and read it intelligibly.  I can't tell you what it's meant to me when I've had managers say, Liz, that is so awesome  and I know it's really hard work.  I'm so glad you did it.  If you do that, you're more likely to see this work continue to happen.  Put seniors in charge of teaching A11y to juniors.  Anybody here who has ever volunteered at a boot camp will tell you one of the best ways  to learn something is to teach it.  You can do this on your team.  If you put your seniors, if you make your seniors responsible for when your juniors submit a  pull request that's not up to stuff in accessibility, then I think you will find that the whole team's  knowledge goes up.  And then finally, go to, I'm sorry, not finally, go to an A11y conference.  This is the part of the talk where I admit I've been a little sneaky.  Remember those talks I said at the start of this talk ages and ages ago?  Accessible syntax where it lives, what it looks like, how I hacked NVDA into living  rails?  Well, I know these are good talks because I saw versions of them at a conference I went  to last year called Accessing Higher Ground.  Now this conference has a very heavy education bit because, again, education is one of the  fields where accessibility gets taken more seriously.  But you can totally, they're still talking about a ton of things that are pertinent to  the stuff we do.  You know that great feeling when you go to a conference and your brain's just spilling  out of your ears because you learned so much?  That's totally how I felt last year.  If you send somebody to this conference, I think you will find that they learn a lot  and it's very useful.  Also look into automated testing and linting.  It's easy to do accessibility related work if a machine's doing it for you.  If you just say the stuff that goes on our website, if it has an image, it needs to have  an alt attribute and it just gets caught in the linter before you can put a pull request,  you will find that images with alt attributes go way up.  Okay.  Last, I want to talk about at the personal level, expand by Twitter.  Like I said, one of the most pernicious ways that ableism impacts all of us is that it  erases disabled people.  Well, guess what?  There's things that you can do to undo some of that damage.  All of these are organizations that deal a lot with disability rights or accessible development.  There's also a lot of activists out there, individual activists who work for rights for  disabled people.  I didn't want to put them up here in case this talk ends up on some of the less pleasant  places of the internet and I didn't want them harassed, but they're easy to find if you  look for them.  Also get out into meat space out here with the rest of us.  Anybody here ever been to an ASL poetry slam?  They're amazing.  They are just the coolest thing you can possibly imagine.  And they're usually interpreted so you probably won't feel as left out as you think.  Just bring a piece of paper and a pencil and you'll find you can communicate with people  next to you if you want to.  A11 Y meetups are also great.  We have them in New York City.  I imagine that's probably true of other major metropolitan areas.  Even if it's something that's not related to what you do, like, hey, I invented a new  Braille reader.  Go, learn something.  It's really neat.  By the way, everything that I'm talking about right now does not just apply to people with  disabilities.  Get people who are not like you into your online presence and into your life.  And I think you will find that you are a better person and also a better developer.  You'll start catching things like, for example, oh, our company only has fire sales that start  and end on the same day on Saturdays.  You know what?  None of my Orthodox Jewish friends are ever going to be able to take advantage of these  sales.  Maybe we should vary the day.  Or hey, we've got all these avatars for people to use on our website.  But you know what?  Not one of them wears hijab or a hearing aid.  Maybe we can add a few more so that everybody can see themselves.  You're going to start catching these things if you have people who are not like you in  your life.  Okay.  Finally, I'm cognizant that I am at RailsConf.  And so I am probably talking to some of the foremost Rails podcasters, Rails bloggers,  Rails vloggers out there.  So let me ask you something.  Accessible development starts at home.  If you run a podcast, do you post a transcript of that podcast after the fact so that dev  developers can take advantage of it?  If you run a, put videos on YouTube of coding, do you put captions on those videos or do you  rely on the automatic generated ones of YouTube that are commonly called craptions by the  dev community to give you an idea of how good they are?  If you run a blog, one last time you did an accessibility check on your site, even if you,  oh, and also the examples that you used, like I said before, do they use different kinds  of semantic HTML or is it all divs and spans?  Even if you just tweet about code, I can't tell you the number of times I've been working.  I'm super frustrated.  Take a break, go on Twitter, and it's like, oh, man, somebody else is having the same problems  I have.  In this case, oh, those merge, those Git merge feels, I think we all know those Git merge  feels.  You push to a base branch, but when you're cleaning a merge conflict, but somebody else  pushed to it too and now you've got a second merge conflict, it's like, anyway, you can  totally, so I, okay, getting ahead of myself.  It's made me feel like, oh, other people have these problems too.  I still belong in this industry.  It's not because I'm stupid that I'm having these problems or what have you.  Disabled developers want to feel that same kind of inclusion too.  And did you know Twitter has image descriptions?  They don't, they're not turned on by default.  You have to go into settings to turn them on, but you can totally write an image description  on anything you tweet about and make the Internet a more accessible place in your home, in your  own backyard.  Okay, I'm going to end with some quick resources.  I thought about doing a gigantic resources slide, but really, you only need these three.  One is Google.com.  Anything I am talking about, you can find on Google, and I know this because I use Google  to find a lot of the things I'm talking about today.  So like I said, there is no legal consensus on what an ADA compliant Internet should be,  but the guideline that's commonly accepted by our industry is the WCAG 2.0 guidelines.  They recently put out the WCAG 2.1, but it's probably going to be about a year before that's  adopted as a standard, and this has a lot more documentation to it.  So that's at www.w3.org.  WCAG 2.0.  And then finally, this last resource is a monster list of every single kind of accessible  development related topic you can think of.  The topic of this talk that I'm giving today is actually a little deceptive because in  reality, there are some people doing accessibility 102 because there are people who are programming  the screen readers and making sure Chrome doesn't break when you hit a keyboard button.  And a lot of them have blogs and Twitter where they talk about the work they do.  Again, this is a gigantic last list.  It's pauljadam.com.  It's resources.html, you can spend days getting lost in here.  I know this because I have.  Check it out and see some of the amazing work people are doing.  Okay, that actually is the end of my talk.  Thank you so much.  I'll see you later afterwards if anybody has any questions, but thank you for coming.
Why_We_Never_Get_to_Web_Accessibility_102_0_155.png Why_We_Never_Get_to_Web_Accessibility_102_156_287.png Why_We_Never_Get_to_Web_Accessibility_102_288_3119.png Why_We_Never_Get_to_Web_Accessibility_102_3120_3299.png Why_We_Never_Get_to_Web_Accessibility_102_3300_3863.png Why_We_Never_Get_to_Web_Accessibility_102_3864_4679.png Why_We_Never_Get_to_Web_Accessibility_102_4680_4727.png Why_We_Never_Get_to_Web_Accessibility_102_4728_4835.png Why_We_Never_Get_to_Web_Accessibility_102_4836_5363.png Why_We_Never_Get_to_Web_Accessibility_102_5364_5483.png Why_We_Never_Get_to_Web_Accessibility_102_5484_5795.png Why_We_Never_Get_to_Web_Accessibility_102_5796_6623.png Why_We_Never_Get_to_Web_Accessibility_102_6624_7247.png Why_We_Never_Get_to_Web_Accessibility_102_7248_7691.png Why_We_Never_Get_to_Web_Accessibility_102_7692_7847.png Why_We_Never_Get_to_Web_Accessibility_102_7848_8603.png Why_We_Never_Get_to_Web_Accessibility_102_8604_9743.png Why_We_Never_Get_to_Web_Accessibility_102_9744_10367.png Why_We_Never_Get_to_Web_Accessibility_102_10368_11651.png Why_We_Never_Get_to_Web_Accessibility_102_11652_21911.png Why_We_Never_Get_to_Web_Accessibility_102_21912_22355.png Why_We_Never_Get_to_Web_Accessibility_102_22356_25043.png Why_We_Never_Get_to_Web_Accessibility_102_25044_30563.png Why_We_Never_Get_to_Web_Accessibility_102_30564_32147.png Why_We_Never_Get_to_Web_Accessibility_102_32148_32207.png Why_We_Never_Get_to_Web_Accessibility_102_32208_32627.png Why_We_Never_Get_to_Web_Accessibility_102_32628_35627.png Why_We_Never_Get_to_Web_Accessibility_102_35628_43523.png Why_We_Never_Get_to_Web_Accessibility_102_43524_44135.png Why_We_Never_Get_to_Web_Accessibility_102_44136_44759.png Why_We_Never_Get_to_Web_Accessibility_102_44760_47111.png Why_We_Never_Get_to_Web_Accessibility_102_47112_52007.png Why_We_Never_Get_to_Web_Accessibility_102_52008_53387.png Why_We_Never_Get_to_Web_Accessibility_102_53388_55667.png Why_We_Never_Get_to_Web_Accessibility_102_55668_55715.png Why_We_Never_Get_to_Web_Accessibility_102_55716_55775.png Why_We_Never_Get_to_Web_Accessibility_102_55776_55931.png Why_We_Never_Get_to_Web_Accessibility_102_55932_56099.png Why_We_Never_Get_to_Web_Accessibility_102_56100_56198.png