Video details

Simplifying Web Accessibility | Monthly JS

JavaScript
10.21.2021
English

Presented by WWCode Boulder/Denver Event: Monthly JS Speaker: Meg Shulmister
Simplifying Web Accessibility is an interactive conversation on how we, as developers, can easily incorporate accessibility-focused design into our work.
Meg changed careers to Software Engineering after being laid off from her Hospitality Management position due to the pandemic. She is a graduate of Hack Reactor’s Software Engineering Immersive and is a front-end/React focused developer, though she also enjoys full-stack! Meg is passionate about uplifting women in technology and empowering others to take this career path to change their lives for the better. She's excited about health, education, and blockchain technologies and intends to use her technical skills to make a positive impact for people and the planet. Meg resides in Rollinsville, Colorado where she is deeply filled by nature and the mountains.
___ 💻 WWCode Digital Events: https://www.womenwhocode.com/events​ 🔎 Job Board: https://www.womenwhocode.com/jobs​​​​ 💌 Make a Donation: https://www.womenwhocode.com/donate

Transcript

All right. So I am so excited to introduce our speaker for tonight. Meg. Meg changed careers to software engineer after being laid off from her hospitality management position due to Pandemic. She's a graduate from Hack Reactor Software Engineering Immersive and is a front end React focused developer. Though she also enjoys full stack. Meg is passionate about uplifting women in technology and empowering others to take this career path to change their lives for the better. She's excited about health, education and blockchain technologies and intends to use her technical skills to make a positive impact for people and the planet. Meg resides in Roundsville, Colorado, where she is deeply filled by nature and the mountains. And if you all haven't got the opportunity to meet or chat with Meg before, she's awesome. And we're really just so grateful to have her as part of our community. So, Meg, I will pass it over to you. Thank you, Jen. That was so warm. Got a big smile on my face after that one. So I'm so excited to be here. Thank you all for sharing your evening with me, to have a conversation on something that is really exciting and forever evolving, and that's going to be on web accessibility and how we can do our part as technologists to consider all of our users and what their experience is like. So bear with me while I share my screen. Give me just a moment. How even in the virtual world, my heart starts racing a little bit when I'm presenting, but so excited to be here. Ok. How is that looking? Can I get a thumbs up? Cool. All right. So today we're talking about simplifying web accessibility or as I like to think about it, developing with accessibility in mind, because the approach I like to take is not really reinventing the wheel or learning these abstract concepts to make our applications more accessible. It's just kind of tuning up how we're already coding, like incorporating best practices into our code. That's going to not only make it more accessible, but it's going to make it more maintainable, better read by other developers. So it's just a powerful approach as we're coding to develop with accessibility in mind. So my quick agenda is going to be a survey of the room who and why we're having this conversation HTML as a powerful accessibility tool and a few code examples. So if you like, throw one of these hearts up or maybe in the chat, do it in the chat where you're at on your web accessibility journey. Are you an expert? Are you pretty familiar and you're already developing every single day with accessibility in mind? Or have you heard about it? But you want to know more or you just beginning your accessibility journey. I wish I could see the chat. I guess that's the funny thing about Sam. I don't know how to make it always work with screens. Oh, there it is. Great. Awesome. Heard about it. Want to know more? Melissa is an expert. Awesome. You've got to teach me some stuff, Melissa. Great. Red hearts, yellow hearts, blue hearts. Great. So it looks like there is a bit of diversity in the room on where everyone's at with their awareness. So for those who know a ton, I hope maybe this is a good refresher. Or maybe there's something new you learn. And for those who today's, maybe day one or two, I hope you get some value from what I'm going to share today. Okay, so to get us the ball rolling, it's important to mention Lacag or Web Content Accessibility guidelines, or WCAG. However you call it when we're talking about accessibility, the question that comes to mind for me is what is our goal? What are we reaching towards? Where are we heading? What do we want our code to actually do? Or how can we judge it or standardize it? So is that standardization for us? It's a technical standard for accessibility, and it's currently considered the gold standard. It's considered also the best path to accessibility compliance. I won't touch a ton on the tag today. This is really going to be my only site about it, because it's worth mentioning. This is our best direction we're heading. Of course, our intention as developers is to make our applications as accessible and user friendly as possible. But with CAG gives us a bit of a framework and some guidelines to work with. There's three levels of compliance, AAA and AAA, and as you can probably infer, they go up in their accessibility compliant standards. So AAA is going to be the best of the best and currently legal constraints for web accessibility is still a little confusing and hairy. Unfortunately, currently, federal agencies and their contractors are required to conform with WCAG 2.0, but this is the direction it's continuing to head. More and more. So as the Ada standardizes for Web accessibility, what KAG is going to continue to be our North Star as developers, so we could go months and months and months on what KAG. I would highly recommend taking more look into it and their documentation and your time. So yeah, just a note on that. So who are we targeting today? And I really wanted this to be a conversation. So I'm going to ask you all to contribute in the chat if you feel open to it. So when we're thinking of a user who is interacting with the Web with disabilities, what comes to mind and what kind of disabilities that we might be targeting? Who is that user feel free to join in the chat? What are some of these disabilities that come to your head? Or maybe you're someone interacting with the web right now who has a disability and you're using any kind of assistance right now? Colorblind is one that popped up. Great. Kendra definitely amputees totally users with visual hearing, cognitive, totally low vision, someone who has no vision, age related? Yes, absolutely. These are all totally what we're thinking of anyone. Yeah, exactly. Anyone. So when we're targeting users, we have a huge diversity of who's joining our applications and what their abilities are, but they can typically follow into four kinds of impairments, visual, auditory, motor, or physical and cognitive. And I think all of those were covered in the chat. So now that we're developing with web accessibility in mind, we're wondering, coming to our code with how is someone who can't use a mouse or keyboard interact with this app? How does someone who has low or no vision interact with this app? And it brings a new awareness to the code that we are writing. So here's just a few images of some of these assistive technologies. Top left is a head planner for someone who might not be able to use have motor function in their arms or their hands. Top right is a Braille reader, which, from my understanding, brings any kind of text on the page to pop up pins so you can read the Braille. Bottom left is a screen reader, which is probably the most well known assistive technology. And the bottom right is it tracks your eye movements, and the user can interact with an application just with their eye motion. So these are some of the assistive technologies that our users might be using. So one challenge that I had a lot of fun trying to do was using a screen reader to interact with the web. Also, you can try just using your keyboard or something like that, embodying someone who might interact with the web in one of those ways. And I found the screen reader was definitely for me, a big learning curve, and it was that much more parent how important it is to test our applications, manually, test them as well as we are that user. Or maybe you are the user. So you're already developing your application like this, and why care about web accessibility? Well, I think the first thing is kind of obvious and why we're all here as empathic individuals or being that user ourselves. We got to think about the user experience for all folks, anyone who is interacting with our app. Again, there's such a diversity of what people are coming to computers with. So we've been thinking about user experience being one of our biggest priorities. 15% of the world's population has some sort of disability. So if we are not considering all those folks, we are really missing out on a huge opportunity for a lot of people interacting with their applications. A pretty frightening stat is that 90% of websites currently are inaccessible, and that's pretty shocking to me. Just thinking about it's. A lot of websites that can have a huge room for improvement and creating a better user experience for more folks. You can also be the accessibility manager for your organization and go deep in this realm and really empower your organization by being that what tag expert and playing an even bigger role in assisting more folks to interact with your app. So when we consider Web accessibility, it typically benefits most users, and this is one of my favorite things to chew on. As I'm developing with accessibility in mind, the curb cut effect kind of speaks to this point that the curb cut effect is something that people who advocate for disabilities talk a lot about or advocate for people with disabilities. It's a technology that was originally built for folks who needed it might be using a wheelchair of sorts, but it also ended up benefiting so many people, like skateboarders or people with luggage or people with pushing babies in strollers and even temporary injuries. And there was this concept that happens when an assistive technology is widely adapted that it becomes not really considered assistive technology. It just becomes considered normal, and many, many people benefit from it. One of another good example of this effect would be closed captions. I love keeping my captions on when I'm watching anything, whether videos or Netflix, whether there's noise going on in the background or my ears are struggling a little bit that day. I know I'm a big captions fan. It's one of those things that might have been intended for folks with a certain group of folks who are having auditory issues, and it ended up helping a lot of different people. So going a little bit zone in it, how can we practically apply this? Html is going to be our guide today for developing with accessibility in mind, HTML is a powerful tool for continuing to make our code more accessible because of so much already built into that into HTML, and we're going to explore more into that in the next few slides. There is one main takeaway I'd like you all to leave today with is use the appropriate semantic element for the job. Today. We are going to I see Melissa, I see your class. Thank you. We are going to be using the right tool for the job. We're going to use semantic HTML elements for their intended purposes. So headers need to be a header. Tag paragraphs need to be a paragraph. Tag buttons need to be the button element. We're gone are the days of using DIVS and styling them into buttons, which is I'm guilty of as a newbie coder. I was definitely subject to those pitfalls and I didn't know any better, but I knew better now. So let's look at what that looks like. So we're going to aid a screen reader by stretching your HTML document appropriately. This is an example of HTML that is semantically used appropriately. So we've got a NAV element with an ordered list, different list items, and we've got the right tools for the job. We've got our headers, we've got our paragraphs. We know exactly what's going on here, and it's also very readable, even if you're just looking at the code, you know exactly what this document is. The intention for this document is, and we're going to compare it to presentational. Html, which is Firstly, just terrible to look at. It doesn't look good at all. We've got way too many DIVS in here. We've got some weird styling in line. There's no paragraph. So if we go back to the appropriate structure, a screen reader is going to read each header as you go through the content, it will tell you what a header is. A link you can jump around with a screen reader. If it's properly structured, the screen reader will pause after each element and give the user more control. If it's written like this, it's going to just basically kind of the screen is going to blast it all out and the user is going to be like, I can't navigate through this web page. Like, what am I? It just makes a terrible user experience, which is pretty. If you think about all the effort you take to write your code and then it's just an awful experience for someone that's like that hurts my soul as a coder, thinking about what their experience would be like. So let's go into some of the main offenders. My intention today is not to blast you with a ton of different concepts. I wanted to go into some of the main points that you can incorporate immediately, that you just stick in your brain a bit that maybe you might be doing an anti pattern and we can just tune it up. So we'll look at some of those main offenders that are really easy to make fixes for UI controls are going to be where we start. This is the stuff users interact with buttons, links, and form controls. So by default, what's so powerful about these UI controls is browsers allow keyboard manipulation. How many of you all have just tagged your way through any kind of form or anything or button you hit return and enter that's boom accessibility built in for us. You get accessible features for free. On the contrary, if you are making a Div into a button that is not accessible at all, it typically won't tab into a Div. You have to write the code for that. You'll have to make a very long element with a bunch of different attributes and also add JavaScript into this Div just to make it remotely accessible. But if you just use a button, you get it all for free. It's super clean. It's already done. It saves you a ton of time. So we're using the right tool for the job. We're using a button where we're needing a button and a link where we need a link. Form control where we need form control. Another main offender are images and alt text. We always are including an all attribute on our images and another one that again I'm guilty of, is not naming files appropriately, and we'll see an example of why that's important. But if an image is visually necessary, if the user needs to understand what is going on in the image, we're going to use descriptive alt text. If the image is not necessary for the user to understand what's going on here, we're going to include empty alt text, and I've got an example coming up for you on that one. And then finally, another offender is not including form labels. I've got snippets for all of you guys on this as we move forward in the presentation. But again, including labels will improve how screen readers understand form elements, inputs, et cetera. Again, just increasing the user experience. They're not lost in the dust. Like what is going on here? What form are we even filling out? What is this input? So an example of the image that we just talked about and not using alt text. So for this first one, how does the screen reader interact with it? Well, it'll just say probably dancer JPEG it will read out the file name. Really not very useful. If this file name was zero S-H-T-L-P-Q-R-S-T. You can imagine how frustrating that would be for someone to hear that and not have any idea what this image is. Is it necessary? So that's the really big importance on Firstly naming it? Well, but we wouldn't want to stop here on this first one. We want to at least go to the second one where in this case, the screen reader might just say image or possibly skip over it instead of reading the file name because we did include that MD text. Maybe this image isn't visually necessary for the reader to understand the application or the user. And finally, another option is using a descriptive alt text. So a ballerina is pictured in a purouette pose where the image is visually necessary. And this is what the screen reader would read out. And it also might read out the file name as well. Different screen readers have different functions, and we can talk about accessible HTML without talking about Aria attributes, which stands for accessible, rich Internet applications. Aria is a really powerful tool for if you have a component that you don't know how to make accessible or it's not clearly obvious. So yeah, it's a set of attributes that define ways to make web content more accessible, but a key thing to know about Aria to supplement HTML. And ideally, we can use semantic HTML first, and Aria second, that won't always be possible, obviously. But Arias, that wonderfully powerful supplemental tool that we're going to consider when we are in one of those situations where I don't know how to make this component accessible. And Aria is quite extensive. It's one of those things for developers that it's great to just Google how to make this thing accessible. We're going to have an accordion example coming up shortly but you've got this thing. Don't you love it when you don't know how to do something in your code and you just Google it and Google tells you right there. This is one of those. This is one of those times. So here's an example of why we wouldn't want to use Aria first here. This would be functionally appropriate. It would be okay. We're using the role attribute. The screen here would say navigation. Here's a few links for navigation. But does anyone know what we would want instead of this dip here because we don't want to do Aria first here we want to do Aria second. So what would we put here instead of an Aria? Yes. Nav. I see the NAV. Awesome. So we're going to do NAV because this is just more readable, more maintainable, and it's better to use the semantication of first, if possible. Here's that accordion example of me just Googling. How do you make an accordion accessible? And this is the W three. Org, which is the Worldwide Web Consortium, a powerful community of resources, and it spells it out for you. Here what attributes you're going to include and how you're going to use it. So my intention here is not for you to read this whole thing. It's just kind of seeing what Google would give you when you're in an ambiguous situation. So Google. I love Google. Google's the best. Yeah. So that was kind of the main offenders of HTML, but we can't talk about continuing to write our code without talking about styling and how important it is to not style away our accessible elements. Someone mentioned color blindedness as one of the first things when I asked about different people's varying conditions or abilities, so we can really make beautiful semantic HTML beautifully structured, and then we can style it away and make it completely confusing and ambiguous to the reader or the user. So we are going to talk a little bit about not doing that. This is a great quote from Mdn. That kind of summarizes it. Well, in my opinion, the rules thumb, you can update the styling of a page feature to fit in your design, but don't change it so much that it no longer looks or behaves as expected. Again, zooming out. My intention for this talk is little tweaks little things to just remember. Keep in mind, we can build these beautiful, extensive applications that are powerful, but it's not necessary to style the heck out of them so far that no one even knows what they're doing. And guilty of charge right here. When I first started coding, I just got so CSS happy and I was making a whole big mess. Honestly, this kind of gives the developer more freedom and the way I think about it as like a bullying alley, I've got my bumpers up and I'm going to roll the ball and it's going one direction. I have a little bit of room to play, but the ball doesn't serve me. If it's six lanes down, it doesn't serve the user. But if it's right here contained in this bumper in this clear pathway, it's getting the job done. It's accomplishing what we're trying to do, which is hopefully get a strike. So here's some fast facts for styling to keep in mind again, just keep the function obvious. We're going to keep headers looking like headers, paragraphs, links, list controls, et cetera. Let's keep it obvious. We don't want buttons flying across the screen, keep links visually different from non linking text, and another big one that would I'd encourage Googling again, is the proper text contrast because there are a bunch of different kind of specs for the text contracts that we like for different sizes of text and what the purpose is so really fun. Text contracts has been a really fun one for me to explore, because I have a resource coming up in the next slide. You'll see, I like to think of it as my grandma, the lowest common denominator. Imagine your sweet grandma trying to read your web page. I know my mom. I can't hear my phone. Give me my glasses like I can't read this. So thinking about my grandma reading my application I made, is it going to be a good time for her? And then back onto that contrast I was referring to. There's so many amazing resources that and we're wrapping up here shortly. So many amazing resources that to test your accessibility contrast ratio, dot com is a fun one. This is the colors that I've been using on some of my main point side. So that was that bright Orange and the white and you can see it's. Okay. It's not great. I like getting a green check Mark. Orange is not perfect. So it's a really great resource to show you how I'm doing. And that passes like the AA compliance for WCAG, which is cool. You've got all of these resources to help you out. So the last part of this talk is going to be a quick application of what we know. So I would love if anyone was to speak up quickly. I know I want to be mindful of everyone's time, but we're going to look at this application and see a few of our pitfalls and how we're going to fix those. So does anyone want to just shout out something they see that they don't like here? That might not be very accessible. Melissa, you're in my screen. So I keep seeing you laugh. Kamla, what did you say? The alt tag for the source on the yeah, there's no alt tag here, and Vs code is helping me out and actually telling me that I need an all tag. So yeah, we're missing an all tag. Definitely. What else do you guys see? There's a lot of conversation in the chat about the color of this text. Too many dance red text on background. No button tag, no alt tag. Shout out to what you don't like in terms of accessibility. Yes, I love that everyone is offended by the red and green because that was totally my intention here. Could a red and green color blind person even see this page? Probably not. So something to keep in mind. We are missing the alt tag. The image is also named terribly. It's kind of hiding up here, but Import Oregon from assets ever at McIntyre, it's like this crazy, Unsplashed JPEG name. So again, not good. We're also missing form labels here, which would mean that when a screen reader reads this form, it's saying Edit text blank edit. What? So that's the power of including four models. So let's take a look at a better version now and again. Even this JavaScript is not very good. I'm not talking a lot about JavaScript. I'm not talking about JavaScript at all today, but we even want to be mindful about how our alerts are popping up accessibility wise. So even there's an offender right here on line eight. So here import Oregon has a much better file name. We have included that alt text, a forested road with a welcome to Organ sign. We're including those form labels. So now the screen reader is reading first name, edit text last name, edit text submit button back here. The screen reader didn't even read the button because it's a dip. The screen reader can't even see it. You can't tab with a keyboard onto the button. So here you can tab through the whole form. The screen reader will describe the image and this would be a much better application. So that is what I had prepared for you all today. These are some of my favorite resources for accessibility. Go ahead and screenshot. If you care, I'll give you a couple of seconds to do that. Thank you all for joining me in this conversation about how we can develop with accessibility in mind and just tweak a few of those what we're already doing to make it better. And I also have my LinkedIn right here and a QR code because women who could use QR code. So I wanted to use a QR code if you all are interested in connecting with me on LinkedIn. Actually, it's Meg Schulmeister. It's not Megan Shellmeister anymore. So Megshowmeister 19 is the rest of the URL. I got a typo. I also will add it to the chat, but yeah, and I can put the resources in the chat as well. I also am trying to improve as a human. So if there's any advice or feedback you have for me, I'm open to it. If I could have used better market inclusive language, please let me know if I made any errors. Please call me out on it privately. At some point I would love to have some feedback, so thank you, everyone. And that's. Hello.