 Can you all hear me? OK, yeah, that's on. So as they said, oops, I forgot to plug this in. New to the clicker thing. So as they said, wait, sorry. OK, I want to just go through what we're going to be doing so you're aware of what we're doing. I'm going to be doing an intro. Just why am I the person telling you about the subject? And we're going to do a brief overview of accessibility and the sorts of people it's affecting. And I'm going to give you some real life examples of accessibility and bad accessibility on the web. And we're going to conclude with the sorts of things that you might be able to do to improve the accessibility of your products. This talk will not have a reliance on the slides. If there's any visuals that are important, I'm going to describe them to the best of my ability. It's not going to have any animation because I feel like animation and accessibility talk is a little weird. And it's not going to have any cat pictures because my dog would freak out about that. You can find my slides and other resources at dragonwithau.tech.nbpy. That's for North Bay Python. And I'm not going to be taking any questions from the audience, but you can totally approach me afterwards to ask questions. Or you can also contact me with the information I'll be giving at the end. Or if you can actually read my handle down there, which is techevangelista, is me on Twitter. So I went to a bootcamp. And I got into web dev right afterwards. I was a full-stack developer for PBS. And there, we did a ton of accessibility work. And it was for the first time, I realized that, hey, I can actually do something for the stuff we complain about on disability communities online. And it was just mind-boggling to me that there's code that you can do that's pretty easy to automatically improve people's experiences online. And now I'm a technology evangelist. I'm not really doing a lot of code. But I'm caring a lot more about the physical aspects of accessibility. I have to worry about, like, are our vents accessible for people? Are the activities we're doing accessible to people? So it's giving me a much broader view of what's possible. But before all that, I earned that MA in International Peace and Conflict Resolution, which is a bit of a mouthful. But it was really helpful when it came to accessibility work because it meant that I had studied a lot about the needs and wants of people from cultures that I couldn't really understand because I couldn't really experience them the way that those people experience them. And when it comes to accessibility, a lot of it is what would people who I might not share everything in common with, how would they approach this website? What would they need from it? But I've been throwing around that term web accessibility. And it's kind of a buzzword right now, but you might not know exactly what it means. So I thought we'd just go through an intro of that. So the World Wide Web Consortium, which is also known as the W3C, is a community that develops web standards. And if you do any front-end work, you've probably used their website at some point to look something up. They have what's called the Web Accessibility Initiative. And those are the people behind the Web Content Accessibility Guidelines, aka WCAG. And they do a lot of around accessibility, and they have pages and pages of different information on that. But I'm just going to go through a brief overview of what they say. And it's that web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the web, and that they can contribute to the web. WCAG 2.0, which is the current version, has guiding principles in this weird acronym, POR. And it's that they should be perceivable, operable, understandable, and robust. And what both of those statements means is just that people should be able to use the web and get a good experience out of the web and be able to interact in ways that other people can when in the web. WCAG 2.0 is currently adopted by many countries, Australia, Japan, Germany, others. And in the United States, we have various laws that cover web accessibility. But the closest we get right now is 1.0. But in January of next year, so next month, some of those are moving towards 2.0. So it's a pretty big change for people. The target audience for web accessibility is generally considered to be disabled people. And WCAG and other resources tend to put these people into five categories. So there's visual. The most obvious is probably blind and colorblind users that you hear a lot about. But there's also just people who can't see because of blurry vision or because of obstruction vision or any other number of things. There's auditory. So there's deafness. But there's also just issues like Tinnitus, where people are ringing in their ears. So if you make people listen to something very closely, that can really be a problem for them. There's motor and physical. So that's obviously like paraplegics, people who don't have fine motor control and might not be able to use a mouse very well. And a whole other slew of issues. Cognitive and neurological is the biggest category. So that spans from autism, ADHD, PTSD, and various other issues. And finally, language and speech, which is a lot more important now that we have stuff like Alexa and Siri and other ways of interacting with our technology through speech. So if people can't speak or can't speak well, that can affect their usage of that stuff. But also, there's more than just those categories. You'll notice throughout this talk, I'll probably be saying people with accessibility needs as opposed to people with disabilities or disabled people, because accessibility actually affects way more people than who might think of themselves as disabled or who might count as disabled when there's like a survey in their country. And lots of people break it down into lots of different ways, but I watched videos by this Canadian accessibility expert named David Browerman. And he broke them down into four ways that I thought really kind of covered what the other categories weren't covering. So the first one is permanent. So that's like being born blind. And when you're in the permanent category, you normally have ways of interacting and ways of using different devices that spring from actually having to experience this all the time. There's temporary, and this could just be like being sick. Maybe you get really sick and you get weak and you can't use your computer the way you used to. There's acquired, so that's like aging. You could have no accessibility needs, and then suddenly you hit a certain age and you have them. And there's societal, and the best example of this is left-handedness. A lot of programs and apps are often made assuming people are right-handed, and so left-handed people can have issues using them. And a lot of these people might be using other less common tools of interacting with the websites as opposed to just the standard mouse. There's many, many alternative input and output tools, and these come from just using your keyboard, which obviously a lot of devs also do. You can have foot pads. You can use your mouth. There's eye tracking. There's all different ways of experiencing a website that don't involve a mouse or even a touchscreen. And if you have an accessible website, it's easier for every sort of device that people are using. But also, when we put things into categories, humans have a cat... They tend to put them into just one, right? Like, we make a category and we think everyone just slots into one category. But those are actually deceptively simple because users don't just fall into one category, right? Everyone gets sick. Everyone ages. Someone with vision issues might also have motor issues or cognitive issues. It's not just one thing or another. And you have to also consider that. In their book, Design for Real Life, Eric Meyer and Sarah Wachterbetcher put this forward as thinking about accessibility issues as not edge cases, but stress cases. So they're putting your design and your product to real-life tests. And if you can get them to pass those stress cases, then, of course, they're better for it and they're going to be more reliable outside of those stress cases. So what are some examples of what accessibility looks like on the web? There's color and size. And this counts a lot for text, especially. There's lots of checkers that you can get that use WCAG 2.0 to tell you if the color in the foreground and the background of what you're doing is actually visible. And, of course, if it's something light on a light background, it's harder to see. And as far as size goes, generally the bigger the better and the bolder the better. I like to think of it as an eye chart office when you're getting an exam and it's on the far wall and there's like lines of letters and they're telling you to read like the smallest row that you can see. But if you could read just the top row, which is really big and really bold, it would be a lot easier and a lot less stressful. There's also fonts. People with dyslexia have issues reading different fonts and there's ways to make it just slightly easier for them. A lot of fonts don't differentiate enough between certain letters. So if you put like a one, a lowercase l in a capital I next to each other and you can't tell the difference between any of those, that's not a good font. You can also have alternative text for your pictures. This means that when people are on a screen reader, which is a very popular way of people with vision issues to experience the web, it just kind of reads out what they go over. If they have alt text on an image, they'll know what that image is because the screen reader is going to say the word image when it hits it normally. And on that note, you also wanna be careful of how you word that because you don't wanna be like image of a dog because when the screen reader hits it, it'll go image, image of a dog. And that gets really annoying, even just in testing, let alone like every day. You can make changes noticeable. If you're trying to log in and it doesn't do anything, you don't go anywhere, you get no error message. You don't know what to do, right? Like is it a hiccup? Did I do something wrong? Is the site doing something wrong? Who knows? So maybe some people make the password label red or something. And that's also not very noticeable. Maybe you're distracted, whatever. If they put a symbol next to it, that lets you know like, hey, something's wrong. That can be even easier to see. But symbols aren't always universal and also still just like adding one little thing. So some people will also put a message, like something went wrong. And then if you're distracted or not paying attention or if you have an accessibility need, it's a lot easier to know what went wrong. And on that, and using ARIA tags when you're doing forms like that is important. ARIA is a way of communicating with these screen readers and that way you can have a specific tag that tells people on a screen reader who are already way down the page that the password label changed and that there's an issue. Although you should use that very sparingly because you can also interrupt screen readers and that can get annoying. Like if you have something just lazy loading and updating all the time, they'll hear every single update. And these are all just like really small things you can do and pretty easy to implement. And sometimes they can sound kind of easy, but obviously it's one of those things where it's like, if it was easy, everyone would be doing it. So I like to think of it as like a metaphor and in this case, like if you've ever read the wayside school books in school, you're really popular when I was a kid and I'm probably dating myself. But in one of them, the school installs an elevator and it can just go up. So it's just supposed to take kids up. But no one thought about how it was supposed to reset so it only goes up and stays there. So they only get one ride out of the elevator. And web accessibility is kind of like that at times. People will think toward to a certain point and get the basics done, but they won't actually consider usage of their website. For another example, at my last job, we did a lot of web video and we would check the accessibility on our web pages to make sure that that was still working for everyone. And we had a few very basic tests to do this one of them is we'd get a blindfold and we'd put on headphones and we'd turn on our screen readers and we'd have the test be, okay, go from the home page to a video, play the video and pause the video. And of course, a lot of sites, you couldn't even get to the video and play it. But a lot of other sites you could get there, but you couldn't pause it. And this was like pretty major video providers online hadn't thought that, hey, our users do more than just play a video. They interact with a video. They don't just do the one single step and stop. And you know, like the elevator in wayside school, no one thought past the most obvious step. To what would actually be accessible. And if someone had thought of that, they might have been able to avoid it and they might have been able to avoid really annoying some of their users. And it doesn't have to be someone necessarily in charge of web accessibility at a company. It could be nearly anyone in some way. And it could even be some of you in some way, even if you're not doing front end, even if you're not doing design or whatever. You could make sure you avoid gimmicks, not just in your styles, but in your features. And think through whether something's being done just because it's popular or trendy and how well it actually works for your users. Because you need to think about how your particular users are using your particular products. A lot of the guidelines like WCAG or a lot of the testers online are designed for general projects. And what you're doing might not quite fit into that. So for example, if you have a footer or a right hand sidebar that's really important for people to get to, but you also have infinite scroll, like someone using a keyboard can't get to those. They just press button, press button, it keeps adding more and more stuff and they'll never actually access, like say your FAQ or your contact information or whatever you want them to get to. And this kind of goes into the idea that there's an opposite of user-friendly. It's called user hostile. And it's when you're actively annoying or even harming your users. Because there's a lot of stuff on the web that is unintentionally causing harm to people. Like autoplay and the nation and noise. You might be hurting people with anxiety, distracting people with attention disorders. You could be triggering seizures or migraines with that. And the list just really goes on as to how you could be affecting people. And you can push back on inaccessible decisions because just like some people who put autoplay in something aren't thinking about how it affects people, a lot of times people just don't realize what they're doing is inaccessible. And if you point it out, they'll be like, oh, I didn't know, let's maybe come up with an alternative. Or you could offer alternatives and sort of save them the time and make it really easy for them to just accept it because they don't have to do much work. You can do opposition research. If there's any pushback on it, you can go to your competitor sites. And if they're more accessible, you can come back with that and be like, hey, we're probably losing people to our competitor because it's so much easier to use their site. Or if they're less accessible than you, you can use that too. Be like, this is a niche that we have that they don't have. We're filling a need that they are not filling. And we can embrace that and really use that to set ourselves up as different and better. And if none of that works, you can just try to keep the bare minimum even if it has to change a little bit. So, for example, focus state is generally an outline around an element that shows where someone using a keyboard is. It's like the equivalent of their mouse pointer. And a lot of people like to get rid of focus state. And then when you're using your keyboard, it's really confusing because you're going through a list of links and you have no idea where you are. So, even if you have to maybe change that, like make it a different color, make it a different thickness, that's still okay. Link decorations are also a big one. Like, I get annoyed when I'm on a website and I can't tell what's a link and what's not because they have done everything in their power to make it not obvious. And if you have even more issues using websites, it can just be really frustrating not knowing how to find a link. And, again, that doesn't necessarily have to be an underline. It can be lots of different things that just differentiate it from the rest of it. And if you work on anything involving, like, the copy or wording of things, words are also super important when it comes to accessibility. Your written content matters just as much as your visual content. For example, earlier this year, I was trying to find a ergonomic keyboard and I was going to lots of sites looking for them. And I was reading one of the sites and it had, like, super long, you know, descriptions of everything. And at one point, it said the phrase, no sane application. When you use words that also are used on people and you use them in a bad meaning, it can really reflect badly on how you're doing it. Because what they meant was something like no logical application or no good application, but they were using a word that's a medical term about human beings. In a professional site, you really should not be insulting your users and you definitely shouldn't be hurting anyone's feelings just because you can't think of a synonym. Unless you're doing something medical, just avoid medical terminology. It's not that hard. You can also just try keyboard navigating through your site. Like I mentioned we did earlier. You can start with just trying to tab through it. You can add in a screen reader and then try some basic keyboard commands for navigation. They all have kind of different ones. But understand that you're not the common user if you're not using this all the time and that you might be getting a slightly different experience than other people. And to that end, you can get real input from users. People with accessibility needs can, you know, be paid in gift certificates or a small amount to go through your site and let you know where they have problems. Much like UX designers and researchers will have people like sit in a cafe and get a cafe gift card if they go through something with them. Those of us with disabilities still like getting paid for stuff. You can also just make sure people have a way of reporting issues. There's a lot of websites that make that really hard. But if you have an easier way to do that, that can help if you have a slow process to change things or if it's really hard to prioritize, just get feedback from your users who are willingly giving that to you for free. And if none of that works, there's also benefits beyond just a happier user base. Good accessibility is good code. WCAG is under the W3C who do HTML standards. And this means that if you have good accessibility, your headers will all be in proper order. You'll be using the right elements for things and you'll be following guidelines. And for that, that means that future developers working on your website will have an easier time understanding your code. Because HTML can actually get pretty confusing if it's done wrong. It's also good for things like Google Search and other search engines, which are using web crawlers to go through your site and well-structured content is helpful. And as devices like Alexa and Echo get more popular, they're also going through your content, but they're also not necessarily interacting with all of your content. The same way that some people with web accessibility needs might not be interacting with all of your content. It's also the law. For a lot of people, you're legally required to have a certain amount of accessibility. When Dixie, a popular southern grocery store chain, actually lost a lawsuit this year about web accessibility, they normally settle out of court with these sorts of things, but they took it to court and it found that not only did their own code have to be accessible, but their third-party plugins were their responsibility too. If their entire site wasn't accessible, they were responsible for that. So there's lots of reasons for accessibility. You're making your users happy, you're getting a bigger user base, and you're probably making your lawyers happy too. And it's just an easier, better product to work on. So finishing up, if you're interested in maybe looking into accessibility, I've got the resources on my site that I mentioned. I have different sites for you to check out and read and also mentions of extensions that are really good to work with, and that's at dragonwithau.tech.nbpy. I also suggest maybe downloading a free trial of JAWS. It works only with Windows, but if you know how to set up a virtual machine, you can get a Windows virtual machine from Microsoft, set up JAWS in it, and just restart that every 30 minutes as the trial expires. So it makes it a lot easier to work with. Some other really good ones that I list on my website is a Chrome extension called NoCoffee, which lets you see how people with different visual issues might see your website. So I highly suggest that one too. If you want to contact me, my email is LMDRAGUN at gmail.com. That's LMDRAGUN with a U. And that's also my GitHub. I don't really do much on there anymore, but people are always putting their GitHub on these things. And my site is, of course, dragon.tech. Also, if you run an organization in New York City or San Francisco, and you need diversity or accessibility sponsorships, hit me up at my work email at lindsay.dragon at weightwatchers.com, and I might be able to get you some money. Thank you.