 Also, in addition to typing your questions into chat, if you prefer just asking, again, having that conversation as a small group, then feel free to just raise your hand. The best way to do that is digitally. Alt Y, I think, for Yo, is the keyboard shortcut. Different on a Mac, but I think the Y still comes into play there, so you can raise your hand and we'll call on you if you have an immediate question. Or you can type in the chat either way. So today, we wanted to talk about web accessibility. This is a regular topic of these webinars. We do twice a year presentation on web accessibility, but in this case, we're going to mix it up just a little bit. And the focus is going to be on the accessible university demo site, which we created 20 years ago, actually, to help us in presentations like this, to talk about web accessibility. So the focus is going to be on that. We're working on a new version. I think maybe the promotional materials said we were going to be unveiling the new version. And we kind of are. We're giving you a sneak peek, but it's not quite ready for release yet. We're going to be giving a much bigger presentation to a national audience accessing higher ground in November. And that will be the official unveil, but we're getting pretty close. I just have a few small things to work out. So but this will give us an opportunity to work with that. So I want to share my screen. And I do have a few slides that I want to kick things off with. So I am Terrell Thompson, a manager of the IT accessibility team within UWIT Accessible Technology Services. We're a small team that is here to meet all of your technology accessibility needs. So any questions that you have, any help that you need related to web accessibility or document accessibility or video accessibility, software that you're purchasing, software that you've already purchased, we get involved in all that sort of stuff and serve kind of a consulting role related to technology accessibility. So feel free to reach out. If you send an email to help at uw.edu and mention technology accessibility or just be specific and use accessibility in your request, then that will come to us and we're happy to help. So what is web accessibility? Well, I've got just two bullets. So it can be simplified quite a bit. It is creating a website that works for all users that really should be our goal anytime we're creating or providing a website, a web application, content on the web. We want everybody to be able to access that. Also more specifically, creating a website that complies with web accessibility standards. So there are standards that help us to understand what it means to create a website that works for all users. So it really is both of those things. That's how we look at and how we measure web accessibility. So who are all users? That may seem obvious, but if we start looking at their individual characteristics, that really gives us a better idea of what web accessibility is about. And maybe we're talking about people with disabilities, people without disabilities, but that really is a kind of an artificial construct and not very helpful when we're trying to understand web accessibility. It's better to think about sort of the particular behaviors that you're expecting users to have and then asking questions about how they, where they fit on this continuum related to those behaviors. So for example, the ability to see. That's not a given. Not everybody has perfect vision. So some people do have 20-20 vision. Some people can't see at all. And most of us fall somewhere in between on a very broad spectrum. Some of us have assistive technologies that we use to help us to be able to see. I use eyeglasses, for example, without them. I fall somewhere in the middle, actually the lower portion of the continuum. Eyeglasses boost me up closer to the top. Some people, even eyeglasses won't help. So they may be using assistive technologies like a screen reader to read the content of a computer screen in a synthesized voice. Or they may be using a Braille device to access content through a tactile interface. But a lot of variety in people's ability to see. Same thing with people's ability to hear, ability to walk, read print, write with pen or pencil, communicate verbally, tune out distraction, and so forth. I should also add the ability to use a mouse to this because that is a behavior that we often sort of associate with using the computer or accessing websites. Some people are able to use a mouse without even thinking about it. For others, that actually is a very difficult endeavor. It involves holding the mouse steady. It involves sometimes holding down a button while moving the mouse in a straight line, clicking twice in succession without moving the mouse. Those are all pretty challenging behaviors for certain people. And some people, imagine somebody who has no hands or has limited ability to use their hands. They're not going to be mouse users at all. They're going to be using some other technology. Perhaps just the keyboard, maybe with a stick or with some other assistive technology that enables them to use the keyboard effectively. It's pressing the tab key to move through your website, for example. So all of these issues, people fall all over the place on this continuum. And that is what all users is all about. This wide variety of users developing websites, web applications that are usable for everyone. So the other part of that definition was web accessibility standards. What do we mean by that? Well, most web accessibility standards fall under the domain of the Worldwide Web Consortium, or W3C. That's the organization that manages all sorts of specifications and standards related to the web. Hypertext markup language or HTML, the language of the web. That's theirs early on in the day, the early days of the web. They start working on the web content accessibility guidelines or WCAG. So that too is their set of guidelines or standard. And they also developed a specification called ARIA, Accessible Rich Internet Applications, which plays a key role in accessibility of particularly complex, dynamic, rich internet applications. And we'll talk more about that in a moment as we start looking at the demo. So looking at WCAG specifically, that is the standard that we're trying to meet. And specifically, we're trying to meet the latest version, which is WCAG 2.1. This has been around again since the early days of the web. They started working on this in the early 90s, published the first version in 1998, the second version 10 years after, and then 2.1, the latest version 10 years after that. So that is the current standard that we are required to meet via Washington State Policy 188. And it's become clear through all sorts of policies and legal resolutions and settlements that WCAG 2.0 or 2.1 more recently is the standard that we're expected to meet. And within WCAG, there are quite a bit of details, if you drill into it, that specifically define web accessibility. And those at the deepest level are called success criteria, essentially measurable checklist items. And there's 78 of those, but they're all assigned a level, level A, level 2A, and level 3A, that has to do with kind of how critical they are and how difficult they are, sort of a balance between those two things. And it has emerged through all the policies and legal cases that level 2A is the expectation. So we're expected to be able to meet level A and level 2A success criteria. So that's a total of 50 success criteria in WCAG 2.1 that we're supposed to meet. And so as we look at the demo site today, we're not going to be talking about specific success criteria, but we're just going to kind of be using common sense and thinking about the web and the diversity of people who use the web and the different characteristics and asking ourselves who might have difficulty using this particular feature or this particular interface and what can we do to prevent that. So Accessible University was, again, it's a 20-year anniversary, so we originally created this website in 2002 as part of the Access IT grant that was from the U.S. Department of Education, National Institute on Disability and Rehabilitation Research, I think. And it's a pretty simple site, really. There's a fictitious university homepage, the before page that has accessibility problems, and there's an after page that has all those accessibility problems fixed. And then there's an issues page that kind of is the glue that binds the two that just lists and explains all of the problems and what their solutions are. So a great way to teach about accessibility, particularly about web accessibility, and also a great way to learn, even on your own, you can explore that site and learn quite a bit. So we have, since we created that original version, 20 years ago, we have maintained it and upgraded it a little bit here and there to try and keep it current. But accessibility does change as technology has evolved quite a bit in 20 years. Accessibility standards have also evolved. And so it was starting to show its age a little bit. And so we have been working on an update. It's almost complete. And you're going to be the first people to actually see that today. So the new 20th anniversary edition funded by the National Science Foundation as part of the Access Computing Grant. And we've got an Access Computing logo in the bottom left. We've been funded by NSF for quite some time now to work on just breaking down barriers for people with disabilities who are interested in the computing fields. And we do a lot of work in that space. And so this is just a project that sort of fits within that scope. Also, I mentioned accessing higher ground. We are doing a half day pre-conference using the Accessible University demo site. So with it for a really deep dive into that, looking at all the issues in great depth. That conference is great. And it's great for so many other reasons. If I could only choose one conference to attend every year, that would be the one specifically focused on accessible technology in higher education. It's a fairly small, intimate group that is committed to the same goal. So check that out. It's in Colorado every year. And I think they'll have a virtual, the hybrid as well, that's at accessing higherground.org. A few resources that I'm going to talk about. I just wanted to share links to, first of all, the demo site itself. This is the old version that you'll get if you go there now. In a few weeks, it'll be updated to the new version. But uw.edu slash access computing slash AU is the actual demo site. And then a lot of information about accessible technology, sort of our hub for communicating to the university, is the UW accessible technology website at uw.edu slash accessibility. We also, I'm going to be demonstrating a few accessibility checkers. So we can kind of try to identify what the problems are using different tools. There's an annotated list of tools at uw.edu slash accessibility. Again, our site with slash tools on the end to get to the tools page. And I'm also going to be talking a lot about this resource from the W3C, which is the design patterns that are specifically recommended for particular user interfaces. So as you get into more complex turf with websites, where maybe you've got a navigation menu with drop-down submenus. Maybe you've got a modal dialogue. Maybe you've got buttons that trigger other things happening on the page. There are design patterns that have been created with a whole lot of community input on the best way to do these for accessibility. And those are all very thoroughly documented in the ARIA authoring practices guide or APG. And so I highly recommend that all designers and developers keep that open in a tab at all times and consult that. And we'll talk about a few instances where we had to consult that on the Accessible University site. So that's it for the PowerPoint. And I want to jump over to the website. So this is what it looks like. It is available on GitHub. And actually, there have been quite a few other institutions and accessibility consultants who have used this and have contributed to it and have forked it and created their own versions. And it's great, actually, to have community input for such things. But here, again, is the heart of it. We've got an inaccessible homepage, an accessible homepage, and an issues page. And then we also have some different versions of digital documents so that we can use that for teaching about document accessibility. But for today's presentation, I'm going to focus specifically on the web pages. So, Phil, we'll start with the accessible homepage. And let me actually get a show of hands. How many of you have seen the original Accessible University or have used or explored that? Again, it's Alt Y, I think. Dan helped me with the acronym if I'm wrong about that or what the MAC equivalent is. Y for Yo. Y for Yo. And it's Alt Y on Windows and Command. Is it Command Y on the MAC? It's Option Y. Option Y, OK. OK, well, so we've got a few hands up, I'm seeing. But not many. Most of you are new to this altogether. So, those of you who raised your hands, you'll see some differences here. And as we talk about new features, I'll specifically call those out so you'll know which ones are new, what we've changed. Obviously, there's a new, the carousel right out of the gate is new in that we used to have different images up there. So, we've changed the interface of the carousel and changed the images that accompany the carousel. But there's some other things here, too. So, this is the before page. We know that it has a lot of accessibility problems. But at a glance, maybe you wouldn't think that. It looks pretty straightforward. It's well-structured. It's got good, it's mostly just text with a few features. So, if you're asking, how do I know whether my website, my web page is accessible? Well, one of the first things that you need to do is think about what the function of the page is. What is a person supposed to do when they come to this page? And how are you expecting them to do it? So, if we kind of take a quick tour of the page with that in mind, first of all, it's broken into sort of different regions as are most web pages. You've got usually a banner across the top. You've got a navigation menu that helps us to get around on the website. And as you've seen a couple of times, because I accidentally hovered, when you hover over this menu, a submenu pops up and I can mouse over and select different submenu items from the menu. Then everything else might be considered main content. And then, at the bottom, there's a footer. So, those are kind of the main regions of the page. There's also what might be a sidebar over here on the right, in this case, it's a form. So, we can actually apply to the university with this simple form. We've got a carousel with different ways of getting around. And it sort of tells a story. There's text overlays on top of the images. So, it says a modern school rooted in its history. And I have to look pretty closely to try to see that text. But I think it says, with opportunities to learn and grow, and then we go back to start. We've also got a previous button over here, which initially might be hard to notice, but there is previous and next. And you also have these little dots called lentils, which change. So, I can see that which slide I'm on because it's indicated with a yellow highlight. And I can also use these for navigation to skip ahead or to jump back. Then I've got different sections. I've got a welcome section. I've got a bienvenido section. So, reaching out to Spanish speaking people. There's a section here, can you spot the barriers? And this is really kind of the heart of how this is intended to be used. There are at least 18 accessibility issues on this page. Can you spot them? So, we can kind of gamify this. And, you know, see if you can spot the issues without being told what they are. To see a list of all known issues though, you can click here. To see a more accessible version of the page, you can click here. And for a cheat sheet of accessibility issues, you can click here. Then you've got a table that shows AU enrollment trends last year and this year in CS, ING, ECO, PHY, and SI, both for undergraduate and graduate. And then we've got a video that if we have time at the end, we can turn to video. Video is a new feature. We had not included that before. And that, you know, the whole lot of issues that we can talk about related to that. So, given that quick tour, how many of the 18 barriers can you identify? Just thinking about the different ways that people might be interacting with this. What sort of barriers might they encounter? Karen, feel free to just unmute and share. That might have been an accidental hand raise. Anybody feel free to either type in chat or raise your hand. And there's a question in chat. Will the slides be provided? Yes, they will after the meeting. Jackie says, can you use the keyboard to navigate the carousel? That's an excellent question. Everything that I have done so far has been with a mouse. So that's a question. And you don't know necessarily whether something is inaccessible or not. At this point, we just wanna sort of unearth the questions. What questions do we need to ask? And that's a really good one. Can you do, not just the carousel, but all the things that I was doing with a mouse? You're displaying the sub menus. That's another one. Can I do that with the keyword? Color contrast on the photo, that color contrast in a lot of places is questionable. It is also measurable. And so that would be something that I would wonder, like the menus seem to have quite poor color contrast. And the fact that I couldn't read some of the text here in the slideshow suggests the text, white text over top of a photo is probably not a good idea for readability and accessibility. Okay. And Karen confirms that was an accidental hand raise. That does happen. So no problem. John raised the question, alternate text for the photo. There are four photos here and they all communicate something pretty significant. There are also other images. There's the image at the top. The whole banner here is accessible university. That's an image. There's the captcha in the form. That's an image. And probably does not have alt text because that would be a security problem. So that raises some interesting questions. How do we get past the captcha? And I think there's also an image, a creative commons image in the footer. But that's a good question too. Can a screen reader access the content of the image? Okay. And Jackie points out the captcha probably is problematic. There was another comment too. Click here, not specific enough and we'll actually show why. Also, this, can you spot the barriers section? And I read that aloud and from the context, if it says click here, click here, click here, then you probably assume there are links within that but it's not visibly apparent that there are links within that section. And this is a really frequent problem actually on the web where designers have gotten away from underlining links and they use color only to communicate that something is a link versus not a link. And in this case, for those of you that are not color blind and they can see the color accurately, you probably think this is an extreme case. Nobody would use an almost black text for their links if the text itself is black. But if somebody is color blind, that may be in fact, how they perceive links if they're using color only. So a lot of times I see dark blue, for example, as the link color in a block of black text and they both look exactly the same to certain groups of users or maybe to any user if they happen to be looking at a mobile device or any screen where there's sunlight or glare that it becomes difficult to see. So browsers have always underlined links by default for a reason. And they still do by default because it works as a good way of communicating that something is a link. So it's in some curiosity from Jackie about how a screen reader would process this table if this would make any sense. And so that again is a really good question. So let's do a couple of tests. Let's try this with a keyboard. I'm just gonna start at the top and I'm gonna press tab and navigate through the page and see what all I can access. So the first time I press tab, I get to the menu and the sub menu appears. So that may seem to be accessible, but if I press tab again, I go to news, then I go to governance and I go to diversity, et cetera. I don't want to access everything in the menu. Let's say I'm trying to get over to that apply now form. How do I get there? If I press escape, I would expect that to close the sub menu, but it doesn't work. If I press the arrow keys and arrow right, I would expect that to go horizontally across the top level menu items, but that doesn't work. The only choice I have is tabbing through all the menu items. And this is a pretty short menu. It still takes a long time. If it was a much more comprehensive menu, that would take forever. This is a new feature in accessible university. We used to have a much more inaccessible menu that had sub menus that could not be triggered at all with a keyboard, but what we have found is that the super fish or sucker fish menu model is in wide use out there. And it used to be sort of promoted as an accessible menu option because it is technically keyboard accessible, but it is designed to work only with tab. And that's not very accessible because it takes so long to get through the menu and you can't get past it. This resource that I talked about already, I just wanted to take a quick look at it, the ARIA authoring practices guide has specific design patterns and specific an index of examples or a few different ways of getting around. But if we look at, for example, a navigation menu, there's a whole lot of examples of navigation menus, but every design pattern in this resource has a list of keys that should be supported by the menu. And so the idea is if everybody designs and develops according to the standard, then every time you access a menu bar on a website, it's always gonna be the same. It's gonna work with the same keystrokes, but it is expected to be able to move with the arrow keys left, right, up, down, even the home key and the end key and to be able to press escape to close the submenu. This is in the submenu, if the submenu is open, you get different key functionality than if there is no submenu open. These design patterns also have basically the recipe spelled out for what you need in the way of ARIA in order to communicate effectively to assistive technologies. And so both of those components, the keyboard mapping and the ARIA recipe are spelled out in great detail within this resource for all sorts of different menu or different design patterns. And so that really is the definitive resource. If you're doing anything that is remotely interactive, then check this first to see if there, as it says here, well, read this first to see if there is a design pattern that will meet your needs. So back over here, the menu is not very keyboard accessible, but now let's move beyond that. We've got to tap through it once again to the carousel. And I actually can't, I'm tapping, tapping, tapping. I can't access the carousel, I jumped past that, and I can't seem to access anything else. I can't tell where I am. And this too is a problem that's really common on the web that a key part of keyboard accessibility is visible focus. If I can't tell where I am, even if I can access something like these click here links, those are just links. So I think I probably am tapping to those, but I can't tell if they have focus or not because there's no visible focus indicator. Browsers do provide visible focus indicators by default. In Chrome, it's a prominent blue outline around the item that has focus. And in Firefox, it's a less prominent dotted line, which can be very difficult to see. But it's possible for designers with CSS to override that and to make it invisible. So there's nothing, there's no way that I can tell where I am as I'm tapping through the page. So that's another problem. One of these links also goes to the click here. One of the click here links for a cheat sheet of accessibility issues. I'm just gonna click that with a mouse because I can't tell when it has focus with keyboard. But that pops up with a dialogue and here are your 18 accessibility issues. It lists them all. That would be cheating if we actually read those now because we're still gonna explore. But if I try now to close that dialogue and discover that I'm actually tapping around behind the dialogue, the modal aspect of this is visible, but it's not truly modal and that I can still interact with stuff behind the scenes. And that means, I don't know how to get back to the dialogue. So now I'm in the form. I'm gonna have to tab around for a while. Maybe I'll land on the dialogue, maybe not. Escape, I would also expect to close the dialogue and that doesn't seem to work. So I'm really kind of stuck unless I'm able to use a mouse, then I can click on this X or on the okay button. But as a keyboard user, I would be really hard pressed to figure out how to make this go away because now it's in my way. And then with the form, we'll explore that with the screen reader. So I think everything at this point, probably we can just look at with the screen reader. I'm gonna pop up JAWS. And I believe I remember JAWS. Are y'all here? And somebody give me a thumbs up or some sign that you hear. You heard JAWS speak just then because I can't remember if I, yes, okay, awesome. Sometimes I forget to check that, check box in Zoom to share my sound. Meeting controls, accessible university demo site dash and accessible version dash Google Chrome. Okay, so here I am on this website. As a screen reader user, the first thing I probably am gonna do when I go to a website is look for regions of the page. As I was describing the page initially when we did that little tour, I mentioned that there's a banner at the top, there's a navigation menu, there's a main content section, there's a footer at the bottom and there's a sidebar. And most web pages have those components or some combination of those components. And so those are called landmark roles or landmark regions. And ARIA was introduced a way to add a role attribute to HTML so that those could be specifically defined, standard kind of common sections of the page. So a user can easily jump to them. Those were later replaced with semantic elements in HTML. So with HTML5, we have a header element and a main element and a nav element and a footer element and a side, which is the sidebar. And so that all has the same purpose of what used to be done with ARIA and now it's built into HTML. Screen readers support that by allowing me to jump from section to section of the page using the R key in JAWS for region. And so if I press R now, there are no regions on this page. It says there are no regions on this page. So that's frustrating because now I'm gonna have to find some other way to explore. So another way I might choose to explore is through headings. As I mentioned and as we all saw, there's a clear visible heading structure. Looks like maybe accessible university, that banner there, that would be like the main heading of the page. But then we've got a bunch of subheadings. Welcome, bienvenido. Can you spot the barriers, AU enrollment trends? Those are all sort of peers. They're subheadings at an equal level. I would call them H2. And the headings should form an outline of the page content so I can really easily figure out how all the parts are related. So if I hit H now in JAWS, that allows me to jump from heading to heading and I can see how this page is organized using headings. There are no headings on this page. Uh-oh, so there not only are there no regions on this page, there are also no headings on this page. So by now I'm getting really frustrated and my only hope is gonna be to read this page linearly from top to bottom, which is super inconvenient. But let's see what I can find by doing that. Accessible university demo site dash in accessible version. So I'm at the top, I'll arrow down. A 123,456,789.gif graphic. So what I just heard was a bunch of numbers didn't make a whole lot of sense although it ended in .gif graphic. And so I know that's a graphic but I have no idea what it is. And what's happening there is it's reading the file name because there's no alt text. So if you have alt text that describes this image, screen reader will read that. If you have alt equals quote, quote an empty alt tag, then the screen reader knows to ignore the image. It's just decorative. But in this case, they didn't have either of those. They had no alt tag. And so the screen reader doesn't know is this a meaningful image or is it not? Maybe I should read the file name just in case this is critical and the user really needs to know what's there and maybe the file name will offer some clues. And sometimes a better named file would offer some clues but probably not a great description. And in this case, certainly not a great description. So that's completely accessible. List of four items. The menu is a list of four items. So that's helpful. Although at this point, I don't know what the list is of. Visited link about. But now it's starting to make some sense. This is a visited link. Enter accessible university demo site dash in accessible version. Visited link about. If I click that, the sub menu didn't appear. So it's not supporting my using this as a screen reader user. If I tab through it. Academics link. List with four items. Decreate programs. AU faculty. Distance learning link. Then this is fairly, again, it's fairly accessible. Technically I can access all the sub menu items using the tab key. But again, that's the only key that's supported. And so I can't press escape to close out of this. I can't get out of it to bypass it and go to something else. So not a very good model. Libre admission link to five link. Park it, click your link. OK, so and again, the carousel is completely inaccessible. The reason is that this is built with dibs, as is often the case, where this isn't actually a button for next and a button for previous. And these lentils aren't actually buttons. They are dibs that have been added, that have some programmatic capabilities. So there's JavaScript that's listening for me to click on these dibs. And that then has some functionality associated with it. But semantically, they aren't focusable. You can't tab to a dib unless it has been actually made into an interactive component. And that would require adding some aria to it and adding a tab index equals zero so that it becomes part of the tab sequence. So that hasn't been done. Back on the APG, the design patterns, there is a design pattern specifically for carousels. Carousels are pretty complex, but there is a prescription for how you do this in a way that is more accessible. So I am back on that. Click here. Let's only tab again. Click your link. Click here. Click your link. Click here link. So in that context, as I'm tabbing through the page, doesn't make any sense, right? Click here. Click here. Click here. What's going to happen if I click here? And I can also, as a screen reader user, I can bring up dialogue boxes that allow me to access different parts of the page. So I'm going to bring up the links list dialogue. Links list view. Click here. 7 of 10 to move to items use the arrow keys. So a lot of times a user will do this. If they know there's a link on the page, they're looking specifically for that. And here in this context, click here. 6, click here. 5, click here. Click here. 7 of 10. We have a bunch of click here links. And again, I'm not going to be brave enough to follow one of those links because I have no idea what's going to happen. Another common example that you get of this type of thing is read more, where you've got a block of text. And then after that, you've got read more so that you can follow a link to get read the whole article. And you'll open up the links list. And there might be a dozen. Read more, read more, read more, read more with no context. So the rule about links is that it should make sense out of context. Escape. So let me jump down to the table. Table with 11 columns and four rows. Column 1, row 1, blank, space, last year, this year. So I'm just going to arrow initially through all the headers. CSN, ECO, Phi, Psi. CSN, ECO, Phi, Psi. So we know that we've got headers for CS, Ing, ECO, Phi, and Psi. I might be able to figure out what those acronyms stand for. CS is fairly obvious, I think. Phi and Psi, I have to think about. ECO could be ecology or it could be economics. So I really don't know. Under 1481. As I get into the numbers, as a screen reader user, I can navigate in table mode, which is a particular way of navigating through rows and columns, where if the table is coded properly, it will read the headers associated with that cell. Let's see if this table was coded properly. 400, column three. So it reads the data and it tells me I'm in column three. 727, column four. But it doesn't tell me what the header is exactly. And so this is not coded properly, and it's really gonna require a Herculean effort to memorize the position, which column are all the headings in, as I'm moving through the table and trying to remember all that in order to understand what's happening here. Let me jump up to the, actually let me jump. For the back, This is the Spanish text. Accessible universe, it left pair and you a right pair and that's the university. Tisha, why is the super Gina the fishing est up a Gina as the designado para demonstrate. You know, very good. And if anybody speaks Spanish, you probably know that is not very good Spanish pronunciation. As it turns out, Jaws is multilingual. A lot of screen readers are able to handle different languages, but they have to be told what the language is. They're not smart enough to be able to figure that out on their own yet. And so there needs to be a Lang attribute on this entire block of content that says, this is Spanish, Lang equals ES. And then the screen reader would know, oh, this is Spanish and it would switch into Spanish pronunciation mode. So it'd be a much better experience for this. I'm going to press F to jump to the form. Play button. Look at that. Actually, he's jumping to the video because it has a bunch of. Updown slider, one minute, but enter show more left, right. Name, call an email, call country, call engineering checkbox, not checked. I am in the form. Okay. Let me go back. Name, call and edit type of text. Okay. So first of all, the required fields are in blue. And so again, that color issue, maybe we can perceive the blue form labels. Maybe we can't. Not a good way of identifying which fields are required. Two, email, call name, name, call and select. Email, call and edit as popup. Country, call and edit type of text. Engineering checkbox, not checked. So I fill this out. And now I'm in the desired majors and I'm stepping through those. Economics checkbox, not checked. That's the economics checkbox. Physics checkbox, not checked. The checkbox, space box, psychology checkbox, not checked. I definitely don't want to major in physics. That would be awful. It's the hardest discipline, I think. So I'm much more of a psychology kind of person. So let me just check. Physics checkbox, not checked. Not on the physics checkbox. Psychology checkbox, not checked. Make sure I am on the psychology checkbox and I checked that. And then I apply and I get accepted and I'm a physics major. And that is going to be shocking. So what's happening here is this form actually is not properly labeled. None of these labels, even the name and email and country, those are not correctly identified in association with the fields they represent. And the checkbox labels are not associated with checkboxes. Some screen readers, actually all screen readers except JAWS will not even try to match up labels with form fields because they don't want to get it wrong. JAWS actually tries and in this case fails. So it's guessing what label goes with what form or with what field and it's guessing incorrectly. And that's going to have disastrous effects. So to ensure that doesn't happen, we need to use HTML properly to add a label that is explicitly associated with each form field. And of course, this CAPTCHA, if we go down to that. Security, please enter the two words you see below separated by a space edit type of text. The two words I see below, well, I don't see those words and there's no way for me to Submit by images slash CAPTCHA labeled graphic. There's no way to actually get those as a screen reader user to get that information. And so this is completely inaccessible and if it were a longer form and I had successfully filled it all out and then I'd get to this at the end, I'm really not going to be a happy person. Submit button to activate present errors. Space. Then visually an error message appears, but I didn't hear anything, right? As a screen reader user, all I know is I clicked the submit button and nothing seemed to happen. And so where am I now? Link graphic creative commons will submit button back on the images slash CAPTCHA labeled. Still on the form, but I really have no idea what I have to explore to find that error message. So we're seeing a lot of problems here with this website, 18 problems, as it turns out. And actually there are more that we have introduced in this version. So we need to update that count in the issues list. But let's jump over to the accessible version and see accessible university demo site dash accessible version. How are the experience going to be different with an accessible version? Turn off the fast forward, with also five preferences button menu collapse menu. F5 accessible university demo site accessible university demo site dash accessible version. So once again, I'm going to use R to navigate through the regions of the page. Heading level one graphic accessible university banner. So that's the banner region. It tells me the first item that's in that region as well as what region it is. Main menu navigation region. There's a main menu navigation region. Main region. There's the main region. Previous button slideshow carousel. The carousel itself is in a region. Play button video player region. There's a video player region. Heading level to apply now, apply now form. There's a form, which is a separate region. Link graphic creative commons license content information. And there's a content information or a footer region. Wrapping the top. Heading level one graphic accessible university banner. If I also navigate with headings, I can press the H key again. Welcome heading level two. Bienvenido a los eventos. Notice that that was read in Spanish. Can you spot the barriers heading level two. AU enrollment trends heading level two. So much more accessible. Now I've got an outline with heading one at the top and a bunch of heading twos. And so very easy to jump around navigate through the website. If I go up from where I am now. Short list of accessibility issues button menu. Notice first of all this paragraph, those links that used to say click here, now they've been rewritten so that they stand alone out of context. Still the same links, but now we can tell what they actually are gonna go to. And the third of those click here links actually shouldn't have been a link at all because it's important to distinguish links from buttons. And this is a, the function of this is it generates a modal dialogue. And so that is, that should be a button if it does that as opposed to taking you to a new page. So if we click this button or press space. Space accessibility issues one, no editing to, no alternate text on the format of images three. Missing or excessive, okay button to activate press enter. But I can also close dialogue button to activate presenter to the focusable items in the dialogue. And I can't access the stuff that's back behind. So this is a properly coded modal dialogue. I can either press enter on either of these buttons or close or okay, or I can press escape. Escape main region. In that case it's my focus back on that button again. If I now jump down to the table, I'm gonna press T to jump to the nearest table. Zero seconds left, right slider. Slide four button, slide three button, slide two, slide three, slide six, design problems that resulted in in numerous A.U. enrollment trends heading level two, table with 11 columns and four rows. The following table shows under graduate and graduate enrollment over a two dash year period by subject column one, row one blank. So notice it read that text. That text is actually a caption element that's part of the table. And so that's an important part of table accessibility. Just provide a general overview so people know kind of overall what how this table is structured. So when they get into it, it'll make a lot more sense. Last year, this year, computer science. Notice that instead of CS, it now says computer science. This is using the abbreviation tag, ABBR in HTML. And it spells out the abbreviation. So as I'm moving through now. In economics, English. Economic physics, psychology. Much easier to understand than CS, ING, ECO, PHI and PSI. Computer science, English. Economics, economics. Economics, economics. And if I now move to table mode and start navigating around through the table cells. Last year, English. 400. Last year, economics. 727. Column four. It reads all the headings that are associated with the cell that I happen to be in because this table's marked up properly with table headers identified and so forth. Let's go up to the form. I'm just gonna click. Actually, I'll hit H. AU video media player head applied now. Heading level two. And then I'll tell. Applied now form region. Name it required invalid entry type of text. So we're actually to communicate that something is required. We're not relying on color alone. It's bold. It has a red asterisk after it and it has the HTML required attribute. So if I. Email it required in country colon desired major left parent S right parent colon group list with six items computer science checkbox not checked the check press space bar. All of the the fields now have they're properly associated with their. And during checkbox economics physics psychology checkbox not checked space check Spanish checkbox not checked security question group Sunday cow Friday which of these is not a day required invalid entry type of text. So this is just an example of thinking creatively about the capture problem. The biggest question with a capture is always do you really need it? How much spam are you gonna get with the form that you have? And is it just gonna be a minor inconvenience to get some spam content that you have to filter through because the alternative is it's gonna be a huge inconvenience for your users for all users to have a capture and gonna be completely inaccessible to some users. And so this is an alternative to a visual capture one that uses a security question that bots are gonna have a hard time answering. So in this case, which of those is not a day? CW is not a day button to activate press enter. Although I shouldn't get an error because I left some required fields blank space name that required invalid entry type of text error call and name is required. So that error message is coded as an ARIA live region. It has ARIA-LIVE equals, actually has roll equals alert, which is the same thing as ARIA-LIVE equals assertive. So it interrupts the user, tells them, reads the error to them, gives them all the information they need to know which field was a problem. And focus is placed there in the offending field. So if now I type in E-R-I-L, then I go back down and I resubmit button enter email edit required invalid entry as popup type of text error call and email is required. Then it prompts me with the next error and so on and so forth. So if I'd just go ahead and Enter, fill that out, submit enter. Thank you, your application has been received. Then I get that immediate feedback again because it's coded properly to communicate with a screen reader user, but my focus didn't change. So it's predictable interface. I know exactly where I am and I can get around just fine, but I get all those messages. So I'm going to shut down the screen here and just show you really quickly how we can use tools to check some of these things. So like I've stressed ARIA landmarks. If we click on, this is the accessibility book marklets tool that is installed in Chrome. And if I click landmarks, then I can see, how the page is organized using landmarks. There's a banner at the top. This is coded as a navigation region. There's the main region right here with another region inside of it. It's actually a section and the carousel is a section. And there's content info. This is a footer down at the bottom. The form doesn't actually show up using this tool, but it is coded as a form, which is another type of landmark. If I click on headings, then I can see that indeed the Accessibility University banner now is an H1 and all the things that I think should be H2s to form a proper outline are indeed H2s. If I go back to the inaccessible version and I use a tool like Wave, then that tells me there are 16 errors. So it found 16 errors. I say there are 18 or more. And there's a little bit of a disconnect there, but probably it's not finding several of the errors that I found and it's counting many of the errors that I'm claiming to be an error is counting multiple times, but every tool finds different things and it's good to use as many tools as you can get your hands on and don't expect them to all be in sync with each other, but use them all because they all give you a different, a different, slightly different perspective to help develop your understanding of the accessibility of your website. So we can click on details then to see that there are images with missing alt text, there are forms with missing labels and the language is not identified. There are also our color contrast errors that are identified here. And as expected, the menu is a color contrast problem and really nice thing about this tool is it will help me to find a combination that passes. So we're looking to comply at level 2A for normal size text because this is not big enough to count as big. So we want the 2A under normal text to be pass and we just changed the lightness of the foreground until we get a pass rating. And ideally, you know, we'll go beyond that, you know, why not make it as accessible as possible. It'll pass at all levels, even 3A with 424242 as the foreground color. And this is what it looks like. It actually is easier for everybody to read. So why not just change that color to 424242? So really helpful tool within Wave. Whole bunch of other accessibility checkers again that are identified on our tools and resources page here on the Accessible Technology site. So encourage you to check those out. And I am fully out of time. So, and we like to end these things on time. But are there any questions of people, just burning questions that people have? Feel free also to reach out to me afterwards if you have questions you'd like to share. And my email is tft at uw.edu. Paste in that in chat. Hopefully this is helpful. Slides are available. Anne-Marie just pasted a link and the Accessible University demo site. Again, the old version is already out there, but the new version, if you're willing to wait just a couple more weeks will be up very shortly to replace that one. All right, well, thanks everybody.