You. Hello and thank you for joining me for accessibility testing 101. Few little disclaimers just to get out of the way. I will mention some regulations in the course of this talk, but I am not a lawyer and thus am not. I don't feel comfortable with consulting too in depth th on individual regulations and how they might apply to you, how you might meet them, that kind of thing. Additionally, any views or opinions that are expressed by me are not representative of my company, necessarily my employers. They are mine. So just kind of a little cya there. Today we're going to be learning about what is accessibility? Why make things accessible? How do we decide what is accessible? Building accessibility test plans and tools and resources that can help you along the way as you work to make things more accessible. So, first off, what is accessibility? Simply put, accessibility is how well can someone access your content, services, facilities, regardless of whether or not they have a disability? And then with disability we're going to focus on it being a mismatch between the person and their environment, whereby the environment creates a barrier to them accessing information, services, facilities, things of that nature, and then assistive technology. Or you might also hear it referred to as adaptive technology. This is just any kind of software hardware that someone may use to help balance out that mismatch a little bit and allow them to access services and information more easily. And then you may also see the numerom a one one y, which a numero im is just when you swap out some of the better in a word for numbers, kind of like nerd speak in a way, and it's usually the end result is representative of what the original word was or what it meant. In this case, a eleven y means accessibility, and it stands for the fact that the word accessibility starts with the letter a, ends with the letter y, and has eleven characters in between. And you'll often see it used, maybe kind of an ode to sort of the nerdiness of numero nyMs, you'll often see it used for digital accessibility in particular. Now the following are just some different categories that you can use to kind of help you begin to think about how disabilities may impact someone's ability to access services, how you might be creating barriers unintentionally. These are not necessarily all inclusive. You'll sometimes see people divide them up a little bit differently. Here I've got them divided up based on types, time and visibility. For types I have hearing. So like someone having being hard of hearing, or being in an environment where maybe auditory signals just aren't going to be effective. We've got vision, so it can be, of course, like sight loss or being in an environment where visual stimuli or signals are not going to be effective at communication mobility. So someone could have be carrying a child in their arms and thereby have limited mobility for the time period that they're carrying the kid around. It could also be someone who has a limb amputation, a broken arm, someone who has sprained their ankle, anything of like that nature could technically be a mobility disability. And then comprehension. This could be things from ADHD, dyscalcula, dyslexia. It could also be things like if someone is in a state of panic, because think about it, if you're panicking, you are not thinking as clearly as you are when you're not panicking. This can be someone who has ADHD, like myself. Any of those kinds of things could technically count as comprehension. For time, we're looking at how long is the disability impacting, how frequently is it impacting the person? So it could be temporary. If I break my arm, ideally like six weeks, maybe a couple of months, my arm is going to be hopefully healed up and back to normal, for the most part situational. This would be something where, like, for instance, the parent carrying around the child, they're only impacted while they're holding the child, and then once they set the child down, things are good. It could be someone who has an anxiety disorder. There may only be certain situations where their anxiety tends to peak, certain things that cause them to get worked up. Permanent would be things like someone who has a limb amputation, that the limb is gone, unless medical science figures out a way to resolve that. And so that's kind of a permanent disability. Or if someone loses their sight because of a permanent injury or birth defect, something like that, that's not going to go away, most likely, and then visibility visible versus invisible. So just whether or not the disability is visually apparent to outside perception, for instance, someone who is blind, it may not necessarily be visible to outsiders that they are blind, or to what extent they are blind. For instance, in some areas, depending on the level of sight loss, someone may still be able to drive a car. So it may not be readily apparent that that person is blind. Someone who has a mental health condition, you're not necessarily going to realize it visually that there's something going on, versus if you see someone in a wheelchair or someone with the iconic white cane or a service dog, it's a little bit more visually apparent that, oh, there's a disability at play. May not be 100% sure what all is at play because there can be a combination. And that kind of is a thing across all of these is you can see a lot of overlap. You can see things that kind of vary back and forth between whether or not they're visible, invisible, or what types of disabilities, in terms of like hearing, vision, mobility, comprehension, are impacted. And also especially because a lot of disabilities, they'll have comorbid or other conditions that tend to happen with them. So, for instance, someone who has adhd or autism, it's very common for them to have other sensory impacting conditions. Someone who has certain musculoskeletal conditions, they may be more prone to having other issues at play. So there's kind of a mesh going on there. So why make things accessible? Well, simply put, by creating an experience where people can all access the same information and services, we help people. We help people make more informed choices for themselves and their communities. We help people feel more welcome, which can lead to better employee and customer retention. In a business world, we encourage diversity in our communities and workplaces because we're making people feel more welcome. And this can in turn lead to us being more innovative, because we have these more diverse lived experiences. So more chance that someone may have an experience that helps them think of an idea to a solution, to a problem that maybe no one else would have had the forethought to think of. And then there's also the fact that you won't miss out on the market because that little added monetary incentive, fortunately, sometimes it's kind of necessary. I've actually got an article here that is linked a hidden market, the purchasing power of working aged adults with disabilities, by the American Institutes for Research. It is very informative article. I really highly recommend checking it out. They actually state in that article that through research, it was estimated that the total disposable income for US adults with disabilities is about 490,000,000,000, which is comparable to other significant market segments, such as different racial segments and other age segments. You can read more in the article if you'd like. And it's also important to remember that according to the CDC, it's about one in four people that have a disability, and you tend to see that number be fairly consistent around the globe. So that can be potentially a huge number of people that if you're not making things accessible, you could be missing out on having those people as customers, because, I mean, if you're not making things accessible, they're not going to feel like you really want them as your customer. They're not going to have as good of an experience. They're not going to want to be your customer. They're not going to want to be an employee if you're not making them feel welcome and allowing them to participate. So how do we decide what is accessible? There's kind of a mixed thing at play here. It's a mixture of your own personal experience, because as you build different experiences, different facilities, sites, web applications, anything of that nature, you're going to be able to see for yourself kind of what impacts different experiences have. You'll be able to get user feedback which is going to feed into that experience and help you better identify different issues that might cause barriers. That user feedback in particular is very important because going back to the other slide, the whole having a diverse array of customers and employees, when you have that greater diversity of employees and customers, you're going to get more different lived experiences, because even amongst people who have the same disability, it may present different, they may have different symptoms at play, they may have different comorbid conditions. It just may impact them a little bit differently. And so getting that wide array of user feedback is really going to help with building your experience and making it easier for you into the future to design a more accessible experience. Additionally, we have guidelines that we can use. Most notably is the different worldwide web consortium, or w, three c guidelines made by their web accessibility initiative. The most known one, of course, amongst these is the Wikag or the web content accessibility guidelines, which is currently in version 2.1. And version 2.1 is what the majority of regulations around the world are based off of. However, it is important to note that when it comes to different guidelines like wakag, these are starting points. Even in the Wakag guidelines, if you read the sort of the introduction portion of it, they very specifically state that it's not going to capture every experience. Again, just because people can have such different presentations of different disabilities can be impacted differently by different visual, auditory and whatnot elements. And so it's very good to like, you want to try to be compliant with some of these guidelines, but don't be too strict because otherwise you may miss out on opportunities to make things more accessible. Some other w three C guidelines are the ATAG, which is the authoring tool. Accessibility guidelines basically deals with tools that you use to create content. So like Visual studio, Microsoft Word, Adobe Acrobat, things that you're using to create digital content. There's the user agent accessibility guidelines, or UAG. And this is basically browsers, media players, things that you would use to ingest or view digital content. There's the accessible rich Internet applications, or aria. This is a technical specification used to help make dynamic or interactive content in digital scenarios more accessible. And then I've got another one that I've got thrown in here that is not by the w three C, it's actually by the US government, a different portion of the US government whose name has just eluded me. But it is the accessible electronic documents community of practice. And this is basically just a set of guidelines to help with creating more accessible documents, presentations, spreadsheets, pdfs, digital documents of that nature. So very highly recommend checking that out. They've got some great test plans and stuff that you can use to help with checking whether or not those kinds of things are accessible. And then of course there's regulations. That's the part that a lot of companies are incredibly worried about, because obviously you break a regulation, you open yourself up to lawsuits, fines, things of that nature. I will say that whole idea of getting sued for breaking accessibility regulations, yes, there are the people who do the drive by lawsuits, but the majority of the time when you see lawsuits for accessibility issues, it's because people have reached out, they've tried to get things fixed and not been successful, and so then they resort to a lawsuit to try to force the company's hands. So just keep that in mind. I think that's important to keep in mind that you can encourage your users to reach out and you can work with them to make a more accessible experience before you ever have to worry about getting sued. If you are actually listening to user feedback. Some common one regulations now I primarily deal with like north american regulations just because of my location. So the Americans with Disabilities act, or ADA section 508 of the Rehabilitation act of 1973, the Accessibility for Ontarians act, or AODA, which is a Canada regulation. And then if you want to learn more, the w three C under their web accessibility initiative actually has a page entitled Web Accessibility laws and policies. It's not always guaranteed to be up to date, and it's not going to be all inclusive, but it will give you a good starting point for looking up different regulations based on particular parts of the world. So how do we go about really building our test plans, coming up with how we're going to create accessible content? Well, the big thing is shift left. You've probably heard this before. If you've done any kind of software development, it can really be applied though to any kind of effort that you're making in a company, whether it be designing and deciding upon how to create a new facility, creating documents, a marketing strategy, anything like that. The shift left ideology really can benefit you with accessibility, and it's just the idea of including accessibility as early in the process, as early in the discussions, the designing, all of that as possible. So that way you're more likely to catch potential issues early on when it's a little bit easier to make sure that you do things correct and in the best way possible, versus waiting until the very end when things are about to go to production or already are just out in the wild and testing it and being like, oh wait, it's broken now we got to go back and potentially redo a whole lot that we didn't have to do. And that's also like the whole waiting until the last minute. That's kind of why there's the whole myth that accessibility is expensive. Usually it's not accessibility itself that's expensive. It's the fact that people wait until the very end, find out that they've made a huge blunder, and then they're having to go back and redo everything. And you'll see that if you're designing anything that can be a problem. If you don't bother to have users test something until it's already out in production and you're getting complaints, it's obviously going to be a lot more expensive to fix any issues than it would have been had there been testing and discussions earlier on to catch those potential issues. Having a good, healthy balance of manual testing and automated, I know people want to go automated, so there's less work, hopefully, and less repetitive tasks, less human error, that kind of thing. But with accessibility, you really want to have a nice, healthy balance because automated testing, I think the last number I saw was something in the 30% to 37% range somewhere in there of accessibility issues that could be captured by automated testing. And also because if you just depend on automated testing, you can have a site that's absolutely inaccessible, that completely passes automated tests with flying colors if people do things the wrong way. Right? If that makes sense, I've actually got an example that you can see. I've got a GitHub repo that I'll have shared at the end of this presentation, and I actually have a good site example and a bad site example, and they both look identical. And if you run the automated tests on them both, they are absolutely just, they pass with flying colors, even though one is atrocious when it comes to navigating it with any kind of assistive technology or just in general compared to the other. So again, having a healthy balance of manual and automated, then there's this. You may hear the term nothing without us used in the accessibility community a lot. And this is the idea of include people who actually are living with disabilities as early as possible. Kind of combine that with the shift left to include those people in the discussion early on. And this is also where that whole diverse customer and employee base can come in handy. Because again, you can have three or four people that have the same quote unquote disability who present very differently. So you want to try to include a good array, like a good diversity of individuals with lived disability experience, so you're more likely to catch those issues, maybe get that feedback early on. Now, you also will often hear, when you're looking up accessibility testing, the emphasis on screen reader and keyboard accessible just because something is fully screen reader or keyboard accessible isn't necessarily going to make it perfect. But typically if something can be consistently and well navigated with a screen reader or a keyboard, and I also emphasize the idea of using multiple screen readers, we'll talk more about that in one of the next bullet points. But if you can get things consistently and well navigated with keyboard and screen reader, it's going to typically be more likely that other assistive technologies will provide a consistent experience. You don't want to put 100% focus on screen reader and keyboard only, but just know that it does help quite a lot. But then again, going back to the nothing without us, that's also why it's important to then bring in other people with different disabilities who might catch issues that the screen reader and keyboard only users wouldn't have caught. Remember that a lot of accessibility plans are typically based around WiCAg, because that's just what a lot of the regulations are based off of, and because the WiccaG tends to be broken down in such a way that it's a little easier to build individual test plans based on some of the guidelines. But it's important to remember, again, that those guidelines are not going to be all inclusive. They're not going to catch all the different accessibility errors that may be present. And that's why it then becomes important to make sure that you're getting that user feedback. And also with the Wik guidelines, another thing that sometimes people get a little caught up in is as of 2.1, there is three different levels of conformance. This may change with later versions, at least how it's split up. There'll probably still be conformance levels that just might be labeled a little different, but right now they are AAA. And AAA A is basically like the accessibility things that you really shouldn't even be having to try. If you're using good practices, you should be hitting those things just no problem. Which also means that if you are breaking some of those, you really need to fix that stuff and maybe fix some of your practices. Typically what a lot of regulations are based around. And that's kind of like the good standard to try to hit. IsAA is like special use cases or nice if you can. It can make things a little bit better, but you don't have to be 100% aaa compliant. And in fact within the guidelines, it even kind of says that if you try to be 100% aaa compliant, you may cause accessibility engineer other areas. So you've got to be kind of careful about how you apply some of the AAA requirements. And then there could also be instances where some of the guidelines just don't apply. For instance, if you don't have pre recorded audio video content, obviously those guidelines are most likely not going to apply to you. So that's just something to kind of keep in mind. And again, making sure that you're being flexible build upon. You might use the Wik guidelines as a starting point, but then you want to build upon that to make more robust test plans. Another important thing, and this is kind of what I was kind of hinting at with the screen reader point, but you want to customize your test methods for different environments and you want to try to test across as many environments as possible. So like with screen readers, there is typically jaws and NVDA and narrator for Windows. If you can test across all three of those screen readers, that is awesome. Mac and iOS have voiceover, Android has talkback. You want to try to test across those different screen readers and environments when possible, because just the way that content can be interpreted by those different screen readers can vary slightly. There may be slight differences in what Aria, for instance, are compatible with those screen readers, or how those screen readers interpret that content, or even how different browsers interpret that content and operating systems. So it's really good to try to test across all those platforms. Testing across different browsers. Now, there may be some exceptions. So, like for instance, if you just have a native app on a phone and it's only available on Android for a particular business reason, obviously at that point you're only testing in that one environment. If you have an embedded system, something like on a smart refrigerator, well, obviously you're just testing it on that refrigerator. You're not testing it on your browser, your mobile device, that kind of thing. There's that flexibility there. You want to make sure to try to hit all the different environments that you can so you catch those little side issues. Unless you have a specific use case where it's limited to a particular environment. You can see a lot of example test plans. Two that I've got listed here are VGAR, which is the visa global accessibility requirements. This is just visas publicly available accessibility guidelines. They've got some little example test plans, tools and other resources that can be helpful. There's also the section 508 ICT testing baseline for web. This is as it says, it's section 508 testing. You'll see it used for the Department of Homeland Security trusted tester certification, as well as just general section 508 compliance testing. There's also a few other examples that I'll mention later on, but those are just two for now to get you started. So now onto tools and resources. These are basically tools that for the most part may be already available to you and you may just not realize it or are freely available. I'm going to mostly focus on things that are free here because those are of course usually the easiest ones too. If you're trying to pitch to your employer to get them to let you have access to things, those are going to be the easiest ones to get them to let you have access to. So first off, things that are built into your browser here I have the Chrome devtools that are available within Chrome and the Chromium based edge browser, as well as the lighthouse testing options that are within the devtools. The first set of devtools on the left, those are actually the rendering options that are available within the Chrome devtools. And those are accessed by, when you open up the devtools, there's a little ellipses that's labeled with, I think, customized devtools. If you hover over it and when you go into that, then there's a more tools option and then you can access these rendering tools and they just give you some nice little extra features that might help with making it a little easier to identify flashing content, simulating what it might be like if someone is using custom CSS, because that's what some people will do. And it's kind of like the effect that some of the assistive browser extensions, what some of them do is they're injecting custom CSS into a page to cause an effect that makes something more easy for someone to interpret. It also gives you color filters that will help to kind of simulate what it is like if someone has certain types of colorblindness. So it has a lot of nice nifty tools that might be helpful. Lighthouse is available within the Chrome devtools, and it's just a set of automated tests for accessibility, SEO, things of that nature. Now, this does fall into that whole be careful. Just because you get 100% on the lighthouse doesn't necessarily mean that your application is 100% accessible. Next, we have some that are actually built into your operating system. So on the left here I have the accessibility options for Microsoft Windows. I think this was specifically Windows ten. And then on the right is the accessibility shortcuts that are available within macOS. And there's kind of some similar ones that are available in iOS as well. Now, a lot of these are meant to help make things more accessible to users with disabilities. But of course, what better way to know if your content is going to be accessible to someone with a disability than to actually use the tools that that person would be using. So, for instance, there's different color filters, there's the built in screen readers. So for windows, that's narrator, iOS, Mac, it's voiceover. There's different zooming options, text scaling, things of that nature, even color filters that you can use to sort of get an idea for how accessible your content may be to users who are using those very tools. Now, there's also some different desktop applications you can get. The first one I'm going to show here is the color contrast analyzer, also referred to as CCA a lot of times by the Picello group, which is usually shown as TPGI. Now, if you just search for CCA by TPGI, it'll actually come up as this should be like one of the first results that comes up. And it's a free desktop application for Windows and Mac that just lets you see if you have a particular foreground color with a particular background color, how much contrast is there between those colors, and is it enough to pass different Wicca guidelines? And it actually lists three of the WiCCa guidelines that it's comparing against. And it'll tell you whether or not it would pass based on the regular size text for that guideline or the large text for that guideline. And it gives you a nice little description for each of those guidelines on what counts as regular text or large text and what the actual contrast ratio is that you have to meet. So very nice. And it's simple to use, so it's a good option. There are other browser extensions too that operate sort of similarly. This is just one of the common ones that you might see used, and it's free. Next I have Microsoft accessibility insights. Microsoft accessibility Insights is available as a browser extension for Chrome based browsers and also as a desktop application for Windows. The Windows desktop application has a there's an accessibility insights for Windows and an accessibility insights for Android that's both downloadable to Windows OSS and the for Android one is meant to help with. If you're developing Android applications versus the for Windows one, you can just test anything on Windows. And then additionally there are pipeline options that you can actually use to test when someone submits, like a pr request for instance, or if someone goes to build the application, it may run some checks during the build process. So something that could be very helpful to a lot of people. The nice thing about the browser extension is that it does give you fast pass options which are like your automated tests. And then it gives you an assessment option which combines the automated tests with a manual test plan which you could theoretically use as a starting point for building your own custom test plans. And then it also adds a few different little ad hoc tools which are just different little tools that you can use for testing color, contrast, tab order, and a few other different things as they add on to the application. And it's also open source. So if you see something that you notice is an issue, you could actually go in and recommend a fix for it yourself. I've actually submitted a pr to it. I was really happy about that. It was cool. Next im showing on the screen here is the wave tool. The wave tool is accessible through a browser extension and through a website interface. The website interface actually gives you the option to paste in the URL, or I think it gives you the option to actually paste in the source code and it'll spit out a report about different accessibility issues. If you use the URL, it'll actually display the page with an overlay and it'll highlight different potential issues on the page or things that you're doing right. So it's kind of nice to be able to see some of the good and the bad and the maybe a problem things on the page. It also gives you the option to right click on the page and it'll say wave this page. And then on the right here I have the browser extension for Axe devtools. Axe dev tools is made by DQ and there's a free option and a paid option. The free option will let you do a general scan. I think the paid option adds in like some automated color contrast checking and some best practice sort of testing. Similar to accessibility insights, it does also provide some manual guided testing options as well. In fact, accessibility insights is based off of the same Axe core API that Axe devtools is based off of. It's just different interfaces and a little bit different added features for each one. So you can kind of pick and choose which one you like best. One thing I will note too with a lot of the automated tests is say you have a page where you have different modals and such that open up, or frames that only get added if you click on certain buttons. When these things run their tests, they're only running the test on what's on the page in that moment. So they're not going to be testing like those different little modals that can pop up. They're not going to test if the page is different sizes and different just proportions that could cause things to reflow differently and for other things to move about on the page. So that's another reason you want to really keep in mind that automated testing is not conclusive. Next we have the W three C markup validation service. This is going to identify some accessibility issues and also a lot of parsing issues. So it can help you to note whether or not you've got maybe some HTML best practices that you're not following as well as you should. Maybe you're misusing some aria using bad values, and it'll just kind of give you a report. As you can see here, you can either upload a file, just give it the URL for the page, or actually paste in the source code, and it'll just give you a nice little report that you can actually export into different file types. So if you wanted to share the results with someone else, it would be very easy to do that. This does have the same limitation though, that it's only testing the page as it would be when you first open it, and it's not necessarily going to catch issues that might only appear when certain modals open up and things of that nature. Finally, we also have accessibility bookmarklets. Bookmarklets are like little snippets of JavaScript that you can drag up onto the bookmark bar that's usually in most browsers. You may have to turn on the bookmark bar if it's not on by default, but you drag these to the bookmark bar and then let's say you have a web page up and you want to see what kinds of heading structure you have on the page that's recognized you might have a headings bookmarklet. There actually is one under this accessibility bookmarklets option here and it would actually highlight all the accessibility bookmarklets. There's basically bookmarks like for bookmarklets for checking for just about anything, aria, form, structure, landmarks, text spacing and then one of the more robust ones is the Andy tool. I might try to actually show that one here real quick when I get done here, depending on how much longer it takes me to get through all these slides. Also, there's a lot of books out there that can help. Three that I've got here are inclusive design patterns by Hayden Pickering, form design patterns by Adam Silver, and inclusive components by Hayden Pickering. Inclusive components in particular is really nice because Hayden actually has a website version of the book that's completely free and it shows a lot of great examples for how to make certain components in an inclusive way. It is important though, to remember with anything like this that just because someone suggests hey, here's one way you can make a drop down menu, here's one way you can make this particular form component. Doesn't mean that that's the only way, but this just gives you a good starting point. Additionally, there's some other resources I have listed here. Links for NVDA, which is a free open source screen reader that a lot of individuals with sight loss use. There's accessibility insights that I mentioned earlier, information about narrator, voiceover, Talkback, the Microsoft Accessibility page, Microsoft's accessibility fundamentals course, a link to Andy and the accessibility page on my own personal site which if you go to the accessibility page on my corgi dev.com site, I do actually have every resource that is listed in this presentation is also present there, as well as links to my GitHub where you can view these specific slides if you'd like. And in fact right here I'm just going to show on my little thank you slide my corgi dev.com site as well as my GitHub site which is GitHub Comcorgydeva eleven materials. If you go to that, it will actually have this presentation under presentations and then 2023 presentations. And with that we're just going to switch over to another screen here so that I can actually show you some of the tools and concepts that I discussed earlier in this presentation in action. So first off here you'll see I've got my good site, bad site. Neither one is really a good site, it's just good for this example, but visually they have the same general layout. We've got the header logo, some navigation links and then some headers, paragraphs and images that constitute the main content of the page. And some footer links and a little copyright down here for the footer. Now if I actually inspect these pages, the big thing that you'll notice here is that there's the head, the body, but then inside the body it's basically all divs. For the most part. All the text is inside of either paragraph tags or spans. There's no header elements. All the images have alt attributes that are null, which would indicate to assistive technology that they are just decorative and not informative, which is not the case here. There are no nav elements to help describe what areas are navigation links. There is again no headers. The footer is just a div with a list and then a div that has some text in it. Versus if I go over to my good site example and I inspect that one, you'll notice that inside the body I actually have a header that headers the image. It has an alt attribute. All the images on here have alt attributes that actually have good values because that's the thing. I mean you can have an alt attribute, but if it doesn't really convey what the information is intended to be gained from that image by the user, it's not really good. Alt attribute text. I have navs now since there's a nav in the header and in the footer, you'll notice I actually have an AriA label on each one to help differentiate them. This is because some assistive technologies will actually list off the landmark elements for the user. And so if you just had two navs, they're just going to show up as two Navs. But if you add that Aria label, it'll actually label them for the user. So they say nav and then like main navigation nav, social media links or something like that. That way the user just knows that there are different types of links, maybe in each one, which can indicate to someone what they may expect to find there. Because if you think about it, when we visually look through a website, we're tending to look at how is the content grouped together, where is it positioned visually on the page. And that's giving us an idea of oh well, I can probably expect to find links for this thing I'm looking for. If I go down to the footer versus the header, we can look at how headings differentiate in view compared to regular text to help us pick them out really quickly and skim through and maybe identify what text has what purpose or what section is most likely to contain the information that we need. And so using all this proper semantic HTML, you're essentially doing that same thing for someone using assistive technology. You're allowing them to sit there and go through and just view a list of headings and skim through to the one that they actually need. You're allowing them to immediately go to the footer and look there for the content that maybe they're looking for and they expect will most likely be there. In my main, I do have some divs because divs are okay to use if you're just wanting to apply particular formatting or something to a section, but it's still good to make sure to use the semantic like I've got sections here, each section has an aria labeled by so we know what that section is actually for. Got my headers. My headers are all proper h one h two h three s. I've got paragraph text because that's perfectly fine to have nothing against having paragraph text. Again, I've got all my different links and whatnot laid out here with proper semantic HTML, and that's going to help with someone that's got assistive technology that they're using. Now, if I go to axe devtools, as one would expect, once I close the like pro info, you'll notice it has zero issues. It's good to go. However, if I go to the bad one and I also run that, it's also going to come up with zero. That's because automated tests are only going to be able to do so much. So like for instance, it's not going to know whether or not these images need to be null alt attributes indicating that they're decorative, or if they need to actually have an alt attribute with a value. They're not going to know if whatever value I give that alt attribute is meaningful and conveying the purpose of the image, or if it's just random generated lore mipsum text. It's kind of like how if you do AI generated alt attributes, it's not always going to be the accurate meaning of the image. So it's just something to kind of keep in mind. You don't want to completely depend on automated testing. You want to make sure to have a little bit of that manual testing in there as well. Okay, now im going to actually go back over here to my corgi dev accessibility page. Actually, I'm going to open this up in Chrome first, just because for some reason Lighthouse has been giving me trouble in edge the last week or two. Not sure what's going on there? So to show you Lighthouse, which again, as I mentioned earlier, Lighthouse is the automated testing tool that is available within Chromium based browsers like Google Chrome or the new Microsoft soft edge, you open devtools and you just select Lighthouse. It gives you a few different options here that you can pick from, including like you can actually do mobile versus desktop, which can help with that whole thing I mentioned earlier where automated testing isn't going to necessarily capture all the issues because it's not going to necessarily capture modals and stuff that might come up on your page that could have accessibility issues. It's just going to test what is visible on the page in that moment. Now im going to analyze page load here. Now the one good thing about it is since it does this page load, if you have tooltips and stuff that modals that just pop up when you initially load the page in, it will be able to test those, but it's just not going to test other things that might open later. As you can see, it'll give me this nice little rate layout. If I had issues that it picked up, it would display them here for me to be able to see them. And it also gives you options to export them, open them in a different viewer, different options that allow you to share them. Since we already have devtools open here, if I go up to this top, ellipses labeled customize and control devtools by its tooltip and I click that and select more tools and rendering, I get this little option window down here at the bottom and you'll notice it has things like paint flashing. There's no flashing content on this page right now. So that's not going to really do me anything right now. But it does give me some different emulation options, including this nice little one down here that gives me an idea of what different kinds of vision. I don't really like the word deficiencies impairments, but like vision differences, how that might impact how someone views your page. It is important to note that with any of these, it's not going to be as accurate as having someone that actually has these conditions since how these present amongst different people can vary from person to person. But you can get an idea, it can give you an idea if there might be some apparent contrast issues that could be problematic and then go back over here to edge. And we also have accessibility insights. Accessibility insights. The nice thing with it is, again, like I mentioned earlier, you have some of the automated options, but on top of the automated options you also have this assessment, which it does have the automated checks, but then it also gives you these guided manual tests. Now these are not going to be like all inclusive of different platforms that you could be testing your content on, but they give you a good starting point. And it can be helpful for developers who may not have as much accessibility testing experience just to kind of be able to have something that they can go through and they can get an idea of where they might need to make improvements. Additionally, we also have the ad hoc tools which you'll see. It just gives me options to highlight, do color contrast checks, tab stops, landmarks. I actually kind of like the way it displays landmarks better than some things that need review, the accessible names of things, and even some of the automated checks. Now the other thing that I mentioned during the presentation was bookmarklets. And I'm going to start with Andy. Now, I don't think I mentioned this earlier, but Andy was actually developed by the Social Security Administration and it's used for section 508 compliance testing, including the Department of Homeland securities trusted tester certification. And it just will pick up on different elements that it picks up on the page, which can be helpful too, because like for instance, there's a table and a frames module that can pop up with Andy. And so if you have a table on the page but the Andy table tool isn't popping up, that could indicate that you've got an issue with how you wrote your table and it's not going to be interpreted correctly by assistive technologies. Let me see. I don't know for sure. Okay, so now with some bookmarklets, one thing that's important to know is some of them you can just click the bookmarklet again and it'll close it. Other ones you actually have to refresh the page. So I've also got bookmarklets here for headings. I've got one for text spacing because some people that have like dyslexia or low vision may have stylings that they use to increase text spacing. So it's important to see that your content is going to adjust to that. There's a little code sniffer one here that'll give me some little tidbits of information about issues that might be on my page lists. You can find all kinds of these bookmarklets. And again, if you go to my accessibility page on my site, you can actually go to the reporting and testing resources section. And there are all the different desktop applications, bookmarklets and more that I covered during this presentation today that can be found here. And so with that, I do just want to say thank you for listening to my talk and I hope you'll check out my corgi dev site as well as my GitHub repo, which again is GitHub.com corgi Dev a eleven ymaterials and this presentation. The slides will be under presentations and 2023 presentations. With that, hope you enjoy the rest of the conference.