 Now can you hear me? Perfect. Y'all hear me in the back? We're good? Fantastic. I'm Katie Walsh, and I am an application developer at a global payments company. We help small business owners succeed online. And I have always been obsessed with languages. So one summer, right after college, I had the opportunity to study the Persian language in a country called Tajikistan. And this was great because I was able to converse with native speakers. The catch was that the alphabet that I studied in the classroom was different from the alphabet that they use in Tajikistan. So it's my first week there. It's Friday, it's 3 p.m., I've had a long test, I get out of class, and I'm hungry. Like at this point, I might be hungry. And I think, man, all I want is a Snickers. Now here's the thing, it's August and it's Ramadan, so the locals have been fasting since sunrise. And it would be pretty rude for me to walk up and be like, hey, where can I get some candy? So I think I'm a resourceful person. I'm gonna go find a Snickers bar. So I walk out onto the main avenue, Rudaki Avenue, and the good news is there are a ton of shops. And I know that at least one of them will sell me a Snickers bar. The problem is I cannot read a single sign. And I'm a solo, unaccompanied, Western woman, wandering around by myself. I decide it's not a good idea to just start wandering into random doors. So I'm walking down the street and my glucose levels are dropping. And I see this little kid and he's like 10 years old, he's playing with a soccer ball, and I walk up to him and I say in Persian, hello, can you please read the sign across the street for me? And he looks at me like I might be crazy, but he reads the sign. And it turns out that was a barber shop, so no go. So I say thank you, in Persian. Can you read the next sign please? And at this point, he just starts laughing at me because here I am, a grown adult who can speak to him who cannot read any of the shop signs. But he reads it for me and it's a convenience store. So I thank the boy, I walk to the convenience store, I buy my Snickers and it is delicious. But here was the crazy thing about that experience for me. I had money in my pocket and I was highly, highly motivated to spend it. The issue was that there was a barrier to entry to that local economy for me. And I became dependent on some kid I've never met before to know where to go to buy my Snickers. And that feeling was frustrating. Have you ever felt that way, dependent on someone else to accomplish a simple task? Like have you ever been on crutches and you get up to the door? And you have that awkward moment where you're like, do I wait for someone to open it? Or do I like perch on one crutch and then like use the other one to push the button? It's really awkward. We've all been at that point sometime in our lives, you know when we're little kids, we're dependent on our parents to do everything. It's part of life, there's nothing wrong with it. But not being able to accomplish the tasks we want to independently can be frustrating. And sometimes maybe you have other people depend on you. So I don't know if you guys had the experience when mom and dad and grandma and grandpa decided to get a smart phone and suddenly everyone in the family is dependent on you to operate their cell phone. Yeah, that can be frustrating all around. We as developers want to make sure that our users don't feel this way when they're using our application. And as businesses, we want to make sure that if our users want to spend money with us, they can, as easily and as simply as possible, right? This goes for all of our users. And that's why we're talking about accessibility today. So what I wanna do today is go over some of the basic principles and then share with you guys some of my tools that I use to make our site more accessible that are free and pretty simple to get started with. And then we're gonna actually do a little bit of live coding. So bear with me, but it should be fun. And then I will save time at the end. So if you all have questions, I would love to hear them and I would love to start a dialogue with you guys. So first of all, pop quiz. I know it's early, but we have two sites over here. One on the left, site A, has got some pictures, it's got some icons. I think it's got some video somewhere else on the page. Site B on the right, it's just a simple form. Couple of inputs, couple buttons. I wanna take a quick poll. Who thinks site A is more accessible? Anybody? Okay, we got a couple. Who thinks site B is probably more accessible? Okay, I think we have a couple more for site B. So let's try this out. So this is site A, the BBC. And we are going to test it as if we are a user who relies on the keyboard. So I can start to tab through. And I've got this nice little outline here that tells me where I am on the page. And when I start on the page, I've actually got a little button that says accessibility help. On some other sites it's called skip to content so that if I'm a screen reader user, I don't have to listen to this entire menu every time I get to a new page. So the BBC has actually done a really great job making their content accessible, even though they've got video and pictures and icons and everything. So let's take a look at site B. So pretty simple web form. If I'm a keyboard user, I come in and I have no idea where I am. That's a really frustrating experience. I don't know where I am. I don't know when to hit enter. I don't know when to type my name. So they've taken away my focus so I don't know where to go. And one of the things I wanted to dispel today is the myth that to have an accessible site, it has to be text only or ugly or simple, right? You can have really nice accessible sites. So what is accessibility? I like the definition from the Google SEO starter guide. It's the ability for users and search engines to access and comprehend content. It's that simple. One of the things we're gonna see about accessibility is as you make your site more accessible, you get great side benefits, one of which is SEO. Think about it, a Google search bot does not have eyes. It does not have ears. It relies on your DOM to understand what's on your page. That's the same way that a screen reader works. So I made my own super simple definition which is accessibility is making it possible for all users to use your website. So, now the question is why? And I'd like to point to Matt's. We have a saying in the Ruby community, minus one. Matt is nice and so we are nice. So let's be nice to all of our users, to make it easy for them to use our applications. According to web aim, approximately 20% of the population has some kind of disability. That is one fifth of your potential users. You wanna make sure that 100% of your users can use your sites. Okay, so we're all nice people. We're Rubyists, that's cool. But accessibility, it sounds big, it sounds expensive. How do we convince the people with the purse strings that it's a priority for us? So quick disclaimer, I'm not a lawyer. Do you not take legal advice from me? I will not give it. But I can tell you that suing sites for being inaccessible is a thing. It is a thing that is happening more often. If you want more information on this, Carl Groves has a pretty comprehensive list of litigation and Leanny Finegold writes a lot about this topic. But what does this mean for us as developers? The folks at web aim put it like this. When the Americans with Disabilities Act was first passed, it used to have two kinds of architects. The regular architects and then the accessibility architects. So you would build a building and then you'd hire this extra architect to come in and build a wheelchair ramp. Today in 2017, there's only one kind of architect and they all know how to build accessible buildings. So for us as developers going forward, there may be kind of a delineation right now between accessibility developers and other developers. But in the future, as this becomes more and more important in the legal space, that means that all of us are going to have to know how to build accessible user interfaces. The other thing to keep in mind is that we can all benefit from accessible sites. Not all disabilities are permanent. I see a couple pairs of glasses in the room. Anybody else wear contacts or glasses? Okay, nice, I am not alone. So that's an assistive technology. My contacts allow me to come up these stairs without tripping over myself, which is great. I'm very thankful for them. And there are all kinds of things that we don't think about that qualify as disabilities. So for example, there are people who are permanently deaf and cannot hear. But what if you have an ear infection? Maybe you can't hear for a couple of days. Doesn't mean you shouldn't be able to use the internet, right? Or maybe it's situational. If you guys have ever been in a really loud bar and you cannot hear anything, you're just nodding and smiling at the person that crossed from you because you're gonna bake it up. So they're all over the place. So making your app accessible helps everyone. So think real quick about your app. Could you use it if you sprained your wrist? I don't know, I can't use a mouse with my left hand. That would be hard. What if your contacts fell out? What if you were outside on a sunny day? Does your site have enough contrast that you could see it on your phone? Could you use your app after three shots of tequila? So speaking of assistive technology, I wanna tell you a little bit about how I got into this. So I was the new kid on the block at the company, and I was super eager, and they come in and they say to me, you and the other new kid are gonna get your very own sprint. And I was so excited. And they said, yeah, we have to do this thing called accessibility. And we've got this audit from this third-party vendor, so I'm gonna send you a spreadsheet and you can implement it. So that's cool. And I read the spreadsheet, and it said there were 330 things wrong with our application. So that was a little intimidating. And I started to think about it, and I started to panic a little bit. But I thought, hey, I'm a developer, I'm gonna figure this out. And so the first thing I'm gonna do, obviously, is Google it. And I found the web content accessibility guidelines 2.0, which we'd like to call the WCAG, because we're lazy. And this is the industry standard. It's written by the W3C, and there are three levels. So level A is sort of the basic level. Level double A is the standard. That's where a lot of the governmental regulations and things stand. And then level triple A is what I like to call the superstar. You may not be able to make everything level triple A, but it's always nice to try. And there are four main principles. And they conveniently spell out the word poor. The first one is that your website should be perceivable. So I tend to perceive websites' information with my eyes. However, there are some users who rely on screen readers and they perceive it as spoken sound. The second is that your website should be operable. So if you're a keyboard user, you should be able to tell where on the page you are. And you should always be able to interact with the same elements. So one thing we often see is that if you don't use a button and then you use a div and then you add all this stuff and then it responds to on click, you wanna make sure it also responds to enter. The third is that your website should be understandable. Do you have clear, concise, easy to understand guidelines? Can people figure out how to use your app? And the fourth is robust. Accessibility should more or less be browser agnostic. So if you support a specific browser version, that should also be accessible. Okay, so at this point, I had found the guidelines. I had found the principles and I was feeling a little bit better. And I thought, okay, what do I do now? Well, that's right. I read the friendly manual because that's what we do. And my degree is actually in literature. So I'd like to think I'm pretty good at reading. And I picked up this manual, which would be over 1,100 pages if you were to print it out. And according to my own scale, on a scale of Dr. Seuss to Marcel Proust, the WCAG documentation is just after James Joyce. Like it's hard stuff to read. And that can be a little bit frustrating as a developer. It's just like, what is going on? So I thought to myself, is there an easier way to get started? And my good news for you today is there is. There are a ton of free, easy to use resources out there. And accessibility doesn't have to be this giant, scary thing. You can start with something easy. And so what I wanna share with you today is the accessibility dev tools for Chrome. There's a couple of reasons I like these. One is they're in Chrome, they're an extension, they're totally free. And I already spend a lot of time in there anyway. So it feels kind of familiar. And I love these little red, yellow, green dots. It reminds me of like TDD and what Rubyist doesn't love that. Okay, so we're gonna do a little bit of live coding. Bear with me. Okay, so this is my super weird pug postcard page. Simple web form. And I wanna make sure that it's accessible. So I come over in my console to the audits tab. I choose accessibility. And then I'm gonna click run. Okay, so we've got a couple issues here. So we're just gonna tackle them one by one. So the first one says that controls and media elements should have labels. And it's referring to these two elements here. And so you might be thinking, I'm like, oh, there's placeholder text, right? How many of you have ever started to type your email and then you get a Slack message? And it's a catgif and it's a really cute catgif and now you have to go get another catgif to send back because you want to reciprocate the catgifts, right? So you come back to this form and you go, oh, I must have been typing my email, cool. And then you get here and you're like, oh, no, I was typing my name. So now I have to go back and I have to start all over. For me, that's annoying. But for someone with a cognitive issue like ADHD, this is incredibly frustrating. So let's get some visible text up there. So we're just gonna add a label and call it name. And what we're gonna use is the four attributes. And I'm gonna put in the ID of the input. And what that is going to do for us is programmatically associate the label with that input. So let's go back and try this again. Okay, and we're gonna run that audit again. Fantastic, that one's gone. So one of the tricks about using the four attribute is now when I click on name, I actually get into that input, which is really helpful if you've ever been on a form in your phone and you're trying to hit that input and you just can't get it, it's so frustrating, right? But this gives us a little bit more namespace. So if I fat finger something, I can still get into that input. So let's take a look at the next one. Images should have a text alternative or a presentational role. So if an image conveys some kind of meaning, if someone cannot perceive that image visually, we want to give them some text so they can know what's going on. And I don't know about you, but I feel like you're missing out on the fun if you can't see this pug in a pink unicorn costume. It's a pumpkin patch for no apparent reason. So I'm gonna go into my image source and I'm going to add some alternative text. Let's see, pug in pink unicorn, run our audit again. Cool, two left. Text elements should have a reasonable contrast ratio. So the WCAG 2.0 says that you need to have a certain amount of contrast on your text so people can read it. This is important for any users that might have vision issues. This is also really important if you're outside on a sunny day trying to use your application. So this text up here is not a great color. And one of the things I love about these tools is I'm inspecting the element and I can go over here to accessibility properties. And it will actually tell me that my contrast ratio is insufficient and I can try out some new ones. So this is level AA, which is a three contrast ratio and then the 4.0 is the AAA. Let's shoot for the stars, we'll do AAA today. So I'm going to replace that in my CSS and let's try it again. Okay, one left, awesome. The purpose of each link should be clear from the link text. So over here we have this link that just says click here. Now if I'm a screen reader user and I'm tabbing through, I'm not going to hear all of that information that comes before, don't know what a Pug postcard is. And so I don't have any context for the words click here, like why would I click here? You haven't given me a good reason. So we want to make sure that the link gives a little bit more information. So instead of just saying click here, we'll say learn more about Pug postcards. We're going to refresh and we're going to run our audit and we've got all green, feels good. Thank you, thank you. Feeling really good about this. One other thing I wanted to show you guys which is super simple to add to your website and we often forget about is right up here in the top, I've got HTML language equals English. And it's really easy, we're in America, everybody speaks English, we're kind of in our own little bubble, we're not thinking about it. But this is really important for screen readers because if I'm a user who has set up my screen reader to default to a different language and I get to your webpage and you don't tell me the language, it's going to try to pronounce all of your content in my own language, which sounds really, really weird. The other benefit that you're gonna get from making sure that you always include the language is that if your user comes to your site, have you guys seen the Google translate bar that pops up at the top? It relies on that to know what your content is. So you're also gonna help users who maybe speak another language or have their default settings in a different one. And I of course don't mean everyone in America speaks English, that was ironic, joke. Okay, so let's go over how to test your app. Now these automated tools are fantastic and I love them and they're easy to use but they're not enough. They cannot catch everything. You do have to have some human testing. So go through your app with an automated tool. Go through those issues, fix them. Then go through your app with keyboard navigation. If you can hit tab, if you can interact with all of the elements, can you submit the forms? Can you hit the buttons? And then test it with a screen reader. And this one takes a little bit of time to get comfortable with, but I see a lot of Macs in the room. There's actually a built-in screen reader on Mac. It's called VoiceOver. And you can use that to test your apps. Chrome also has a free plugin called ChromeVox. Free, easy to install. And if you're working on Windows, there's NVDA which is also a free screen reader. So let's recap real quick. We have our poor principles. Perceivable, operable, understandable and robust. And under perceivable, we looked at two issues. One was that images need alternative text if they convey meaning and we fixed that by adding the description of our little plug. And text should have good contrast and we fixed that by changing the color of our header. The next one is it should be operable, so link text should be meaningful. So we took away that click here and we added more information to our link. The next one, understandable. Form fields should have visible labels. And we accomplished that by adding the four attributes to our labels and associating it with the ID of the input. The other thing is you always want to include the human language of the page. That allows screen readers to know what's going on and it allows Google Translate to know what's going on. And robust. As I said, automated tools are not enough. Test with a screen reader, test with keyboard navigation. So I promised you guys I would share some of my favorite easy use free resources. So the first one up there is the actual WCAG 2.0 guidelines. They are worth taking a look at and then maybe cross referencing with something that's a little easier to read. There's a great book, it's not free, but it's very helpful, called How to Read the WCAG 2.0 Guidelines by Luke McGrath. And I like to call that the WCAG 2.0 in plain English. I find that one very helpful. The web aim guys have a fantastic checklist for WCAG that you can go through. It's free, it's on their blog. I highly recommend it. Google has two courses that I find very helpful, both free. And then I also wanted to include some resources for your product team, your UX designer. There are two checklists, one by Vox Media and one by web aim for the product stage when you are still figuring out what you're going to build. And one of the things that we learned in making our website accessible, it is that it is much easier to create and build something that's accessible than to try to go back and retrofit it. So it's great to get that into your process early on. And then two books, Inclusive Design Patterns by Hayden Pickering. There's also a web for everyone, which has a set of personas of different users who rely on different assistive technologies that can help your product team sort of think about how people might be using your application. For testing tools, there are a ton out there. I encourage you to go figure out what works for you and come talk to me if you find cool stuff. I'm still on the search for a good CI. So we used the Chrome Accessibility DevTools today. There's also a great one, the web aim wave tool. It's kind of like a GUI and it's really easy to see what's going on in your site. There's Tenon.io, there's AX, there's Pali, and then there's AccessLint CI if you're interested in adding this into your continuous integration. And I will post these online, all these resources. And then as I mentioned, there are screen readers for testing. So if you've got a Mac or an iPhone, voiceover is built in. If you have Chrome, you can use ChromeVox. NVDA is free on Windows and JAWS is not free, but you can do like a 40 minute trial. Okay, so your mission, should you choose to accept it? Grab the Chrome DevTools, run an audit on your app, share a screenshot with me and tell us what you're gonna fix first. Maybe it's like the super easy one, which is just I'm gonna add the human language to my HTML page. That would make me super excited. And then come find me at a happy hour over a beer or coffee and tell me about it. I'm super interested to hear what you guys are doing in accessibility. And I would love to hear if you have resources to share. You know, I'm still learning. It's a huge, huge topic to learn about. And I'd love to learn more. So here's the thing. We as developers have the power to make sure that our users don't feel frustrating using our app. And we also have the power as developers and as a community to decide what is going to be standard practice. We do that in all areas of our code. So let's make this standard practice for the Rails community. Let's make it best practice to have text contrast, to have human languages, to have alt text. Because we can do that and that's really exciting. So even if you're not at a company that has the resources to hire an expensive consultant or do an entire third party audit, you can run a simple DevTools audit on your app and you can make a few changes there. So I hope that you'll join me in working to make a more accessible web. And let's see, I've done a lot of talking. So I'd love to hear your questions if you guys have any for me. Yeah. I don't know if you've had the same experience when you first try out a screen reader. I don't know if my site's not working right or if I don't know if I just done not able to use a screen reader. Do you have any tips for someone trying out a screen reader for the first time on how to learn? Yeah, absolutely, that's a good question. So I can actually show you my voiceover right now. So one of the helpful things to do is that if you're using ChromeVox, test on Chrome, if you're using voiceover, test on Safari, I don't know what the preferred one is for NVDA, but if you stick to Mac and Mac or Google and Google, that tends to minimize the number of errors. And so I'll show you guys real quick how voiceover works. So I do Command Function F5. Voiceover speaks descriptions of items on the screen. Voiceover on Chrome, send a pug postcard window, send a pug postcard web content, landmarks menu. You are currently in a voiceover menu. This is a list of voiceover menu options. To navigate up and down the list, use the arrow keys. To choose a menu item, press Return. To close the menu, press Escape. Okay, so for tab users, they often tab through your screen because they're actually, they might be looking at it. But for screen reader users, what the majority of them are going to do when they first get to your web page is they're going to go to this menu. Windows Pots, links menu, headings menu. And they're gonna look at your headings. So in this case, we've got a nice heading one, which tells them where we are. So it's really important to make sure that you've got semantic headings. But to get back to your question, voiceover actually has a tutorial when it first pops up. I recommend going through that. ChromeVox also has a pretty good one. And yeah, sometimes it's not easy to get started. I totally understand. It took me a while. Just playing around with it and trying to... Send a pug postcard, voiceover off. Sorry, I'm gonna turn that off for a second. There's also a really great resource on webbing, on their blog about how to start with screen readers. And they've got one for voiceover, one for NVDA and one for JAWS. And I'll post that along with my slides. Yes, good point. So she asked if there's any places where web accessibility might seem counterintuitive. And I think originally for our team, the idea that we have to have those form labels for every form was a little bit tough to swallow at first because we were so used to using placeholder text. And it seemed to be doing the same thing. But at the end of the day, when we added that and we had that extra little click area, we found that it was better. That is an excellent question. And as you get into... So what he was asking about was if you have a complex data chart, or if you have a... Maybe an image with a lot of different things going on, what's the best way to do that? So I haven't had the opportunity to work with something like that, but there is a great resource, also on the web aim blog, on how to deal with complex charts and how to give that information. And I can post that as well. Yeah, that's a great question. So his question was if we can have multi-lingual pages, which we can. And so you can actually go in and... Let's see. I don't know. I know that you can put it on a div. You can actually add the language in multiple parts of the page. So if you have a French page and then you have a chunk of German, you can add language equals DE to that chunk where you have that quote. So it's possible to use that to make it multi-lingual. Yeah, thanks. Oh, that's a really good question. So she was asking if there's any places where you can get feedback from users who are using a screen reader or for user testing in general, is that right? So we haven't worked with any of those at all, but I do know there are some services that you can hire out to and they will have users go through your app and give feedback. I don't know any off the top of my head, but I can do some research and get back to you. Thanks. So he asked if I've ever run into an issue where adding labels or changing contrast has resulted in pushback from a design team. Absolutely. And that's why I highly recommend grabbing those product design lists and having a nice little sit down with your product team and talking about how they can integrate accessibility into making new mockups. Yeah, but it's definitely a process and a negotiation when you have to change existing designs. Yeah, you're not alone. Yeah, I mean, I think one of the, he asked how we compromise with our design team to make sure that we can meet those standards. One of the things that we did was we kind of said like level AA is what we're shooting for. So level AAA does require a pretty strong contrast. So we didn't go quite that far for our text. The other things we found is you can do things like adding outlines or adding drop shadows and having that little bit of dark around the text itself means that you have contrast with that instead of the contrast with the back color. We also have a couple places where we've used overlays. So we put a dark overlay and then we put the text on top and that ends up being sort of a more elegant solution than changing all the colors. Yeah, thank you. Yeah, so he was asking if mobile devices have accessibility stuff. The iPhone has actually got a fantastic accessibility setup. It has voiceover and you can put it into accessibility mode. So when you tap you have to double tap to actually go into something as it reads the title. So thank you. So that's all the time we have for today but I would love to talk to you guys later if you wanna chat accessibility. Thank you.