ANNA MARIE GOLDEN: And Terrill, would you like to take it away? TERRILL THOMPSON: Yeah, sure. Thanks, Anna Marie. 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, a 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, Anna Marie. One more click. ANNA MARIE GOLDEN: Yeah, it's not working at the moment. TERRILL THOMPSON: Uh-oh.
OK. And I'll have to get used to not driving. And I'll try not to be a backseat driver. ANNA MARIE GOLDEN: Go ahead. TERRILL THOMPSON: I'm tempted. I'm trying to click here myself and it's not working, because it's not my slide deck.
But anyways, we talk about accessibility. We're talking about accessibility of websites and digital information, information on the internet. And 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 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 pre-pandemic, when students were all walking around on campus, they were all 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, in different shapes and sizes and platforms.
If you click a couple of times, Anna Marie. And we've 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-- in 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. And we're getting closer to that hands-free, conversational interface, where you talk to our devices, they talk back to us, and we exchange information that way. Now, we 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 through braille as well.
And 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 got a few examples, just to 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, so I 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, 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 will use assistive technologies instead. The next slide shows Courtney, who 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. And a lot of blind individuals will use either audio, listening to a screen reader through 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 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. 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 if things are happening elsewhere on the screen, then 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 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 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, that 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 sight, the ability to see, then some people have 20/20 vision, and some people are not able to see at 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 with disabilities, without, it's, 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 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.
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. They sometimes fall short. But generally, they're pretty good. And so our piece of the puzzle is, we need to make sure our websites 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 soon after the web became a thing, he created this organization to oversee the web and HTML and all the other standards that made the Web possible. So HTML is a W3C specification. Cascading style sheets, or CSS, is the 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 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 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 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.
So it really is a small handful of those that are applicable. But each one has a level assigned to it, level A, level AA, or a level AAA. And that corresponds both with the priority level and the difficulty.
So it was 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 AA is 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 then, level AAA 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? Did 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 AA 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, the WCAG version 2.1 level AA is the standard that we are trying to meet as state agencies.
Higher education is included within that. Next slide. So just to bring this 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. These are all level A, except the last one is a AA.
The first is, alt text on images. If you have images, then you need to provide alt text, which is, behind the scenes, a short text description of the 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 heading-- 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 otherwise access with the mouse.
And so that, too, is a WCAG success criterion. Name, role, and value is 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 AA, 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 AAA requirement with contrast that is a little bit more stringent to meet. Level AAA, you have to have even a higher contrast ratio than what you have to have in level AA.
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. ANNA MARIE GOLDEN: OK. Thanks, Terrill. Providing the slide deck all in advance.
There we go. OK, so contrast. We were talking about adequate contrast between the foreground and the background, 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 fades into its background. And it's hard for folks with low vision to be able to consume what is on those tabs. Even me, I have to 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 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, "Please see our Getting Help page," with Getting Help being 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 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 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 1 on it.
And then, in my last example on this page, I actually really like 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 2 very well in that circle. So maybe if the circle wasn't filled in, maybe if it was just a circle, like a border around the 2, 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 controls.
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, it's 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 web page 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 web page. And to move backwards, you can use Tab and Shift together to move backwards.
But we also have accessibility bookmarklets available to use, web developer extension. Lighthouse is in Chrome DevTools. And also in Chrome DevTools, from Deque, is Axe. There's Siteimprove. There's WAVE from WebAIM, which includes color contrast checking, by the way.
And there's the TPGi Colour Contrast Analyser. So let's talk a little bit about accessibility checkers in perspective. Most accessibility problems cannot be automatically detected. So while zero errors is a great start, it's not really a guarantee, because 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 Terrill is going to show you the first few demos. So Terrill, go ahead and take it away. And I'll stop sharing my screen. TERRILL THOMPSON: 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.
OK, 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. There's an inaccessible university home page 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 all of those solutions implemented. So I'm going to actually open each of those in a new tab, so to get easy access to them.
This is the before version. And in the interest of time, normally, I would do this interactively. And 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, can 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 look at the page and ask yourself, who might have difficulty accessing the 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. These menus here have what seems to be pretty low contrast. And so that would be one thing that really jumps out.
We also talk 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 does this have alt text? That's a question. And 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 logo that says, Accessible University.
And you may have noticed, when I hovered over these menus, that they do have dropdown menus. And so can I access those if I'm not a mouse user? If I take that no-mouse challenge and just 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, test with keyboard. So a keyboard is a great accessibility checker, because you don't need any other tools.
And you all probably have a keyboard already. 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 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 I can respond to that. So I just pressed Enter to move on to something, 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 keyboard 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.
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 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 contentinfo. These are all what are called ARIA landmarks. It's part of that ARIA specification that allows us to section off the 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, Bienvenido, 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 dialog box that shows a heading tree. And that really gives me a sense of how this page is organized, and 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 page is completely inaccessible. For a screen reader user, they come here, they maybe check for ARIA landmarks. There are none. They check for headings.
There are none. So they are almost reduced to having to read the entire page from top to bottom, linearly, and try to make sense of all this content, which would be a nightmare to have 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 1, all of the things that I suggested. Should be, heading 2's are heading 2's now. And so it gives us just a really quick visual indication of whether the heading structure 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. I like the heading feature.
Has a similar feature to the accessibility bookmarklets. But if I click on Outline, Show Element Tag Names, and then click on Headings, it presents the same information we just saw, but does so in a slightly different way. And so may prefer one over the other. It also 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 image. So we've got alt equals "Accessible 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 those. You've got a more detailed description of this photo here, because that photo really requires a lot 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 a super-detailed description. Just provide 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 Footer. So a really nice, nice feature. And there's so much more built into that tool that we won't go into now.
One other tool that I'll show, and then I'll hand off to Anna Marie, is, if you go into DevTools in your browser, you've got all sorts of things. But one thing that's built in to Chrome is Lighthouse. And you can check. Lighthouse will generate a report based on all sorts of variables. You can look at performance, and best practices, and SEO. And you can 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, it thinks for a moment. And then, it creates a report. And in this case, we got a score of 100, which is awesome.
But that's on the accessible version. If we do the same thing on the inaccessible 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 page that high of a score.
And it really speaks to Anna Marie's point earlier, that checkers can only check so much. And this is not going to check everything. I mentioned, we know that there are 18 problems with this site. And the Lighthouse checker finds a few of those, but certainly not 18 of them. But it does provide some useful information.
So for each one of these it talks about the color contrast. And it actually shows where all the color contrast problems are. If we get down into there's a 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 a screen reader user would have a difficult time.
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 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 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 DevTools, and provides some pretty sophisticated functionality. I've lost track of what is free with Axe anymore, because they've gone 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 WebAIM. But I'm going to leave that to Anna Marie to demo that. ANNA MARIE GOLDEN: OK, let's talk WAVE.
OK, so this should look familiar. Terrill 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 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? 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'll 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 side-- or my left sidebar. Instead of the summary being open, I'm 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 when I click the CODE link? Well, I click the CODE link. And at the bottom of 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 that indeed, 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 Terrill 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, my 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 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 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 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 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 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 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 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 I'm going to refresh my page now and show you the Colour Contrast Analyser. 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. OK, so in the Colour Contrast Analyser 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 text on white background passes all of the tests for the color contrast.
OK, 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 Colour Contrast Analyser. And it gives me that hex number. I'm going to do the same for the background. OK.
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 web page. But that way, you know it's got the right colors. But it's telling me, still, these are all failing. So 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 just change individual color channels. Or I can click this box to sync them all to move them all. So that's color contrast. Guess it's a good time to open it up for questions. So we'd love to hear what you've got.
TERRILL THOMPSON: Just point out also, Anna Marie, that all of the tools we have demonstrated are free. ANNA MARIE GOLDEN: 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. "So are all those tools listed on the accessibility tools page?" Yes, they are.
TERRILL THOMPSON: And there are many more as well. That's our annotated list of our favorite tools among our staff. And so do check that out. ANNA MARIE GOLDEN: "Have you evaluated the ARC toolkit? And if so, what did you think of it?" I have not tried that one.
Terrill, have you? TERRILL THOMPSON: I have not, either. ANNA MARIE GOLDEN: I think I'm going to write that down so I can take a look at it. TERRILL THOMPSON: It's from, I believe, the ARC toolkit, from TPGi. ANNA MARIE GOLDEN: Oh, OK. TERRILL THOMPSON: Formerly, the Paciello Group.
But I haven't looked at that. ANNA MARIE GOLDEN: "It might be worth pointing out that a good start is making sure you validate your HTML." TERRILL THOMPSON: Yeah, that is a good point. ANNA MARIE GOLDEN: And-- sorry, it moved on me, I think. "And, to a lesser extent, the CSS, the W3C, HTML--" I lost my-- can you still hear me? I lost my audio. TERRILL THOMPSON: Yeah, we can still hear you.
And you might not be able to hear us. I must say that the Tools and Resources page that we keep linking to includes 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 if you skip that, then 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. ANNA MARIE GOLDEN: "Do you have accessibility guidelines tools for social media also? Facebook, Instagram, et cetera?" TERRILL THOMPSON: We don't have guidelines per se. But we have a single resources page, where, if you go to our website, uw.edu/accessibility and then
add /social to the end of that, that links to the various social media platforms' accessibility pages. Those that have anything are linked there. But it's a moving target. They change 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. ANNA MARIE GOLDEN: And we have a link in the chat to that page.
Thank you, Gaby. TERRILL THOMPSON: 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 people are working on. If you want a 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. And we're all trying to make a more accessible UW web presence. ANNA MARIE GOLDEN: It's a nice, safe environment to show your stuff for the first time. TERRILL THOMPSON: OK, well, it looks like we are out of time. But glad you all could make it.
Again, take advantage of some of the other events that we offer. Feel free to reach out if you have questions. If you want an accessibility review or have any needs related to web accessibility, then you can send an email to help@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.
ANNA MARIE GOLDEN: Thanks for joining us, everyone.
2022-03-03