 Hi everyone. Welcome to accessible web content creation. This is the second in our accessible technology webinar series. Cheryl Bergstahl kicked us off last month with universal design talk. And today we want to explore kind of the basics of web accessibility. We do a lot of activities and events throughout every month where we do more of a deep dive into web accessibility and you know look at some of your projects and applications and websites under development and you know look at some of the more challenging aspects and how do you make these challenging features accessible. But sometimes it's helpful just to sort of get back to basics and talk about, you know, the foundation of web accessibility. What exactly do we mean when we talk about web accessibility. So that's our intention here with this presentation is to get back to basics. So I'm going to offer a little bit in the way of a PowerPoint kind of overview. And then I'm going to hand it off to my colleague Anna Marie Golden, who will do part two. I am Terrell Thompson, I'm manager of the it accessibility team. So we are a part of accessible technology services, which is an apartment within UW it. And we promote technology accessibility throughout the entire university so we're here to help with all sorts of things related to it accessibility, including web websites, digital documents videos software. And if it has a user interface, then it, it has accessibility and locations, and we are here to help ensure that those user interfaces are something that everybody can use. So, focusing today on website accessibility, we of course need to ask what exactly is that what do we mean when we say accessible websites. So if you think about how people access computers or how people access information digital information, then it, it tends to be sort of an input output model, where you've got some means of providing input into the computer might be a keyboard might be a mouse might be some other and then receiving output there's some means of receiving output from the computer which traditionally has been a monitor. So, this is a very traditional sort of model keyboard and monitor and then mouse came actually a little bit later than the keyboard, but you know those three working combination to provide users with access. There's been the historic model but it, it's getting to be a little bit old school. Nowadays we have people accessing content and a lot of different devices the on the slide here we have a variety of cell phones. This is an older slide so these are a little bit older models but but the variety still exists. You got a lot of different shapes and sizes and platforms. And the choice of platform is going to influence how a person perceives the content. And it's going to be very different than what sort of an old school person has traditionally received using a keyboard mouse and a monitor. And then you've got tablets as well again a wide variety of shapes and sizes and platforms. You got some people who aren't accessing content visually but they're doing so audibly. So when we talk about disabilities and accessibility we typically talk about somebody who's using a screen reader. Somebody somebody who's blind somebody's low vision somebody who has dyslexia and they're using a tool to read content audibly while they look at it so you get that multi sensory input, but a lot of people access content audibly, rather than just visually. And that actually is expanding all the time because people are using hands free interfaces on a lot of these devices and so listening content becomes a way to consume content, not just accessing it visually. Also for input we have different modalities where rather than using a keyboard or mouse maybe somebody's using speech input. A lot more people are doing that these days again because of our hands free environment and because you know different devices now support speech input. Traditionally that's been the domain of people with disabilities, somebody who for example can't use a keyboard or mouse due to physical limitations, or more commonly is somebody with carpal tunnel syndrome or repetitive stress stress injuries. So using speech input for everything, being able to operate the device, you know, click links, click buttons move sliders do all those sorts of things with speech input becomes important. We also have people who operate by touch. So here on the screen is a refreshable Braille device. So this particular model allows somebody to do use the Braille buttons as kind of an alternative keyboard for input, but also there's a row of dots that refreshes as the person explores the content, and therefore they're able to read the content of websites and other computer information using Braille. And so I ran out of slide space of the ways I could go on and on and on about different ways that people access technology and access the web and the bottom line is it's a very diverse landscape. There are so many different ways, different configurations different tools different devices different platforms that what you see on your computer is not the same thing that somebody else sees you can almost guarantee that. So even if somebody is old school and accessing content visually through a monitor. They have a lot of options. This is on my MacBook pro I've got resolutions from 640 by 480 to 1680 by 1050 and all points in between stretched and not stretched. And within my browser I've got font sizes from nine to 72 16 as default, but a lot of people will mostly beef that up. I don't know how many people go down in size, but maybe some people who do that. A lot of people will set their browsers font size to a larger size, just because they they need that as we get you know we have aging eyes and we need to see things a little bit bigger. A lot of flexibility and again, depending on what settings we use, it's going to be very different experience for us accessing your website. So I wanted to introduce you just to a few individuals these are all students that we've worked with over the years. And the reason I do this because it's easy to sort of as we're talking about web accessibility to talk about standards and kind of the technical issues of how you code for accessibility and so forth. But it's important to keep in mind that what we're really talking about our people that you know this is a human interface issue that you know we want. We want humans, we want students, we want employees, we want visitors to be able to access our content, otherwise we wouldn't create the content. And so it's important that we understand that there's diversity within our audience. And so this is Jennifer she last time I knew was a she had been a public relations major, and she ended up going to work for a nonprofit group that responds to unmet needs of local adults with disabilities. But she has mobility impairment and so she's not able to to use a mouse it's one one big issue in terms of her interface is that she just physically cannot manipulate a mouse. But she can use a keyboard. What she has here is an Intelli Keys keyboard which has larger targets than a traditional keyboard, and she's using a stick that she's holding in her right hand, and is able has enough dexterity to hit the keys on this larger keyboard with that stick and so her communication through websites and so forth is through a keyboard interface using the tab key to move from focusable element to focusable element and other keys that that makes sense. This is Courtney, she has a bachelor's degree in communications from the UW. And she she works for rooted in rights, which is a program that creates media centered around disability rights. She's a very active blogger and was kind of out there in terms of her presence online and so forth. She she uses a screen reader, and she gets her output, both audibly listening to content, as well as through a braille device and so what you see here is her using her braille device. And she's got, she's got headphones in to so she might be listening as well. But a lot of times, people who are blind will switch back and forth. If they know Braille, maybe they'll use Braille in addition to to listening to content. If they're deaf blind will just be using Braille exclusively. But again you've got a lot of variety. Here's Courtney again, this time shown with Conrad, who earned a law degree from the UW, and he has done extensive work with that law degree he interned in Washington DC three different times with different organizations. He received numerous awards for his scholarship and civic engagement. He is now a leading disability rights attorney in Seattle and as a member of the Washington State Governors Committee on disability issues and employment. And he, he's not able to to use keyboard and mouse. And so he uses other other means of controlling the computer and accessing information, among other things he does use dragon naturally speaking so he's one of those speech input users. And there's a lot of other things too, just using using switches and various things to, to, you know, to find his way around on websites and to access content. And here's Hannah, she has low vision and so she she's leaning into her, her laptop here but she also has zoom text running which enlarges everything on the screen makes everything a little bit bigger she's looking at some program code there. She's a computer science major and a physics and math minor, tons of awards that she received while she was at the UW. She interned at Facebook and software development when she was at the UW and now works for Facebook. So, I introduce all these students, just because they are so diverse in the technologies that they're using, they all have done a really outstanding job in their academic careers, but they did so through a very different interface than a traditional interface. So this is really what web accessibility is about is making sure that everybody, including regardless of where they fall sort of on this continuum of ability to see or hear or walk or read print and so forth. The web needs to be accessible to everyone. And if you look at this continuum. It's not really a binary thing it's not you know people with disabilities people without disabilities, it is depending on what you're measuring exactly. Some people are very high on their ability to do that thing. Some people are very low on on their ability. And so, you know, for example, to be able to see some people at 2020 vision. People have no eyesight, but most of us fall somewhere in between. And if we were to sort of plot all of these variables on this continuum, you get dots all over the place so we just as humans are very diverse and so that is what web accessibility is all about. It is creating a website that works for all users. And it also is about creating a website that complies with accessibility standards and so let's do talk just briefly about standards because that is an important piece. And talking about all these different users and all the different devices and configurations they have that might seem kind of overwhelming to think, oh my gosh how am I going to, you know, how am I going to test with all this, you know, these possibilities. And you know how can I possibly understand all the hundreds of ways that people can access the web. And to do that fortunately, you just have to know web accessibility standards and the assistive technologies that people are using and their web browsers and operating systems all also support those standards and so that's where communication happens is at the standard level. So standards are the glue that kind of, you know, binds all these things together and makes communication happen. So the source of standards is the World Wide Web Consortium or W3C. That's the same group that owns the HTML specification and cascading style sheets, CSS, and lots of other, you know, specifications and standards related to the web. So they also very early on in the infancy of the web in the early 90s began working on the web content accessibility guidelines, because they wanted to be sure that this vision for the web of being, you know, information at your fingertips for the entire world was centralized and that the web did not create barriers. It made information more accessible for everyone. And so the W3C was aware of this early on with the potential for barriers and so they created the web content accessibility guidelines, otherwise known as WCAG. We'll talk more about that. But also they have more recently created a specification called ARIA, which we talk about quite a bit in web web accessibility discussions, particularly when we get into deeper dives. Accessible rich internet applications or ARIA is a way of adding code to HTML that helps it to communicate, you know, dynamic rich interactive applications that happen on the web, communicate those effectively to assistive technologies. So at this point probably, you know, as in a basic class it's important just to know that ARIA exists and that it does serve that purpose of making dynamic web pages more accessible. But that's a topic probably for another day. In terms of WCAG though, the current version is version 2.1. And that's broken into four broad concepts. Web content in order to be accessible needs to be perceivable, operable, understandable and robust. I could go into detail about what each of those means, but we'll save that for another time as well. There is an image here on the slide of coffee being poured into a mug, which in the keyword there is poor. You can remember these with that acronym, poor, P-O-U-R, perceivable, operable, understandable and robust. But what does that actually mean? Well, as you drill into each of those four concepts, you get to ultimately the lowest level within WCAG or what are called success criteria, which are sort of like checkpoints. These are the specific things you need to do in order to make web content accessible. And there are 78 of them in WCAG 2.1. And each one is identified with a level, either A2A or 3A, that is kind of a balance between priority, how critical is this issue, and difficulty, how reasonable is it for most web designers and developers to be able to do this. And so early on when WCAG was first, WCAG 2, 2.0, was first published, there were questions about, well, how accessible is accessible enough, because 78 success criteria is a lot. And some of them are really difficult. But those all sort of fall under level 3A. And so the ones that are believed to be attainable, and that are pretty critical, all fall under either level A or level 2A. And so that has kind of emerged, very clearly emerged actually through legal action and through policies that have emerged in the past to legal action and so forth. It has become clear that the expectation is that we'd be able to meet WCAG 2.1 level 2A. So again, what does that mean exactly? Well, that's what we're going to cover in part two of this presentation. And the Washington State Policy 188, this is state policy that requires all state agencies to have accessible information technology, and we're covered under that at the University of Washington. So it does specifically state that it includes higher education institutions. And the minimum accessibility standard that's specified by that policy is WCAG 2.1 level 2A. So just like everybody else, we are needing to meet that level of accessibility with our websites. So I want to wrap up just with how to learn more and then I'm going to hand it off to Anna Marie to cover some details. But our website, UW accessible technology, this is at uw.edu slash accessibility. This is where we cover a lot of information about web accessibility and document accessibility and video accessibility and so on and so forth, a lot of information there on our website. So I encourage you to check that out. And also events, we have a number of events, some on a monthly basis like our web accessibility and usability meetup. We do that once a month on the second Thursday of every month. We have office hours on the first Thursday of every month. And often in a given month we'll have some special events, trainings and workshops and other events related to accessibility. So I encourage you to check out our events page at uw.edu slash accessibility slash events. Otherwise, just stick around because like I say Anna Marie has all the details. So I've been talking kind of in the abstract about what all this means, but she's going to talk about what it means at a detailed level as you're actually producing web content. So I'll stop sharing here and hand it off to you, Annemarie. It doesn't appear that I have the ability to share it. Hi, I'm Anna Marie Golden. I'm also an IT accessibility specialist with the IT accessibility team with accessible technology services a part of UW IT. This webinar will cover heading structure images, links, lists, color, tables and forms. So to start off, an accessible web is a semantic web. Many people with disabilities use assistive technologies to access the web and these assistive technologies rely on a web pages markup in order to relay that content to users. So they're reading the HTML code, not the screen. So even though one of the assistive technologies is called a screen reader, it's actually reading that underlying code. And that's why it's so important to use HTML elements semantically. In other words, use the correct element for the job and not solely for its appearance. That's because each element has its own set of properties, behaviors and interaction model and assistive technologies are confused when elements are used for their appearance and not for their purpose. One way we can do that is with an accessible heading structure. With a heading structure, visual headings should be marked up as HTML headings. They should be in order without skipping levels and we have levels h1 through h6 to work with only one h1 heading per web page. Again, not used for its visual appearance, but for its meaning. Because this outlines the content of your page much like you know if you're doing a research paper, and you start with your outline and then fill in the content your headings are going to do that same thing for your web page. And search engines really beneficially use an index content and structure of web pages so if you're using a heading structure in a correct manner, it could increase your search engine results. On the right side of my slide here, I have an image of what that should look like. So with the first heading one with only one heading. That's your page title and main content. And then heading to is under that for major section headings and then h3 headings under that which would be subsections of heading to and so on in the heading structure. So I have an animation to show how that's done in the WordPress environment we use a lot of WordPress here and the at the University of Washington. So first I need to add some text. And then once I do that, I'm going to click this toolbar toggle, because that gives me some more options in my toolbar. And then I'm going to select the text that I want for my heading so in this case, I want that be a heading to. Underneath those the heading to will be heading three so I'm going to mark all of those appropriately on this page. And then when that's done. I can show you what that code would look like behind that. So it starts with my h2 here we have h3 some text h3 and so on. Any questions about heading structure. I have a question. I noticed in WordPress and canvas and other places there's no option to put in a heading one. And so the headings always start with heading to how do I use headings properly and creating content using a tool like that. Oh, thank you for that question very important I didn't cover that here. So now in my code here it starts with the h2. So the where is that h1, the h1 is actually going to be the title of the page so when you enter the title of the page in WordPress, it's going to use that as your h1 heading. So it doesn't show here but if I were to view this web page in my browser, I would have a heading one above this. Great thank you. Okay. So let's talk about accessible images. It's really important to use alt text for all images that can be meaning. Now alt text looks like this alt equals and then in quotes a brief textual equivalent of the images purpose. It's not necessary in this alt text to say photo of unless that is the context because the assistive technologies will announce to users that it is a graphic. And it's really important to limit your alt text to 140 characters or less. And there's a couple reasons for this. One of them has to do with the way assistive technologies chunk up that data to relay that alt text to users. So, another aspect is with assistive technologies and text users usually have the ability to traverse through that text, either word by word or character by character so they can review through to get to more clearly understand it with alt text they're they don't have the ability to do that so you want to keep it short so that they can remember what you're talking about as you're doing it. And then assistive technologies relay this alt text to users, and it's really important to emit information that's not available to all users. So if I put something in alt text, then it's going to be available to assistive technology users, but as a visual user when I go to that page, I may not have access to that information. However, I will note that if an image fails to load for some reason I will get that text. And sometimes we have decorative images just to make our pages look prettier to fill space they don't really add to our content of the page. So in those cases, use no alt text, and that's basically just alt equals quote quote, and use these for decorative images only purely decorative that do not convey meaning, because this allows assistive technology to ignore that image. On this slide, I'm the right, or excuse me the left side, I have a picture of strawberries. And on the right side, I have my interface in the, in the WordPress environment, and I'm going to add this image of strawberries to my web page. First, I'm going to click this add media button, and it brings up an interface. And in that interface, I have a text box for alt text. So I'm just going to put my alt text in this text box, and for this image it's strawberries. And in the code at the bottom of the page I have the image markup there that shows what this would look like in your editor. Any questions about images. I have a question. When talking with instructional designers, they are usually challenged to provide meaningful. That's for the graphics that they are receiving from the professors who is building the course, or building the content. I'm usually suggesting that the person who needs to provide the alt text is the person who is altering the content was wondering, can you elaborate a little bit on that know who is the right person to come up with this alt text. If you hit it right on the nail head, hottie, I, I, I, in my experience, I go back to the person and ask for the alt text also if I'm creating something like this, because I need to make sure I understand what the purpose of that image is and that I, because my, my inclination maybe just to describe the image but maybe that's not the purpose that they're trying to get across by using that image. Does that make sense. Oh, yes. In other words, you are also suggesting that, you know, in the professional field, if you are not familiar with the purpose of an image, we need to get back to the author and then ask him or her to provide the the, you know, the proper alt text. Correct. Yes, yes. I think just just to build on that this image of strawberries that we've been looking at may in fact strawberries may be good alt text in some contexts, but if this is a biology class, and there's something very specific about these images that this image is trying to convey, then strawberries is not going to be good alt text and so only the professor who knows what this image is intending to convey would be able to add alt text properly to this image. So I think this is a, you know, that's a really good example of what you guys are talking about. Great. Thanks for adding that. I have a question to add on to that. What if I'm given information about the photo and then I've been asked to make sure that I have the right alt text, and I have been given like a work of art or performance photo, and they've told me about the artist or the photographer or they've identified the performers in the photo. So would I put that in the alt text. I remember you saying something about assistive technology users will be the alt text but other users won't. Correct. So, it's really important not to include anything in the alt text that wouldn't be available to other users, for example, a visual user who goes to this page may not access that alt text because they don't need to use it. So it's really important to make sure that the information you provide an alt text is information that's available to all users by viewing that image. Does that make sense. Thank you. Okay. Next we have accessible links. The only thing we notice about link text, or about a link is its link text. So, it's important to use really meaningful link text because this provides context to users. It's really important that the link text makes sense out of context, with no click here or read more link text. The reason that's important is assistive technology users have this whole other way of navigating a web page to help them quickly find things on the web page. So through a keyboard shortcut, for example, a screen reader user can bring up a list of just the links on the page. So when they bring up a list of links on the page and it's populated with phrases like click here and read more. They have no idea what those links are for unless they follow them and go there and how many times have you followed a link and what, oh wait, that's not what I'm looking for. So then they have to go back where they started from again. So, make sure that link text gives users an idea of what to expect when they click that link. Omit the use of target attributes in most cases. So that's the target equals underscore blank attribute. The reason I say don't use this in most cases is because it removes control over the interface users are interacting with. And sometimes it can turn into a bad user experience for users who may not know that a new tab has opened. And so what happens when you hit the back button when you go to a new tab. Something happens right because your history doesn't follow you. So it may make it more difficult for them to get back where they started from. So for most applications I say let the user decide where links will open. And I say most there are a few exceptions. In the big example I like to use is for example if you're doing online shopping with eBay. And to complete that purchase you have to pay for it. And so if you're paying through PayPal, it'll open up the PayPal window, but you don't want the eBay window to close because you're still working on that transaction. And so once you enter the stuff in PayPal, it sends you back to eBay to complete that transaction. So in that case, it's a good use of a target attribute for. But for most things I would say let the user decide if the purpose of using this target attribute is to keep users on your website. That may not be a good enough reason in itself. And underline links. I know this is the latest fad to make links a different color, but users ever since the beginning of the web under links were underlined and users know when you see underline text on a website that it's clickable. Links should look like links not buttons so this is not just differences in semantics also behavior links navigate to content which is activated with an enter key buttons perform actions and they're activated with a space key. And often there's a mix match when communicating with the system technology users and an example that I always think about when I'm when I'm talking about this is one of my colleagues who is totally blind talked about a scenario where he was on tech support, and they were telling him to click this or look for this button on the page and he's like I don't see a button on the page, because it was a link that was styled to look like a button. When you're using link images, your alt text should relay with the links purposes and not necessarily describe what's in the image. And with document links it's important to alert users that a document will open. This can be done several different ways but the most common ways are using icon with alt text so if I have a PDF document maybe I use a PDF icon that says PDF document, or make it part of the link text you know it can say opens PDF document. Those are not the only ways you can do it but just two of the most common easy ways to do it. So I have another animation here that shows how to create accessible links in the WordPress environment. And there's this nice little link button that I clicked in the toolbar menu, and it gives me this interface. I have two textboxes one for the URL and one for the link text. So let's do a link to the Google homepage. I have Google.com is my URL and my link text I'm just going to say Google it. And then click the add link button, and that adds the link to my page now note that this link is not underlined and you're going wait you just said we should underline our links. So this is in my interface for the editor, it doesn't show but if this were rendered on the actual webpage, this link would have an underline on it. So this is what that link looks like in the browser using the a. Do we have any questions about wings. I do. We see that a lot of developers there, they use links versus button button versus you use them interchangeably. So that would be a little bit about the cementing behind these two type of elements. Yeah, let me go back a couple of spite or back a slide here. Can I interrupt Annemarie? Yes. I've got actually have for another meeting after the webinar here I've got an accordion pulled up, which is a really common widget or feature that appears on a lot of UW websites. And it, I think it illustrates this issue really well buttons versus links that it it is basically there's an item that you click on. It's used a lot for like frequently asked questions so you got the question, and the answer is collapsed so it's not shown by default. And the user clicks on the question, and then the answer appears beneath the question. So you got like a whole, you know, stack of questions, and you can just go through and click on those. And so. So that's, that's a case where in this particular case this this accordion is coded as links. And so each one of the questions is a link. And you click on it, and you would the user will expect that they're going to go to a new page, because that's what links do. And a screen reader is going to say link, you know, before it announces the link text. And so the screen readers led to believe that okay if I click on this I'm going to find the answer on a new page. And so it's prepared to happen. And instead, it just shows content on the current page. So showing content on the current page is actually a button function, because buttons change, you know, content on the current page or they perform some function. That's the main distinction between a link and a button. It's important to them, in addition to the visual differences you pointed out here. It's important to code them properly based on their function, so that a screen reader user understands, you know, and has certain expectations about what's going to happen if I click on this thing. So, so I thought, you know, since that just happens to be up on my browser, I would share that. Thank you that's a very good example. Okay. So next up we have lists. It's important to make sure lists are marked up as HTML lists. We don't want just paragraphs preceded by a dash dot icon, etc. Because this provides context, assistive technologies when they hit a list they will announce that it's a list. We don't want to provide the number of items in the list. And then if users don't want to hear the whole list, they can skip over the rest of it if they wish. In HTML, there are three types of lists, ordered lists that you numbered, unordered lists, those are bulleted lists and definition lists we won't talk about those today but those are basically used for glossary type definition, type of things. So ordered lists, use an ordered list, which is a number when the item order matters. So on the left side of my screen here, I have list markup with the ol tag for the ordered list and I have my list items in between those ordered list tags. And on the right side of my screen. This is what how the browser would render this code. So I have two items cat and dog, and I have one in two in front of the items and of course cat is number one. So in the WordPress environment. I'm going to enter my text here for my list. I select the text, and then I click this numbered list button in the toolbar, and it turns my list into a numbered list with each item preceded by a number in order. And that's what it looks like in my editor for the markup, just like I had just showed on the previous slide with the ol tag. So I'm going to use an unordered list, use an unordered list, fulleted list, when the item order does not matter. So on the left side of my screen, I have the markup for an unordered list. I know the only real difference here is that my ol tag changes to a ul tag for an unordered list. And the items live in between those tags. So on the right side of my screen. This shows how it's rendered in the browser. I have cat and dog and each item has a bullet in front of it instead of a number as in the last example. So in my, it's going to be very similar, how to create an unordered list in the WordPress environment. I enter my text, I select it, but this time I click the bulleted list button, and then that gives me my bulleted list I have cat and dog each preceded by a bullet. And then in my editor, it shows here the ul tag instead of the ol tag. Next up, we have color. Color includes two areas, meaning and contrast. So when we talk about meaning, it's important to avoid conveying meaning through color alone, because we may not perceive color in the same way that others do so. Not that it's wrong to provide meaning with color, but if you do, you should provide a backup so that that could be understood by all types of users and some ways to do that is links can be underlined remember we just talked about that. Paracel lentils can be numeric. So on the right side of my screen here at the top I have two examples of a sentence with a link in it. And the top one note that my link here is just a different color. But if I have a visual impairment, I may not be able to see the difference between these colors to know that it's a link. And the second example, my link is underlined so it's clear that that is a link when it's in the middle of my text. The next example here I have a set of carousel lentils and the first one, I have just a set of dots and the only way I can tell which slide is in view is because that one is the one that's a different color. And if I can't perceive color the way that most folks do, I may not be able to see the difference between this yellow dot and this white dot, especially since yellow and white are so close together. But in the second one, I still use color to show the difference, but it's not the only way that I show that note how my border around this one is a different shape so it stands out from the other two. And I really like this other example. However, it does show really poor contrast around the item that is selected. If this had better contrast, this would be a really good example. Now, I know which one is in view because it has a circle around it and in this case unfortunately the circle is filled in so it's hard to see the two, but in contextually you can tell because you can see the one and the three that are on either side of it, rather clearly. So just some examples there and how you can use backups for color means. Another thing is contrast contrast has to do with having an adequate contrast between foreground color and the background color. Again, because some visual users cannot consume contract content with poor contrast. So I have two examples on the right here. In the top one I have a set of tabs, like navigation tabs from the page. And the text on them is really washed out and so it's really hard to see so if I had low vision I may not be able to consume this I may not be able to read that text at all. However, on the bottom example, I have those same tabs again, but in this example, the text is bolded and it's black and it really stands out from the background so it's a lot easier to read than in the first example. So they figure out what the color contrast is. So there is a formula, but seriously there is an easier way. There are many free color checkers out there that you can use. And I'm going to show you two of them today. One of them is the color contrast analyzer by the Pichello group. And the other one is the color contrast checker by web pain. Next up we have the color contrast analyzer from Pichello group. And the really cool thing about this one is it has eye droppers that allow you to grab any color from anywhere on your screen so that you can easily test them. So, if I select this eye dropper and move it over and select the foreground color. It will populate the color text box with the hex number and I do the same with the background and note how the interface told me immediately the result that that this color combination passes this black with white passes easily. But what is it what if it doesn't pass so I know this other color combination has really poor contrast so let's see what that looks like. And I select the foreground color and it immediately tells me that this color combination fails. Now I'm using the same background color so I don't really need to test the background in this case. Again, the next one is the color contrast checker. Now this one. Oh, let me let me just say something about the previous one real quick. This one is downloadable, and it creates a little exe file so this is actually really helpful you could use on print documents to check the contrast as well. The color contrast checker that we're going to look at now is a web based tool by web aim. And so there's a web page that you need to go to use this one. And the special feature of this one is it has these little scrubbers here for each color that allow me to choose a color combination that passes the color contrast test. So, I put a color in here and I know this one fails. It tells me right away it shows me that it fails for both normal and large text. And I move this scrubber, and I keep moving it and notice these balloons start popping up and tell me that this color combination finally passes the color contrast test. So it's just a matter of moving either the background or foreground scrubbers until you find a contrast ratio that passes. Do we have any questions about color contracts. Yeah, I have a question for you, Annemarie. Yes. When using color contrast checkers, I noticed that they all provide separate pass fail ratings for regular text versus large text. How do I know whether my text is large. Oh, good question. So large text is generally defined as 18 point text or 14 point text if it's bolded. And this is in the WCAG guidelines. Great. Thank you. This is in this is in the WCAG guidelines that Terrell talked about earlier. Great. Next up we have tables. So it's really important with tables that you're using them for tabular data and not for formatting. So think about the way a table is read. You read a table from left to right. So that makes sense when you're reading tabular data, but if, if you're laying out a web page or formatting this content may not make sense when read from left to right so my cell in this way. It's really important to use table heading so when I'm creating my table headings and HTML I'm going to use the T head element instead of the T body. And I want to enclose each one in a TH element instead of the TD element. And I also want to use scope. The scope attribute relates table headings to their corresponding table cells. So if I'm if I have column headings I'm going to use scope equals call. If I have row headings, I'm going to use scope equals grow, and I have some examples on what that looks like here on the next slide. So, on the left side of my screen, I have a table markup example. So note here that my table headings are using this T head element, and each heading itself is enclosed in a TH element. So note here that because I have column headings that I've used the call scope attribute to note. So, on the right side here, have how that table looks so it's just this two column table. I want you to know that I added a little CSS to this table but it's not going to just render like this automatically from that HTML, but I added a little CSS to it so it would make it a little bit easier to see on the slide. So, I often get asked how a screen reader would read this table. So let's check it out. So note how, as it went through and read the table, it read the table headings along with that cell data. So users understand how this content is related if they can't see it. We have any questions about tables. Have a quick question. I know you're not supposed to use tables for layout, but what if there's no other way to get the content positioned side by side like you're using a rich text editor and a content management system. Is it okay then. It's not. I, I, as I said, it's going to affect the way that content is related to users and it may not make sense when it's read in that order. Okay, thank you. So I would keep digging and into your CSS to find a better solution for that. You kind of just stole my, my advice, Annemarie, but I was just going to say don't, don't, your tables are kind of the easy button. So, you know, people sort of feel like, well, I know how to do this at the table, but there's always a better way and probably there's a way within the content management system. So, but yeah, you just need to look around or ask around, you know, somebody that knows that that system well would be able to help you figure out how to position things side by side because there probably is a way. Hey, thank you. Okay, let's talk about forms. It's important to use explicit labels for form inputs. This is using the matching for an ID values in the label and input so I've got an image here that shows a label markup. An input markup with this label. And no in my label my for attribute equals name. And in my input the ID also equals name. When this for an ID attribute are equal to the same thing. It relates that label to that input so when an assistive technology user lands in this input, they're going to know what what's expected in that input because it's going to read the label to them. It's important to include any kind of special instructions in label elements to because when assistive technologies a screen reader for example, hits a form. It's only going to read form elements to users. So if you have instructions dispersed throughout a form that's using paragraph elements. The users likely not going to get those instructions. So if you include that those instructions in the label elements, they will certainly get it. I strongly suggest using field set and legend elements to group elements such as radio buttons and checkboxes, and also when a description is necessary so on this next slide here I have an example of that. At the top here, I've used my field set and legend example in this markup. So note how my whole thing is wrapped in the field set. That's going to give me this box around my input. And my legend says, is it your birthday. So note here in the bottom example says is it your birthday that acts as a label for this input. Does anyone have questions about forms. Yeah, I do. I'm curious about the various tools that are that are in use there's so many different ways to make forms other than you know sort of a standard web based form and Microsoft has things Google has has forms survey monkey is a real common tool. How, how good are the forms produced by those sort of outside tools. Can you answer that one, Annemarie? They all do things a little bit differently and Terrell has actually done some work on this so I think he'd be great to answer this one. Yeah we actually are in in the process are our team IT accessibility team is in the process of doing a comparison. We've done this in the past but it's kind of old information and so we're looking at actually some of the same tools that you just mentioned. There's most very monkey called tricks catalyst Microsoft forms Google forms might be a couple others thrown in there too but looking at how, how well how accessible their output is and so. So stay tuned actually that we'll have some up to date information and we'll publish that somewhere on the accessible technology website, and probably there will be a blog post on the accessible technology website about that so really good timing that question because it is something that we're actively working on right now, but the, just to give you some kind of answer, they all create kind of accessible forms, but none of them are perfect they all have some issues. And we're hoping to sort of figure out, you know, just sort of catalog, you know what exactly are those issues and maybe in the end come up with a, well this one kind of is better than the others or these two are better than the others or something that will make educated decisions. Thanks public for that. So do I. Okay, so that that's the end of the content I have for you. I would like to let you know our next webinar is about video accessibility so look for that coming up. March 25 at 3pm. Awesome. Well thanks and Marie and thanks everybody for being here today. This was, this is really great and you know even though it's a basic web accessibility I feel like even you know I picked up a few few things that I had forgotten about or you know kind of needed a pressure on so awesome. So yeah, hope to catch many of you at the next webinar in the series.