 And, Terrell, would you like to take it away? Yeah, sure. Thanks, Annemarie. And thanks everybody for being here. One of my favorite topics talking about web accessibility. We're both part of the IT accessibility team, which is part of UW IT Accessible Technology Services department within UW IT focused on ensuring that all the technology we use on campus is accessible. So you can go ahead and go to that first slide, Annemarie. One more click. Yeah, it's not working at the moment. Uh-oh. Okay. And I'll have to get used to not driving. And I'll try not to be a backseat driver. Go ahead. I'm tempted. I'm trying to click here myself and it's not working because it's not my slide deck. But anyway, as we talk about accessibility, we're talking about accessibility of websites and digital information, information on the internet. And kind of the traditional model for accessing digital information is you've got some means of communicating with the technology. So you get your input device and you've got some means of getting information back so you get your output. And the traditional model is a keyboard for input and a monitor for output or a screen. The mouse was introduced after the keyboard, but that too has been sort of part of this formula for a very long time that people would interact with computers using a keyboard and a mouse and a monitor. But that's a pretty old school model and things have changed significantly in more recent days. And now if you click, now we've got mobile devices. And so in a pre-pandemic when students were all walking around on campus, they were all sort of glued to their devices, it seemed, and still are. And that really has become more of a typical modality by which people are accessing digital information. And even with mobile devices, you've got a variety of different shapes and sizes and platforms and they all, depending on what sort of device a person is using, that has an impact on the content that they receive. It's not going to be the same thing for an iPhone user as what an Android user is receiving and so forth. And there are also tablets that come in similarly and different shapes and sizes and platforms. If you click a couple of times, Annemarie, we got tablets. We also have people not just accessing that output through eyesight, but accessing it through hearing. And so we have speakers on the slide here that symbolize that. But historically, this has been the domain of people who are blind, some case people who have low vision, where they're using a screen reader to access content on the computer. And so it's giving them that same output, but instead of giving it to them visually, it's giving it to them audibly. And that too has become the domain of a much broader audience these days as we can listen to our devices and get information audibly from our devices, which becomes more essential as we're accessing information while we're driving and so forth. And similarly with input, you can use voice for input and don't have to rely on a keyboard or a mouse. And you can dictate documents, you can use voice commands to access websites and web applications. And this too has traditionally been the domain of individuals with disabilities who maybe physically could not use a keyboard or a mouse, but they could use their voice. But now more and more of us are using voice commands to access information technology. Again, through our mobile devices, we're getting closer to that sort of hands-free conversational interface where you talk to our devices, they talk back to us and we exchange information that way. I also have here on the slides a touch device. So this is a refreshable Braille display. It has a row of dots that refreshes as the person navigates through a website. So essentially a person would use this, they would use this with a screen reader. And so somebody without eyesight would be either listening to content audibly or using a Braille device to feel the content through that row of dots. And this particular device also has some Braille buttons that can be used to input Braille through Braille as well. So that would be both their input and their output device. And I just ran out of space on the slide. So otherwise I could have gone on and on and on with assistive technologies that people use. Hundreds, literally hundreds of assistive technologies out there. If anybody can just twitch a muscle, they can access the computer, but that doesn't mean they can access your website. It means that they should be able to access everything, but that depends on everything being designed appropriately and coded properly so that it is accessible to everybody who otherwise should be able to access it. Next slide, please. So we've got a few examples just to sort of anchor this in the fact that we're talking about people, not just technologies, but we've got a few examples of people that we've had the pleasure of interacting with over the years and some of these are getting kind of old sort of lost track of where they are. But this is Jennifer. She was a public relations major and she physically is unable to use a mouse. She uses instead this IntelliKeys keyboard. So it's a large keyboard that has large keys and those keys are the right size for her to be targets for you see that in her right hand, she's holding a little stick and she can hit those keys with that stick. But she's not going to be a mouse user. And so there are a lot of people that physically are unable to use a mouse. If you think about a mouse, it is a pretty complex device. You have to hold it steady while you click and not everybody is able to do that. And a lot of people will use the keyboard instead or people use assistive technologies instead. The next slide shows Courtney who is a was a bachelor's was a communications major got her bachelor's degree in communications and now works for rooted in rights. And she's using one of those refreshable Braille devices that we talked about. So she can get all of her content through that row of dots. She's also wearing a headset. So I think a lot of a lot of blind individuals will use either audio listening to a synthesized speech screen reader through a synthesized speech or they'll use Braille and they may switch back and forth between the two depending on the content that they're reading. Next slide shows Courtney with Conrad. Conrad graduated from UW law and now is a prominent civil rights lawyer in Seattle and a big Seahawks fan. You see he's wearing the 12 Jersey there. But Conrad has very limited upper body mobility and so he uses a variety of assistive technologies to access the computer, including speech. He is one of those users who would use speech but also use a variety of other devices that will enable him to access the computer but not with a mouse. He's not going to be using a mouse. So if we move on to the next slide, you know, these are, Hannah also now works, I believe, with Facebook or whatever they now are called. I should know that. But she graduated with honors at the UW. I think she was majoring in physics as well as doing a lot of computer science and the picture here that we see has her zoomed in. She has very low vision and so she's using zoom text to zoom in on the content to magnify the content, which means that she only sees a very small portion of the screen at a time. So, you know, if things are happening elsewhere on the screen, then, you know, she might not be aware of that and it's important that websites be coded in a way that works with her assistive technology so that, you know, she is aware that things are happening outside of her current scope of view. So now if we move on to the next slide, the folks that you've just met are all individuals who qualify as having a disability and they then would be qualified to receive disability-related accommodations, you know, from disability resources for students as a student, that sort of thing. So there is a place for disability in our society for qualifying for those sorts of accommodations and benefits, but what I'm sharing with this slide is that it really is kind of a false construct. You have people with disabilities, people without. In reality, whether somebody is able to do something or not able to do something really just depends on what that function is that you're talking about. So if we're talking about site, the ability to see, then some people have 20-20 vision and some people are not able to see it all, but most of us fall somewhere on a continuum in between those two extremes. And so it really is a much more complex picture, not binary at all, that, you know, with disabilities without, it's, you know, where do you fit in the ability to see? Same thing can be said with the ability to hear, the ability to walk, read, print, write with pen or pencil, communicate verbally, tune out distraction, and so on and so forth. We could go into great detail, you know, in terms of functions that we might be looking at and people are going to be all over the map in terms of how well they can perform that function. So it's a complex landscape with a lot of differences between individuals and different technologies that we're all using in order to help us to perform on different functions. So this is where web accessibility comes in. We want websites that work for this vast array of people and all the differences that they have and different technologies they're using. Next slide, please. So web accessibility is creating a website that works for all users. And as we've just seen, all users is a very diverse group. Next. And it's creating a website that complies with web accessibility standards. So really it's all about that first bullet, creating a website that works for all users. But then the question is how do I do that? All users is so incredibly rich and diverse. You know, how can I make a website that works for everyone, including all these different characteristics? And that's where standards come in, that if we create websites that comply with standards and the browsers comply with those standards and assistive technologies comply with those standards, then standards provide that place in the middle where communication happens. And all these different pieces are able to communicate with each other. And then that user is able to access your website through standards. But it requires all of the pieces to actually support the standards. And so the only piece that we have control over is the website itself. We depend on the browsers and assistive technologies to support standards. And we can file bugs if they don't. And they're pretty good at that. Sometimes fall short, but generally they're pretty good. And so our piece of the puzzle is we need to make sure our website to meet the accessibility standards. So what are the accessibility standards? Let's look at the next slide. Most web standards, all web standards, not just accessibility ones fall under the scope of the World Wide Web Consortium, the W3C. This was the organization that was founded by Tim Berners-Lee, the person who invented the web back in the early 90s. And he, you know, soon after the web became a thing, he created this organization to oversee the web and, you know, HTML and all the other standards that made the web possible. So HTML is a W3C specification. Cascading style sheets or CSS is a W3C standard. They also very early in the 90s became aware that accessibility could be a problem. And this was not in sync with the vision for the web. The web was going to be this great opportunity to have information, you know, at your fingertips, regardless of who you are and where you are in the world, and it was going to revolutionize access to information. And so the very idea that there would be some groups of users who could not get access to that information because of their physical characteristics was not something that sat well with the founders. And so they created the web accessibility initiative, a group within the W3C who began working very early on in the 90s on the web content accessibility guidelines or WCAG, which is the accessibility standard today. And we'll talk about that in a bit more depth in subsequent slides. We also have another W3C spec that is ARIA, Accessible Rich Internet Applications. That is used to supplement HTML and allow where HTML falls short in making rich dynamic interactive applications accessible. ARIA steps to the plate and fills in some of those gaps and allows interfaces to communicate with assistive technologies in ways that make those applications accessible. So next slide, let's look at WCAG specifically because this really sort of forms the heart of our accessibility responsibilities that we're trying to meet standards and the standards we are trying to meet are the web content accessibility guidelines. I mentioned that they began working on this early in the 90s. They published the first version in 1998. And then every 10 years after that, they have published an update. So we're currently at version 2.1. That's the latest. It was published in 2018. And the 2.0 and 2.1 versions both had success criteria as their kind of the deepest level as you drill into the guidelines. When you get to the success criteria, you're talking about very specific things that need to be met in order for an application or a website to be accessible. And there are 78 success criteria. So quite a few. But most of our websites, most of those are not relevant for most of our websites. It really is a small handful of those that are applicable. But each one has a level assigned to it, level A, level 2A, or level 3A. And that corresponds both with the priority level and the difficulty. So it was kind of a balance between those two that ended up getting levels assigned to the success criteria. So the level A success criteria are super important in terms of breaking down barriers for groups of users that if you violate a level A success criterion, then there will be some users who have no access whatsoever to this feature on your website. And also it's attainable. The level A issues are all attainable. And level 2A is kind of a mid-level where they're pretty important, maybe not as important, or maybe they are a little bit more difficult, but still doable. And level 3A are either not as critical or they are more difficult to implement. And so early on there were questions, how accessible is accessible enough, if you will? Do I have to satisfy all 78 success criteria or is there some level within that that's acceptable? And what has become clear over the years, mostly through legal action, through resolutions and settlements, and then through policy that emerged as a result of that, it's become clear that level 2A is the expectation. And this is reflected in our own web accessibility policy or IT accessibility policy. And at the state level, we have policy 188 that requires all state agencies to ensure their IT is accessible. And it specifically says level, the WCAG version 2.1, level 2A is the standard that we are trying to meet as state agencies, including higher education is included within that. Next slide. So just to bring this sort of back to a level where you can understand it, here are a few examples. These are pretty common things we encounter as WCAG 2.1 success criteria. And these are all level A except the last one is a 2A. But the first is all text on images. If you have images, then you need to provide alt text, which is behind the scenes, a short text description of that image so that people who can't see it get access to it. If they're using a screen reader, whether that be listening audibly or using a Braille device, they need that alt text in order to access the content of the images. Info and relationships, this is all about making sure you have headings and lists and tables that are coded properly and forms that are coded properly. And using the code in HTML to explicitly identify what the different parts are. So if it's a main heading, it needs to be an H1. And if it's a subheading, it needs to be an H2. And there are proper ways to use HTML so that it communicates all that information so that particularly assistive technology users can understand the relationship between all those parts. Websites need to be keyboard accessible. You should be able to access everything with a keyboard that you can access. And so that too is a WCAG success criterion. Name, role, and value is kind of a more advanced success criteria, but it has to do with using ARIA properly for more interactive and complex internet applications. There also are a number of WCAG success criteria about contrast. There actually are three of them. Two of them at level 2A, which have specific ratios of foreground versus background that you need to meet. One of those applies to text. The other applies to images, but both are in there. And then there's a level 3A requirement with contrast that is a little bit more stringent to meet level 3A. You have to have even higher contrast. Higher contrast ratio than what you have to have in level 2A. So speaking of contrast, I'm going to hand off to Anna Marie and she can talk a little bit more about contrast and color. Okay, thanks, Terrell. Providing the slide to go in advance. There we go. Okay, so contrast. We were talking about adequate contrast between the front and the back. Because some users with visual impairments cannot consume content with poor contrast. So on the right side of my slide, I have an example of that. So there's actually two sets of tabs here from a web page. And the one on the top, the text is kind of washed out looking. It almost sort of fades into its background. And it's hard for folks with low visual impairments to be able to consume what is on those tabs. Even me, I have to like lean into my screen a little bit to be able to read that easier. And then in the second set of tabs, notice how the text is much darker. It stands out much more. It's so much easier to read. And that's not going to be just easier to read for someone with a visual impairment. That's actually easier to read for everyone. And since we're talking about color, I briefly want to say something about meaning. It's really important to avoid conveying meaning through color alone, because we may not perceive color in the same way that others do. And not that it's really wrong to convey meaning through color, but if you do, it's really necessary to provide a backup so that all of the content that you're going to be able to convey meaning through color alone. So what you do, it's really necessary to provide a backup so that all folks can get the same meaning. So for example, there's probably several ways you can do this, but the biggest examples would be underlining your links and your carousel lentils. They could be numeric and have different shapes. So on the right side of my screen, I have some examples here. The first set of examples, I have a sentence that says, it's a link to that page. But in the first one, it's not underlined and the only reason I know that it's a link is because it's a different color than the rest of the text. But if I have low vision, I may not be able to be able to see blue and black from each other so easily. So I may not even be able to know that there's a link there. So in the second one, getting help the link is underlined. So it's not just a different color. There's another hint that that's a link and that's the underline. And the thing about underlines is they've been there since the beginning of the web. So since the beginning of the web, folks know that you can, when you see something underlined on a web page, you can click on that and go to other content. And then the second example here, I have two sets of carousel lentils. The lentils are those little things below the slides that tell you which slide is in view. So in the first example, the only reason I know which slide is in view is because that lentil is a different color. It's yellow instead of white. But again, we're dealing with colors that might be so close together for somebody who has low vision, that they may not be able to tell which slide is in view just based on this alone. So in the second example, notice how the lentils all have numbers. And not only that, they have shapes around them. And I can tell that the first one is in view because it has a slightly different shape in addition to being a different color. It also has a border around it. And I know it's the first slide because it says number one on it. And then in my last example on this page, I actually really liked the way this is except for what is wrong with this. It has really poor contrast, doesn't it? We really can't read the two very well in that circle. So maybe if the circle wasn't filled in, if maybe it was just a circle, like a border around the two, it would be much easier to read. But what I like about this is it does have the numbers. So you know which number is in view. And it also has control. So before the numbers and after the numbers, I have arrows so I can go back through the preceding slides or I can navigate through whatever slides come after. So it gives the user some control over what they're doing. So a few web accessibility checkers. We're going to talk about a few of these today. But first, the very first one, your keyboard. That is a tool that all of you have right now, probably sitting in front of you even. So I invite you to take the no mouse challenge. And basically what that is is, so take your mouse and set it aside and don't even touch it and just navigate through the webpage using your keyboard alone. And so I'll give you a little hint there. You can hit the tab key to move forward in the webpage and to move backwards, you can use tab and shift together to move backwards. But we also have accessibility book markets available to use, web developer extension. Lighthouse is a Chrome in Chrome dev tools and also in Chrome dev tools from DQ is axe. They're site improved. There's wave from web aim, which includes color contrast checking, by the way. And there's the TPGI color contrast analyzer. So let's talk a little bit about accessibility checkers in perspective. Most accessibility problems cannot be automatically detected. But while, so while zero's errors is a great start, it's not really a guarantee because, you know, then we start talking about technical versus functional accessibility. So while something may be technically accessible, it's actual functional accessibility may still have barriers that mean it's more difficult for users to get to content in order to consume it. And note that all checkers are different. So results may vary. It's not necessarily right or wrong. They just may have different perspectives. So how can you learn more? That's a really great question. There's the UW accessible technology website, and we'll get the links in the chat for these for you. Our frequent events page on the accessible technology website where you can find things like today's webinar. Use an accessibility checker. So we have a tools page that has some various tools that you can use. And we have some demos to show you. So Terrell's going to show you the first few demos. So Terrell, go ahead and take it away. And I'll stop sharing my screen. Andrea, thanks for posting a couple of the links there. I just posted the one for the website that I'm about to look at, which is our accessible university demo. And let me pull up the right screen here. Okay, so this is a website that we created as part of a couple of grants that we had originally created on the access it grant, which was many years ago. And then more recently, we've updated it with funding from access computing, the National Science Foundation funded project. And essentially it consists of three pages at its heart. One is an inaccessible university homepage and an accessible university homepage. So it's the same two versions of the same page. And if you start with the inaccessible version, then you try to identify all the problems on that page. And then the accessibility issues page describes what all the problems are and what their solutions are. And then the accessible version shows that all of those solutions implemented. So I'm going to actually open each of those in a new tab. So I've got easy access to them. This is the before version. And in the interest of time, normally I would do this interactively and it works. That works really great in a live setting where we've got maybe a little bit more time to work with. But the heart of this is, as it says here, when you spot the barriers, there are 18, at least 18 accessibility issues on this page. And so it's kind of fun to think through, just sort of look at the page and ask yourself who might have difficulty accessing particular pieces of the page. And so Anna Marie has already talked about contrast. And I think this actually might have been that same image. But I think that these menus here have what seems to be pretty low contrast. And so that would be one thing that really jumps out. We also talked about the need for alt text on images. And we've got an image right here in the middle that needs to be described, it seems. And so, you know, what does this have alt text? That's a question, you know, in knowing whether this is accessible or not, you need to know whether it has alt text. There's also an image across the top is this banner of this as accessible university. And you may have noticed when I hovered over these menus, that they do have drop down menus. And so can I access those if I'm not a mouse user, if I take that no mouse challenge and just, you know, set my mouse aside, then am I going to be able to access that content. So just to show you a few of the checkers that were on that checker slide. First of all, the very first bullet was a test with keyboard. So keyboard is a great accessibility checker. Because you don't need any other tools and you all probably have a keyboard already. So, so right now I'm pressing tab. And I'm pressing tab again and tab again and tab again. And I have no idea where I am on the page. I've changed the focus now. I've moved down on the page, it seems, but I don't see any sort of indication here that I'm actually focused on anything. So, so this really is not at all accessible to me as a keyboard user. If I contrast that with the accessible version, now this is the same site, but now with accessibility enhancements. And you'll notice that it really doesn't look that different. There are very subtle things visually that have changed, but underlying all of that is much more accessible code. And if I tab now, there is clear visible focus as I move through the interface. I can see very clearly what I'm on, where I am on the page. And, you know, I can respond to that. So I just pressed enter to move on to something on the, because my focus is on the next button. If I shift tab and go back to the previous button, I can press tab and so forth. So in terms of other tools we might use, so the keyword is one across the top of my browser here, I'm in Chrome, but this also exists for Firefox. And I think you can use it probably in any browser, but these are bookmarklets that give us a really quick indication of whatever it is we're trying to look at. So landmarks is a really important feature of websites. If I, let me go to the after version first. If I click on landmarks, it draws a little line around different sections of the page. And then, and it tells me what that section of the page is. So up at the top, this is a banner. This is a navigation, the main menu. The main content here has main. Down at the bottom, there's a section that says content info. These are all what are called aria landmarks. It's part of that aria specification. That allows us to sort of section off on the web page, web page. Pardon my voice. And identify common areas of the web page. So if I do the same thing on the before page where it's not accessible, if I click on landmarks, it says no elements with aria landmarks are found and then it lists all of the possibilities that it was not able to find any of those. Similarly, if I look at this page visually, I see headings accessible university, even though that's a graphic that is sort of the main heading of the page. And then you've got all these subheadings. Welcome. Can you spot the barriers, AU enrollment trends, apply now? Those are all subheadings underneath accessible university and the headings should form an outline of the page. So if I'm a screen reader user, I can jump from heading to heading or I can bring up a dialogue box that shows a heading tree. And that really gives me a sense of how this page is organized and it allows me to navigate very quickly to a particular section that I'm interested in. So, but if I select headings now, it says no heading elements are found. So this, this page is completely inaccessible for a screen reader user. They come here. They'd maybe check for aria landmarks. There are none. They check for headings. There are none. So they, they are almost reduced to having to read the entire page from front, from top to bottom linearly and try to make sense of all this content, which would be a nightmare to have to, to process this that way. In contrast, if we click on headings over on the accessible version, then it outlines each one and it shows there's a heading one. All of the things that I suggested, yeah, should be heading twos are heading twos now. And so it gives us just a really quick visual indication, you know, of whether the heading structure is, is accurate and forms a proper outline. Another tool that was in the list was, the web developer toolbar. So if any of you are developers, you may already have this. It's a really handy tool just to have, gives you all sorts of information about your website. The, I like the, the heading feature. It has a similar feature to the accessibility book marklets. But if I click on outline, show element tag names and then click on headings. It presents the kind of the same information we just saw, but does so in a, in a slightly different way. And so, you know, may prefer one over the other. It also has, has a really nice feature for alt text. You can go to images and you can display alt attributes. And it then shows. Associated with each image. It shows what the alt text is for that. So we've got alt equals accessibility university up here. That's a great way to describe that logo. It's just short and sweet. It provides the access to the text that's in that image. You've got alt equals previous slide. Alt equals next slide. That's great for, for those. We've got a more detailed. Description of this photo here. Because that photo really requires a lot, you know, longer of a description, but not too long. You want to keep it fairly short. Because you don't want to burden users with having to hear. You know, super detailed description. Just provide, you know, as much as is necessary for them to get the gist of what this is communicating. And then there's a creative commons license down in the, in the footer. So really nice, nice feature. And there's so much more built into that, that tool that we won't go into. Now. One, one other tool. That I'll show, and then I'll hand off to Ann Marie. Is if you go into dev tools. In your browser, you've got all sorts of things. One thing that's built into Chrome is lighthouse. And you can check lighthouse will generate a report based on all sorts of variables. You can look at performance. You can look at performance. You can look at performance. You can look at all sorts of variables. You can look at performance and best practices and SEO. And you can, you know, check whether you want to look at it with mobile in mind or desktop. If we just check accessibility on desktop and we generate a report. Thanks for a moment. And then it creates a report. And in this case, we got a score of a hundred, which is awesome. But that's on the accessible version. We get a score of 77, which I think probably is a little bit generous. I don't know that I would give this, this page that high of a score. And that it really kind of speaks to, you know, Ann Marie's point earlier, that checkers can only check so much. And this is not going to check everything. Yeah. I mentioned, we know that there are 18 problems with this. This site and the lighthouse checker finds a few of those, but not certainly not 18 of them, but it does provide some, some useful information. So for each one of these, you know, it talks about the color contrast. And it actually shows where all the color contrast problems are. If we get down into this problem with internationalization, we don't have the light. We don't have the color contrast. If we get down into this problem with internationalization, we don't have the Lang, the language of the page identified on the HTML element. Labels, we actually haven't looked at that form over there, but I can see the form fields do not have labels. So screen reader user would have a difficult time. You know, they're going to access that form. They're not going to know that's the name field necessarily. They're going to have to do some detective work to figure that out. And they shouldn't have to do that. And they might, you know, not do it accurately. But in addition to showing a screenshot of the offending element, lighthouse shows the tag. And you can click on that and jump right to the source code to see where the problem is. So that's, you know, that's a very useful tool as well. Also in that slide of checkers, there's a tool called axe. That was identified. That too is a plugin that would work within the, the dev tools and provide some pretty sophisticated functionality. I've kind of lost track of what is free with axe anymore because they've gone, you know, to various tiers where you can get a lot more functionality if you actually subscribe instead of the free version. Anyway, another of my favorite tools is wave from web aim, but I'm going to leave that to Anna Marie to demo that. Okay, let's talk wave. Okay. So this should look familiar. Terrell was just using this website. So I already have the wave tool installed in my browser. I've got a little icon up here. So all I have to do is click it to activate it. And when I click that, I get a sidebar on the left side of my screen that has opens to a summary of some details about what's going on in the page. And on the actual page itself, I have several icons that are superimposed over the interface. So what are these icons for? Oh, let's, so let's talk about the stats real quick. We've got 21 errors, four contrast errors, nine alerts, and it shows us a few other things that are going on in the page too. So when I take a look at these icons, actually, for example, I'm going to click this one here. When I hover over it, it gives me a border around where the issue is. And then when I actually click it, I get this box and the box tells me it's missing a form label. A form control does not have a corresponding label. And I have two links in this box, one for reference and one for code. So I'm going to click the reference link. And it changes my right sidebar or my left sidebar. Instead of the summary being open, I can now open on the reference tab and it tells me why this is an issue and it even gives me information on how to fix it. So what happens? What happens when I click the code link? Well, I click the code link and at the bottom on my screen, a code window popped up and it takes me right to that line in the code where that issue lives. And when I look at this down here in the code, I see there is no proper label for this input. So it was giving me some good information there that it's missing a form label. And to dismiss the code window, if I just click on this icon, then it hides down to the bottom. Let's just look at another one here. So Terrell talked about this image. So if I click this icon for the image, it's telling me missing alternative text. When I click the reference, the reference tab is already open in the left side. So it's just going to change it to this particular error. And again, tells me why missing alternative text is an issue and how to fix that. And again, I can open up the code window by clicking the code link. It takes me right to where that image lives in the code. And I can see, yes, there is missing alternative text for this image. So again, that's good, good information it was giving me. So let's take a look at some details here in the sidebar. So as I scroll down, it's listing out all of the details of what it, what it detects on this page. And again, if I scroll through the actual interface, all of these icons are on the page. And sometimes that can be kind of cluttered depending on what you're doing. Maybe it's just too busy for you at the moment. And you just want to narrow down to some certain issues. It's easy to turn those off in this details panel. So I'm turning some of these off here entirely, but note that under each section, I can actually turn off just a part of a section too. So watch what happens when I click missing form label, then all of those icons for the missing form labels disappear. Or I can just get rid of those errors altogether. So what I've got left now, right, are four contrast errors that it's detecting on the page. And when I click on one of these icons in the details pane, it highlights it on the interface and it shows me the border around where this particular issue lives on the page. So now I'm going to go over to the actual contrast tab here. It's the last tab in the details area. And when I click that, it gives me a new set of tools for color on the, on the left top, I have the foreground color. It gives me the hex number for that color, a sample of the color. And I have a lightness slider underneath that. And then I have the same for the background color. I have a hex number, a sample of it, and a lightness bar. And then below that, I have some, the results of the color contrast test. And right now it's telling me that these colors fail. It's showing me what they look like in this sample, in the samples for both normal text and large text. So maybe you were wondering what those sliders are for. So watch what happens. I'm going to move this one and watch what happens in the, in the results. So as I start to move it, see I can make them pass the color contrast test by just changing it, just tweaking this a little bit. And when I do that, so now they're all passing, I've moved it far enough that they all pass. And note in the interface here, it changed the color so that I can see what that actually looks like in the interface. And when I look at that, I'm like, wow, isn't that so much easier to read? So not just somebody with low vision, but just everyone is going to find that easier to read who is a visual person. So that's, I'm going to refresh my page now and show you the color contrast analyzer. So this is a nifty little tool. It's actually a standalone EXE. And the beautiful thing about that means you can also use this to test your print documents before you print them to make sure that they have good contrast. So, and also because I need some larger targets to hit, I'm going to go ahead and bump up the size of my page by using control plus until I've got some nice big targets here. Okay, so in the color contrast analyzer interface, the top of it shows me the foreground color. And when you open it, it's just going to default to black and white. So it defaults to black text on a white background. And then the background shows below that. And then below those two samples, it shows me a sample of what those colors look like together. And yet again below that I've got WCAG 2.1 results. So the black, black text on white background passes all of the tests for the color contrast. Okay, so now I want to actually look at this page. I know that these tabs have poor contrast already because a couple of checkers have already told me that. So the beautiful thing here is there are these little droppers. So you don't have to know the hex number or anything to input it. And when I click a dropper, it grabs a hold of it. And then I just drag it across my page. And so I want to select the foreground color right now. And when I do that, the foreground color changes in the color contrast analyzer. And it gives me that hex number. I'm going to do the same for the background. Okay. And then it gives me the background color. And it shows me that example of what they look like together. Not that I didn't know from the webpage, but that way you know it's got the right colors. But, but it's telling me still, these are all failing. So it's another, it's another great tool to use to back up what other tools are saying, or even as a first pass. I'm not going to demo these today, but just to point out, it does have some functionality to help you find a more accessible color combination too. And the thing about this one, it even gets more granular because I can, I can just change individual color channels or I can click this box to sync them all to move them all. So that's color contrast. I guess it's a good time to open it up for questions. So we'd love to hear what you've got. Just point out also, Annemarie, that all of the tools we have demonstrated are free. Yes. Yes, they're all free. We like free. So you could put your questions in the chat, or if someone feels comfortable enough to maybe unmute themselves to ask a question, that would be totally fine too. Are all those tools listed on the accessibility tools page? Yes, they are. And there are many more as well. That's our annotated list of kind of our favorite tools among our staff. And so do check that out. Have you evaluated the arcs toolkit? And if so, what did you think of it? I have not tried that one. Carol, have you? I have not either. I think I'm going to write that down so I can take a look at it. It's from, I believe the arc toolkit from TPGI. Oh, formerly the posh yellow group, but I haven't looked at that. It might be worth pointing out that a good start is making sure you validate your HTML. Yep, that is a good point. Sorry, it moved on me. And to a lesser extent, the CSS, the W3C HTML. I lost my, can you still hear me? I lost my audio. Yep, we can still hear you. And you might not be able to hear us. I will say that the tools and resources page that we keep linking to includes HTML, links to HTML validation tools as well. That is definitely an important part of the equation. And alt text is one example that alt attribute is a required attribute within HTML. And so if you skip that, then the validator will tell you. But even more importantly, as you get into using ARIA and do things that are more complex, ARIA is pretty challenging sometimes to implement. But errors in ARIA usage will show up in the HTML validator. So that's a really great way to detect those errors so that you can use ARIA appropriately. You have accessibility guidelines, tools for social media also, Facebook, Instagram, et cetera. We don't have guidelines per se, but we have a single resources page where if you go to our website, www.edu slash accessibility and then add slash social to the end of that. That links to the various social media platforms, accessibility pages. Those that have anything are linked there. But that's kind of a, it's a moving target. They've changed frequently and what they support today, they may not support tomorrow. Hopefully it continues to improve instead of the other way around. But we've chosen not to provide our own documentation on that because it does change so frequently. But that is one single page where you can jump out to the documentation that they all provide about their accessibility of their platforms. And we have a link in the chat to that page. Thank you. So one other link that I will paste in is a link to our events page. We offer a number of events. One that comes to mind in particular if you're interested in web accessibility is our once a month web accessibility meetup where it's an informal opportunity just to talk. We tend to do maybe a little bit of a deeper dive in web accessibility. But we are open to looking at sites that people are working on. If you want to review of your site, you have particular challenging features that you're struggling with, how do I make this accessible? Then bring those to that meetup. And it's a great opportunity for people who are responsible for websites to support each other. We're all trying to make a more accessible web presence. It's a nice safe environment to show your stuff for the first time. Okay. Well, it looks like we are out of time. But glad you all can make it. Again, take advantage of some of the other events that we offer. Feel free to reach out if you have questions. Or have any needs related to web accessibility. You can send an e-mail to help at uw.edu. And just mention web accessibility. Or be detailed in your question or your request. And that will come to us and we'll get back to you. Thanks for joining us, everyone.