 I'm starting right away because, again, we 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 of 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. And even if I were, I am not your lawyer. So you should not be taking legal advice from me. Disclaimer number three. This is going to be a very US-focused talk on cognizance. 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 as disabled, I apologize. OK, 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, OK, am I working on anything cool that I think the Rails community might want to see? And over the past year and a half, about I've been really ramping up into accessible development at my company. So I thought, OK, 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 improve my Rails app, cure my acne, save 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 that requires your own a lot of expertise into a subject. And also something tailored to our particular audience. And when we just teach one over again, 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 Rails Conf 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 excess, are gonna 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 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. Well, 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 gonna 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 gonna 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 of itself a bit problematic, which we'll also get to in a second. And we're gonna 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 hands down now, you're finally right. 19% 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. For instance, autism is very, very undercounted in girls and women. And there's also just people who say, yes, it's hard to get out of bed every day because my pain is so bad, but 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 gonna stick with 19% because that's a nice hard meeting number that we can hold on to for later. Bearing that in mind, I'm just gonna go through two aspects of the society that we went into and they're very formative aspects, that 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% had a disability. Furthermore, according to the Washington Post, of the characters that we see in television and in movies who have a disability, I think it was 95% 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 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 that 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 gonna 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 gonna make the home page screen reader readable and then on Tuesday we're gonna 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, 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. And I know this because about, so 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 gonna send me this article about someone inventing this. And they always wanna 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 this 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 coming, they're usually not gonna 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 refos and wait for two different employees 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? 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 that 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 wanna 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 ones and zeros, you're not doing real code. 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 wanna note that's just an interesting trend I found while I was researching this talk. We're gonna 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. But, and this, 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 to 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 copy and pasting and building off of are at their most complicated ULLs and LIs, then you're not gonna have good semantic HTML on your website. And you're not gonna 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. And 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 gonna 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 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 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, 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 gonna say who, cause that's not important. The importance is you had three major candidates who had nothing on their website about 19% laws that would impact 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 three 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 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 box 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 guesses 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 it 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 gonna 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 gonna 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 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, does it 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, 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 wanna look into stuff. Just as a side note, pretty much any example you've ever heard 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 kinda 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 homepage 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. If 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 snuff 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 NVIDIA into Loving 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 bent 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 again, 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 gonna 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 gonna 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? Do, 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, once the 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 same problems I have. In this case, oh, those merge, those get merge feels. I think we all know those get 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 got a second merge conflict, that's like, huh. 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 cause 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'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 backyard. Okay, I'm gonna 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've recently put out the WCAG 2.1, but it's probably gonna 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 slash tr slash 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 Twitters where they talk about the work they do. Again, this is a gigantic last list. It's pauljadam.com slash 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 be up here afterwards if anybody has any questions, but thank you for coming.