How to Audit Sites Using Accessibility Checker ![rw-book-cover](https://img.youtube.com/vi/1CuNxS9TGsk/maxresdefault.jpg) ## Metadata - Author: [[YouTube]] - Full Title: How to Audit Sites Using Accessibility Checker - Category: #articles - Document Tags: [[video-notes]] [[youtube]] - Summary: How to Audit Sites Using Accessibility Checker (PART 2, Beaver Builder Accessibility Best Practices) - URL: https://www.youtube.com/watch?v=1CuNxS9TGsk Welcome back to part two of the BeaverBuilder accessibility best practices series. In this video, Amber Hines takes things a step further and talks about how to test your BeaverBuilder websites for accessibility, including the tools, techniques, and strategies you can use to find and fix accessibility issues to make your sites more inclusive. Let's get started. We've talked about what's bad about inaccessible websites, what's good when a website is accessible. How do you know if your website is accessible? I don't have enough time today to really go through all of this, but what I would say about the measurement of accessibility is that it is most commonly measured by something called the web content accessibility guidelines. These are internationally agreed upon testable standards created by volunteers in the worldwide web consortium otherwise known as the W3C. These guidelines come in different versions and they get updated over many numbers of years by collaborative groups. It's almost like an open source project like WordPress. Anyone can come and contribute to these guidelines. the current version for web content accessibility guidelines which I'm going to call WIKAG WC A. I'll pronounce it as WIKAG moving forward through this presentation. The current version is 2.2. Most laws around the world require a minimum of 2.1 conformance because these laws were written before 2.2 was established. I would highly recommend that you test up to 2.2 to because in the future laws may shift up to that. So I would always just target trying to meet whatever the current version of WIKAG is. In WIKAG it is made up of a bunch of what we call success criteria. These are testable things where you can either say yes or no. This applies to this component or this applies to the website as a whole. Uh so for example there is one the very first one is non-ext content and you could say does an image have alt text? If it does then that image passes non-ext content. Uh if it doesn't then it might fail if the image is important and conveys important information. Uh so all of these are intended as there's no gray area. They either pass or they fail. The success criteria have different levels of conformance based on how lowlevel or easy they are to achieve or whether they're considered the bare minimum for accessibility. There's level A which is the lowest double A which is in the middle. This is best practice and what you should be striving for. It is also what almost all laws around the world require is that minimum 2.1 doubleA and uh AAA is the highest level. Some rules like color contrast is a great example has both a double A version which allows a slightly lower level of contrast and a AAA version which is a higher level of contrast. By law, you'd only have to meet the double A, but you might consider striving for AAA because it would be the best practice and provide the best level of accessibility. Now, where do problems come from in WordPress? They can come from a lot of different places. The first one can unfortunately happen before the website is even built and that is inaccessible branding. Uh you can have we were just talking about color contrast. If you have brand colors that don't meet contrast, then before you even started building the website, you maybe were not set up for success because you were likely if you used your existing brand palette to design something that was going to fail Wikai. Then once we get into building the website, a lot of problems actually come from the way content is entered into the website. And we'll talk more about this in greater detail in just a little bit. And then this third bucket of where problems come from is code. And in WordPress, this code comes from a lot of different places. It can come from your theme. It can come from the plugins that you installed. It can also come from thirdparty inbeds. Like I've seen people using a third-party um embed like Survey Monkey to put a survey on their website and they just put, you know, a little snippet and embedded it in. That's an example of a third party embed. I have this graphic up here of Popeye, which I think is really funny. He's a cartoon character that looks like a sailor. He's holding his arms out to the side trying to hold back water that's spraying towards him. And I will say sometimes I do feel this way about accessibility problems that it's like trying to block all the problems from all of the different directions. It's not impossible. You can do it. You just have to be aware that there's a lot of different ways that can come in. And when you're choosing plugins, when you're choosing your theme, when you have people, especially if you are on a larger website where maybe there's multiple people entering content, you really just need to make sure that accessibility is thought about from all of those different perspectives and angles because they can all have an impact on the accessibility just like they can all have an impact on the SEO or the performance, the speed, the load of a website. It's very similar. So, how do you test for accessibility? How do you know if you have accessibility problems on your website? The first way, and what I always recommend doing first, is automated testing. You can use our accessibility checker plugin. I actually have a screenshot of accessibility checker up with our front-end module, which nicely works in the BeaverBuilder editor. So we can see here in this image that we have a photo open and it's a logo in a line of logos on this website and accessibility checker has flagged that that image has empty alternative text which if this was just a decorative image it wouldn't matter but obviously when this is a logo of a company who's maybe a client on of this website then we would want to make sure that we had uh the name of the company. So in this case, Malo Travel Inc. set as alternative text on the logo because that would tell blind people, oh, this is one of our clients. So automated testing is ideal because it allows you to do some testing really quickly and find some really obvious things without having to inspect code, without having to turn on a screen reader. And if you have the free version of our plugin, you can use it just like this in BeaverBuilder on a per page basis. If you have the paid version, then you can actually go and have it scan your entire website. And it doesn't matter if it has thousands, hundreds of thousands of pages, it will scan them all and come back and it will tell you, "Oh, there's a video on this page. There's images missing alternative texts on this page without you having to go into each individual one." So, I would always say start there with automated bulk scanning and try and fix those problems first. And then what you want to do is you want to manually test a representative sample of every type. What do I mean by this? So for example, test your homepage. Then you want to test an archive page and a single page for any post type you have. So that would mean your main blog page and a blog single. If you have a portfolio post type, then you'd want to test your main portfolio page and then go into an individual example of a portfolio item and test that manually. Any pages with special features. So, if you know that on this page we have maps embedded or we have a contact form or some sort of onboarding form, we have a checkout page where people can buy things. All of those would be considered a page with special features. And you want to do manual testing on these in addition to the automated testing that you've already done. When you do this, you do it first with a keyboard only. So what I would do is I would use my tab key to tab through all of the components on the page. You can use tab to move down and shift tab to go back. And the first thing I'm doing is I'm checking to see can I actually tab to all of the things that I expect to tab to. So, this would be like buttons or links. Anything that is interactive. If, for example, there's an accordion or a carousel on a page and I expect to be able to tab to it and then use my spacebar or my return key to use to trigger one of those buttons to open and close the accordion. If I can't tab to it or I can't open and close it with my keyboard, then that is a problem. So, I'd want to do all of those things. Make sure that you can take the actions you want people to take without using a mouse, engaging with all of the content, adding products to cart, checking out, submitting for form fields, all of those sorts of things. Then after I do keyboard testing, I'd turn on a screen reader. Screen reader testing is its whole other animal. Um, if you are on voice over, there is something called or sorry, if you are on a Mac, there's something called voice over that is already built in to your Mac, and all you have to do is turn it on. If you are on a Windows machine, then there is a free open-source screen reader called NVDA, which stands for nonvisual desktop access. You can download that, install it on Windows, and use it for testing. But you want to listen to things because sometimes things can look right with the keyboard, but they're missing important information. Like you might be able to open and close an accordion with your keyboard, but with a screen reader, you might hear that it's not saying expanded collapsed as you interact with it. So a blind person wouldn't actually know that that button was working even though you can visually see that it's working. So it's really important not to skip the screen reader testing step. And then I always recommend turning on reduced motion in your operating system and look at any pages that has a carousel or any sort of animations you've added to the page and make sure that when you have that turned on they don't actually go or they have significantly reduced animation if none at all. And then the next thing I'll do is I will open the web page. I'll zoom in in my browser 200%. And then I'll zoom in 400%. And basically what I'm doing at both 200 and 400% is I'm looking to make sure that things have their reflow set properly. So, you know, I don't have to scroll horizontally. They stacked the way we would expect them to stack. Really, it's like mobile responsiveness. But you need to check up to 400% zoom in order to meet WIKAG. And then in an ideal world, if you have the budget for this, you would also bring in screen reader users or people with other disabilities, depending upon what your target audiences, to test and confirm accessibility. I don't recommend necessarily doing that at the beginning. It can be helpful, but if a website has a lot of really obvious problems, you don't really want to have a screen reader user tell you, none of the images have alt text, right? These buttons don't have labels. I don't even know what they do. when you can have an automated tool tell you that you really want to bring in screen reader users at the end when you think I think this is really accessible and then at that point you can use them to confirm or to find like the like unique details that would make something much more understandable to a screen reader user than the obvious items. So once you've tested, you're going to have potentially a giant list of issues that you need to address. I have an example here with a screenshot. And actually, I'm realizing this is a little bit of an outdated screenshot from accessibility checker, but um this is from a a fake website that we've put problems on. I'll tell you honestly, if it's a really large website, you might see even more than this. This shows links opening new windows in tab 7,000 insufficient color contrast uh 2,000 area hidden 1,000 incorrect heading order 670. So it could be even bigger numbers than this which I know can feel incredibly overwhelming. So what you just have to think about with remediation is what are the most critical things that I can do first and and then how can I prioritize fixes and just start making fixes slowly over time. No one expects this to happen overnight. You just need to make slow progress or whatever speed progress you can make. If you can do some things really quickly that's great and then that's what is going to make a difference. So when I am prioritizing items, what I do first is I look at global elements. So I would look at my header first and say, can I have a goal of in the next month making the header and the navigation menu perfect or as workable as possible? Can I fix my color contrast problems? Things like that that are global that ideally I change it one time and it makes many components on many pages significantly better. And then I look at things that are critical blockers. So if I were looking at this specific issue on um this website, this list of issues, I might look at down at the bottom, there's only seven empty links, but those empty links could stop someone from being able to actually know what a link is about and be able to follow it. I would look for things like empty buttons. Uh, I would also think about from my manual testing, if there was a button or an accordion that I couldn't even go to with my keyboard and maybe let's say you were using a separate plugin, then you say, "Boy, I know BeaverBuilder's accordion works with a keyboard. So, I should this is a critical blocker that's going to stop people from accessing information. I need to spend time rebuilding these accordians to use BeaverBuilders instead of whatever separate plugin I was using for them." Right? So starting to figure out what are the things that are literally going to stop someone from being able to do something on a page. In that case, then that's would be my next priority. And then from there, once I've hit all of the global and the critical blockers, I'm going to start looking at pages where conversions happen. So think about your funnel on your website and start at the bottom. An example of this for an e-commerce store is I make sure my checkout page works perfectly and has no accessibility problems and then I move from my checkout page to my cart page. Then I move from my cart page to my individual product page or wherever it is people would add to cart and then I go to my main products like search and make sure that that is good and then I look at my about page or my blog post. Right? So thinking about the bottom of the funnel up and then the other thing that I'll do once I get to okay now I'm ready to just look at individual pages. I would then go look at Google Analytics or whatever analytics software you are using for your website and I would identify high traffic posts and pages and I would focus on those first. Uh, you know, a lot of people are like, "Our team page is so important." But then you're like, "Well, in reality, almost no one goes and looks at your team page. How about this other page that gets a lot of traffic or this blog post that gets a lot of traffic? Let's make sure that those are working really well because that's what's bringing people in. That's where people are going to get the information. And then you have these priorities and you just strategically roll out fixes over time. Can you fix one thing a week or one thing a month or two things a month? Whatever that might be. Figure out what that cadence looks like and just build that into your regular development and content planning strategy. Thank you so much for watching. That wraps up part two. Coming up in part three, we'll dive into accessibility best practices inside of BeaverBuilder. And if you haven't done so, I would encourage you to subscribe to the BeaverBuilder YouTube channel to get notified of upcoming videos. Bye for now., How to Audit Sites Using Accessibility Checker, YouTube, 01k9attms5tp8z9pd7kxvw52sy.