 Hello. Hi everyone and welcome to Aria Winninson, How to Achieve Accessibility Wins on your next project. Come on in, take a seat, let your hair down. Let's have a good time. Hi, my name is Kaylee and I'm from Chicago. I'm a front-end Drupal developer and yes, I am open to work. Some of that will be fun to talk about later. A fun fact about me is that I love Korean dramas. How I got into accessibility and all that fun jazz is my sister. She shared with me her journey in discovering these different accessibility tools and it was cool to learn alongside her and as I learned more about those tools I was inspired to do some of my own research and make sure that others could use accessibility tools easily on the projects that I create. I'm Irene Doggs. I'm a front-end Drupal developer and I'm based out in Denver, Colorado. I work at Bounteous and I've been here for about four and a half years. A fun fact about me is I love hiking and camping. I got into accessibility because my family is all developers and QAs and so we tend to talk about work a lot in our conversations and so one time at the dinner table my mom was talking about some accessibility bugs she found on a project that she was working on and I asked her what accessibility was and became more interested as I started to learn more about accessibility and just want to make sure that I can deliver the most accessible solution possible. Wow that's kind of heavy. Before we get started let's get on the same page about what these four wonderful words are. The first one accessibility meaning the quality of being easy to approach, reach, enter, use, understand empathy meaning the psychological identification with or vicarious experiencing of the emotions, thoughts or attitudes of someone else and ARIA which stands for accessible rich internet applications is a set of roles and attributes that define ways to make web content and web applications more accessible. And then lastly we've got WCAG. I'm sure you guys have heard that word thrown around a lot. It stands for Web Content Accessibility Guidelines and it's an international standard. WCAG documents explain how to make web content more accessible to people who are differently abled. So we often find ourselves working on websites that are not always accessible. Accessibility is essential for those who want to create high quality sites or projects and not exclude anyone from using their products and services. So starting the process of making a site more accessible can seem like a challenging task. It can involve things like audits, collecting data, creating tickets, and sometimes even explaining solutions to other developers and your clients. And then ultimately it's taking all of these updates and pushing those to production. This process is incredibly overwhelming. But as Tim Berners-Lee said, the power of the web is in its universality. Access by everyone regardless of disability is an essential aspect. So therefore it's important to make sure you take time and care when addressing accessibility issues to welcome your site or project to a wider audience. It can be a long and painful dance when done infrequently, but we have seen firsthand how tangible and accessible accessibility can be. So we found success in a step-by-step approach and we'll talk through this approach and hopefully you'll see how you can make small steps to make accessibility enhancements on your next project. So we had a problem. As I was discovering about accessibility tools and I decided to be curious, much like this cat is here and just poke around on the sites that I was working on, I discovered that the accessibility tools when I tried to use them didn't always work. And then I discovered, oh, I found a bug and another bug. And as I started going through this process of discovering, hey, these accessibility tools aren't working on the projects that I'm creating, I discovered that accessibility can tend to be treated like an afterthought. And so I posed this question to you. Are we thinking about accessibility when we're thinking about our company websites? And you definitely want to be curious. And that curiosity can help show and reveal a lot. You can't use what you don't have, so you might want to go poke around. And our solution was this process. We were able to work on creating, not just creating empathy, but taking the empathy and doing something with it. And being driven by empathy, we were able to draw attention and identify that there was accessibility work that needed to be done on the project. We were able to research and gather resources to get buy-in from leadership. Once we got that buy-in from leadership, we were able to delegate, I would like to say we delegated wisely and assembled the right team. And with that team, we were able to make some really awesome repairs and perform abbreviated audits. So the first step in our process is identifying that there is accessibility work to be done. Hashtag fun fact, there will always be accessibility work that is needed. The dance of accessibility is one that never really ends. There's always more accessibility enhancements that can be made. As some of you may know, focusing on accessibility at the end of a project can be quite difficult. And it is much more efficient and easier to identify accessibility problems early and often. So some of the ways we identified accessibility work to be done on our project was we took things page by page. So we started with our home page and then moved on to our more high-traffic pages. Another great way to identify work that there is to be done is to try walking a mile in someone else's shoes. So try not using your mouse and navigating your site with your keyboard or try closing your eyes and using your screen reader. Are you able to put items into your cart and check out? Are you able to go from page to page? And then another great way to identify work is pinpoint painful spots. For us, we had a lot of keyboard traps on our site, which occurs when a keyboard user can't move focus away from an interactive element. And so we identified painful points like that. And much like what these beautiful penguins are doing, the next step is getting buy-in from leadership so you should hashtag share it. The proof can be in the pudding. We have lots of reasons for investing in accessibility and leadership does as well. A couple of the main points would be to attract a greater clientele to avoid legal spiciness in the future to show your company pride and to get an edge in the field. In sharing with leadership and working to get that buy-in, it was really helpful for us to share tangible examples instead of being like, oh, there's an accessibility problem. We could show and say, hey, this is what this is. Walk through it with them. And while it's also great to share the tangible examples, it's also great to share your plans on how to fix those tangible examples. So the next step in our process is assembling the right team. For us on our team, we don't have a traditional looking team. None of the people that work on our team are actually allocated to this project. So we have a lot of people that come in and out. We also have a lot of team members with different development skill levels as well as accessibility experience. And we often have developers who are working more as a project manager on our project to help us keep organized. So we've found the most important thing about creating a team is really just having interested team members. If you have people who are interested and willing to learn and learn more about accessibility as well, it'll be a great experience overall. And it's important to remember that any step you make to make your site more accessible is a step in the right direction. The next step in our process was performing abbreviated audits. So hashtag mess around and find out. Our process consisted of going through the site and using tools for manual testing to complete our audits. And we decided to take this as page by page. This step was a lot like making a sandwich. You start with the bread, which is the audit itself. Add the jelly. Create tickets based on your findings. Pop on the peanut butter. Decide the complexity and estimate how much time each ticket will take. And after that, you add another slice of bread. Bread is essential for sandwiches and audits are essential for accessibility. The more you know, you know. Here are some of the big picture tools and some of the specific tools that we used. The first one is Wave. This is a suite of tools which allows users to do things from testing accessibility directly within your web browser to measuring your site's aim or accessibility impact score. This helped us figure out the spots that we needed to focus on to get a better idea of what was going on to get a bigger picture of how people were experiencing our site. And also it pointed us towards specific issues such as empty alt tags and empty form labels. The next tool we used was Axe DevTools. This is a browser installation that allows users to find accessibility issues on a site. And what I enjoy about Axe DevTools is that it shows you reports on your progress as you continue working on it so you can get an up-to-date or live image of how your site is doing. The last big tool that we used was SiteImprove. This tool gives you an insight on how accessible your site truly is. And using these three tools, Wave, Axe DevTools, and SiteImprove helped us get a bigger picture of the issues that were going on and it also helped us really narrow in on the global issues that were affecting the site. But we didn't just use big broad tools, we also used specific tools. We used two specifically, the first one being HeadingsMap. This is an extension that generates a document map or index of any web document structured with headings. We used HeadingsMap on projects to make sure that the proper heading structure is there. And lastly, we used Color Contrast Analyzer. This is a website and it allows you to analyze the text color contrast problems on a web page according to the WCAG to text color contrast requirements. Try saying that two times fast. We used Color Contrast Analyzer to ensure the colors on our website were accessible. So as you can see, there are lots of tools you can use to help identify accessibility issues. However, no tool alone can determine everything. This is why we recommend checking and testing manually for accessibility issues. So one way we manually test is we typically use the keyboard to navigate through the site. So using your tab or arrow keys, you're able to jump from one interactive element to the next. And to activate a link or a menu item, you're able to use the enter or the space bar key. So when we use the keyboard to navigate through the site, we make sure there's no keyboard traps and that all of the links and menu items are reachable and function as intended. Another way we manually test our site is using the screen reader, which is a form of assistive technology that renders text and image content as speech or Braille output. And so for our project, we like to use the screen reader on both the desktop and mobile devices and we listen over every page to make sure that the content is understandable. And so then another area on our site where we saw a lot of issues with was zooming the page to 200% and still making sure that not only assistive technology works, but all of your content is still readable and functions as intended. And this is actually a WCAG criteria. And as you can see in the screenshot, when we zoomed our screen into 200%, it's cutting off a lot of the content as well as a CTA. So for a user that's using their mouse and is sighted and looking at the screen, they're missing a lot of content. But if you were to navigate with your keyboard, you were still able to reach that CTA. And so we found using a combination of these tools and manually testing has helped us catch more of our accessibility issues. And so the final step in our process was creating tickets from the audit. And so for us on our project, when we create tickets, we like to make sure that we add as much detail as possible because we have a team that rotates out a lot. So we want to make sure that no matter the skill level of the developer or the accessibility experience of that developer, they're able to pick up this ticket and understand what the problem is and how to fix it. So as you can see on every ticket, we will identify whether it is a global issue or a page specific issue. And so we'll add a link to that impacted page. And since in this particular example, it's a global issue. We also marked that this is located in the footer. And so then we will give a brief description of the issue. And so this issue is about a keyboard trap. And so then we'll explain why this issue matters and also the WCAG criteria so that whoever picking up this ticket can understand like more about the issue and why it's an issue and they can read into the WCAG criteria to understand how it's supposed to properly function. And then we will give a suggested solution. And then we will usually include an image or a video. And since this is talking about a keyboard navigation issue, we included a video here. Before we leave this slide, you guys might want to take a picture of this type of ticket. It makes accessibility accessible for developers. So now that you've completed your audit, you're probably thinking once you finish all of these tickets, you'll be done, right? Well, accessibility is a never-ending process. So once you complete all of the tickets from your audit, you'll start this process again. So you'll look to see what accessibility work there is. You'll get your team together and you will begin the audit again. Especially if you do this process like us where we did things page by page, this process becomes very continuous. So once you've done the process like this a few times, you'll see that it's much more effective to include accessibility considerations at the beginning of your process. This is what shifting left means, placing accessibility earlier in your development cycles. Developers and especially our QA team members are the last step in making sure that we're getting accessibility right. So shifting left is all about bringing accessibility up to your project managers and designers and talking as a whole team about accessibility when you begin your projects. So does tackling accessibility still seem overwhelming? I really hope not. Accessibility, while it tends to be an afterthought, impacts so much. With an accessible site, you can attract a larger client base. You can dodge legal jazz that's not so great. And you can show your company pride and get that edge in the field that I'm sure we all want. One thing to keep in mind is that every finished ticket for accessibility is a victory and needs to be treated as such. Big or small, I don't care if it's just, you know, you fixed a hovering effect or something like a keyboard trap, any finished ticket is a big victory. And here's how you can learn more about accessibility in the Drupal community. So Drupal has an accessibility community and they are striving to attain WCAG 2.1 AA standards for Drupal. And Drupal is also striving to shift left by fixing accessibility issues in the development process. Sometimes the accessibility community will even delay releases because there are still accessibility bugs that are open or barriers for users. And so a high priority for this team is to build a platform that is accessible by default for example, all the work that went into the Olivero theme, which is now the default theme for Drupal 9 and 10. So if you're looking for more ways about how you can get involved in accessibility in the Drupal community, you can join accessibility in the Drupal Slack, and there's also ally office hours. So leveraging some of these tips helped us on our accessibility journey. And as Kaylee mentioned before, it's important to celebrate all the wins, whether they are big or small. So some wins we had on our projects was our light house accessibility light house score improved, meaning we've been able to increase the audience that can consume our site. And we had a footer usability issue with not only keyboard users, but users that use the screen reader. If you were to navigate through our site with your keyboard, you would come across an accordion that was acting as a keyboard trap. The accordion would only toggle open and close, and you were never able to get into the content inside the accordion or the content that was past the accordion. And if you were coming to the site with the screen reader, even if the accordion was closed, it was still reading all of that content inside of the accordion. So we fixed that now so that when keyboard users are navigating through the site, they're now able to actually navigate only inside the accordion, but to the content that's past the accordion. And then users using their screen reader, if the accordion's closed, they're not hearing the content inside the accordion, they're moving on to the next. But what we considered to probably be our biggest project win is all the accessibility knowledge that we were able to share and gain. Kaylee and I didn't have a lot of accessibility experience when we first started on this project. So doing the audits and testing stuff with our keyboards and screen readers has helped us learn so much. And so we've been able to share that knowledge not only within this team, but also to our other project teams that we work on. And so speaking of our team, we wanted to thank our team and we also wanted to talk about how our team is made up. So no one on our team is from the same team. We have some Drupal developers, some marketing developers, Solution Engineering developers and QA. We also all have different developing skill levels. We have some associate principal developers all the way down to apprentices that were helping us out on this project. And we also all have a range of accessibility knowledge. We have an accessibility SME, as well as people like Kaylee and I that really have no accessibility knowledge before we started on this journey. So do you want to level up? As you can see, putting the work in for accessibility really paid off. And our process was to draw attention by bringing it up to other developers, management and so forth, shareholders. And we were able to research, gather and gather resources which helped in those different conversations. And after getting buy-in, we were able to delegate wisely and create a really awesome team. And we were able to make some really incredible repairs. We did all of this because accessibility tends to be an afterthought, but having empathy and doing something about it, we were able to just get a big amount of changes that were able to happen. So I encourage you to think about projects that you are working on. Is there any that you know might need a little bit of extra love? Or have you learned any new tools and tricks that you want to try out on your site? I'm Kaylee and this is Irene. So, do you guys have any questions? Yes. Hence the research part, yeah. It's always helpful to have examples and, you know, WCAG can always help out in a pinch. For right now, it's all been manually testing, but we are looking into adding more automation for the project, yeah. If you have any other questions, you can feel free to talk to us later on. Thank you so much for coming.