 Well, welcome everybody. It's great to be back talking about procurement and accessibility once again. This is a webinar that we offer a couple of times a year and usually there's some fresh new information to share over a six month period. And so I think that might be the case this time, some new examples and some new insights. And I'm, I'm Cheryl Thompson. I am a manager of the IT accessibility team within UW IT accessible technology services. And I'm joined by Lynn McGill. You wanna say hi, Lynn? Hello everyone, I am Lynn McGill. I'm the assistant director of procurement for the Academy side of the university. And as you can imagine, things are very busy right now in procurements. I really appreciate Lynn joining us today. I'm taking an hour out of her time to talk about accessibility. So let me share slide deck. So we are here to talk about accessibility and procurement. And there will be a few acronyms, which we'll clarify later on in the presentation, but just to give you a heads up that they're coming, we'll talk about the W3C, the Worldwide Web Consortium, who is the organization that owns various standards related to accessibility, including the web content accessibility guidelines or WCAG as it's affectionately known. And ARIA is another specification of theirs, accessible rich internet applications, which plays an important role in web accessibility. And a big part of what we're gonna be talking about today is the VPAT or voluntary product accessibility template. Getting a little bit of noise on the line. I think I'm gonna selectively mute. Okay, so the heart of what we're gonna be talking about is documented on our procurement policies and procedures page on the Accessible Technology website. That is at uw.edu slash access tech slash procurement. And that page is organized by three sort of big steps where accessibility plugs in nicely into the procurement process. And our presentation today is also gonna be organized according to those three steps. So step one is solicit accessibility information. So as you are shopping for a product or talking to vendors about a product or going out to RFP, then that's an important time to ask about accessibility. Is your product accessible? Can you provide documentation to support that? And we're gonna talk about that step. Step two is to validate the accessibility information received. So once you ask about accessibility, you'll get some sort of answer back from the vendor and you need to be able to ascertain whether that answer makes sense, whether you can trust it and what sort of implications arise out of that answer. Is this a product that is going to present some risk, maybe major risk due to its accessibility failures or is it a product that seems to be accessible based on not only their answer but your validation of their answer? We'll spend a lot of time talking about step two. And finally, step three is to include accessibility assurances in contracts. So I'm gonna talk about the first two, Lynn is gonna talk about the third. And let's move on to step one then. Solicit accessibility information. So on that procurement web page, we actually have some sample language for an RFP and this is a big block of text on the slide. I won't read it all, but you can, if you're curious, you can read that on the web page. It actually is quoting from UW Procurement Policy 7.2.15 which guides a lot of what procurement services does related to accessibility. There are a few words that are bolded here. A few phrases bolded here in this text. Essentially it says University of Washington bidders and vendors shall be required to demonstrate the information technology provided to the UW conforms to our accessibility standards. And the accessibility standards that we need to meet are the web content accessibility guidelines or WCAG version 2.1 level 2A. And a means by which vendors are often disclosing how well they meet WCAG 2.1 level 2A is the VPAT, the voluntary product accessibility template. And so we will accept that and specifically VPAT 2.3 or higher. And so what does all that mean? That's what we're gonna get into in the next two slides. There's some additional language here in this recommended language for the RFP. That talks a little bit more about our expectations. We don't want them just to provide us with a VPAT. We want them to provide us with a good VPAT. And you're gonna see the differences in bad VPATs and good VPATs and why we have some specific instructions here as we go on and look at a few examples. So in order to understand a VPAT, first you have to understand the standards at least generally WCAG 2.1 level 2A, the standards that we're trying to meet. So this goes back a long way. WCAG, the Web Content Accessibility Guidelines, they were developed by the Worldwide Web Consortium or W3C in the early days of the web. So if the web was created in the early 90s, the Worldwide Web Consortium was founded in the early 90s and immediately they recognized that the web could erect barriers for people with disabilities and that was not the intention. The intention from the get-go when Tim Berners-Lee created the very first webpage was that this was gonna be a great equalizer and people all over the world were gonna have information at their fingertips in ways that were unprecedented. So the fact that maybe some people could be shut out of that revolutionary new development, that wasn't at all in keeping with the vision. So they started a group, another acronym, WAI, Web Accessibility Initiative, was founded in order to address this and they worked throughout the 90s on guidelines related to accessibility and they published the first version in 1998. So that was WCAG 1.0. Second version 2.0 was published 10 years later and another version 2.1 was published in 2018. So that's where we are currently. There is a 2.2 on the horizon, but 2.1 is the version, is the latest version and the version that we have state policy that requires that we meet. So 2.1 is our target. Within WCAG there are guidelines and there are various other layers within the document but at its deepest level, you have success criteria and those are essentially checkpoints related to accessibility, specific, measurable checkpoints and there are 78 of those. So it gets into a lot of detail describing how to make web content accessible. And each of those success criteria has a level associated with it and that has to do with priority, level A are the most critical issues or the easiest to attain. It's kind of a combination of both of those things that go into the level assignments. Level A are the highest priority and easiest level. Two A is kind of a middle level and level three A are either the less critical or the more difficult. And early when this was released there was a lot of discussion about which level is appropriate. Do we have to meet all levels, all 78 success criteria or is it just level A or is it level A and two A? And through legal action as well as policies that have arisen in response to the legal actions it has become clear that level two A is the bar. That is what we're expected to meet. So level A and two A fall into that. That's 50 success criteria that we need to meet. So that sounds like a lot. I like to narrow it down to just three because it's a tall ask for everybody who has anything to do with digital content to master all the success criteria. But if you just understand three that gives you some good ground to understand the basics of accessibility and to be able to read a VPAT which comes later and makes some sense of that. So the first success criteria that I wanna focus on is 1.3.1 info and relationships. It's a level A success criterion. And I've included this because it is so critical. We're not supposed to say that any of these are more critical than others. They're all supposed to be at least at level A they're all supposed to be equally critical. But arguably the stuff that's included in this success criteria are really critical like having headings explicitly coded as headings. For a screen reader user, they depend on having the outline of the page explicitly coded so they can jump from heading to heading to heading and understand the outline of the page, understand the relationships between the parts. Same thing if they're filling out a form they need to understand what the labels are that go with each of the form fields. And that can be obvious to sighted users but not so obvious to somebody who is navigating linearly through a form. So that needs to be explicitly coded in the markup. Same thing with tables. Maybe you've got column headers that need to be explicitly coded as column headers in order for a screen reader user to understand the table. So there are many, many other examples that fall into this but basically having good structure in the code really, really helps screen reader users as well as people using speech input and other users with disabilities. So this is a really important one and that's why it's included. The second is 2.1.1 keyboard also a level A and that basically means that all functionality of the content is operable through a keyboard interface. So if you can access something with a mouse you should also be able to access that with a keyboard. You should be able to tab through the interface maybe press enter or space to click on things. Maybe the arrow keys, maybe the escape key all play some role but that should all be intuitive and attainable without touching your mouse. So I encourage you actually to take the no mouse challenge try your website, your software application whatever it may be you should be able to use it with a keyboard don't touch your mouse. Try to go a whole day without touching your mouse and see which applications are easy to use and which ones pose challenges. The third success criterion is 4.1.2. This is name, role and value. It also is level A and essentially what this means is proper use of ARIA. So in order to understand that obviously you need to know what ARIA is. So ARIA stands for Accessible Rich Internet Applications. It once again is a W3C specification and with this they essentially have added some new markup that gets attached to HTML and goes beyond what HTML is capable of. And that specifically is intended to make user interfaces more accessible particularly if they are dynamic interactive interface web applications. And so let's look at just a really simple example even if you're not a coder hopefully this will be simple. What we have here is an accordion widget. You've got a button. It's coded here with a button, HTML tag and a slash button that closes it. And in between that you've got more info. So this is the more info button. So just imagine what this would actually look like on a webpage, it's a button that says more info. And then you've got a div or just a division or a section of content that has an ID of info one and it has some text inside it. This section contains more info. So let's imagine that that is hidden by default and a screen reader user lands on this button and it's announced as more info button and they click on that by pressing the space bar or enter and that that exposes this previously hidden content. So a sighted user if they were to click on that button with a mouse but new content appears, they read the new content. For a screen reader user, they click on the button and they have no indication that anything has happened. They don't know that new content was exposed and they don't know where to find it. So this in and of itself is not an accessible interface and this is all you can do with HTML. But if we add just two ARIA attributes, ARIA controls which points to the ID of the controlled content. So that's saying this button controls this content and we add ARIA expanded, which is false by default. If the content is hidden, then this is not expanded. And then user clicks on it, the content is exposed and then ARIA expanded and it would change to true. So now a screen reader user lands on that button. They hear more info button. They click it and they hear expanded, which tells them that by clicking on this button, something has just happened, it has expanded and there's new content available. Some screen readers also provide functionality that lets you jump directly to that exposed content. Otherwise, if it's immediately beneath the button, then they can just arrow down to access that. So you don't need to know all the ins and outs of ARIA and there are lots and lots of other attributes that can get out of HTML that improve accessibility. The only thing you really need to know for the purposes of evaluating VPATs is that ARIA exists and that if an application is dynamic and interactive, ARIA is gonna play some role in making that accessible. There's really no way of getting around that. So what is a VPAT then? It stands for Voluntary Product Accessibility Template. Sometimes it's called an Accessibility Conformance Report. Those two phrases are for the most part interchangeable and it is a standard means by which IT vendors can provide documentation on whether and how they meet accessibility standards. So the latest version is 2.4 and we say that RFP language that I shared earlier, version 2.3 or higher is required for our purposes. If we're asking a vendor to document how well do they meet WCAG 2.1 level 2A since that is our standard, then the only way they can answer that is with VPAT 2.3 or higher because that's when WCAG 2.1 was addressed within the template. So earlier versions did not support WCAG 2.1. So it's important actually not to get confused by the versioning that WCAG is on the 2.x series. VPAT is also on the 2.x series and that's just a coincidence. They really have nothing to do with each other. So the WCAG 2.1, VPAT 2.3, that 2.1 and 2.3 have nothing to do with each other. It's just a coincidence. So keep those versions separate. Within the VPAT 2.3, there actually are four different versions or four different additions and those correspond with different accessibility standards. So since we are trying to meet WCAG 2.1, then that's the addition that we want a vendor to provide to us. If they provide us with the section 508 addition, then that's the standard required by federal agencies but that's not what we're looking for. It doesn't answer the questions that we're looking for. Same thing with the European Union standards, EN 301549, that's not gonna be applicable to us. We want the WCAG version. I added a parenthetical statement here because it just came up last week actually that we might actually be required in some context to provide a VPAT. So this is pretty rare. Usually we're asking vendors to provide VPATs to us but we had a kind of a frantic request last week because a group at the UW was asked to provide a VPAT in order to receive federal funding. So federal agencies are required to meet section 508 and so I don't know how common this is or it's about to be. I haven't heard of it happening much but it might be that you, if you're getting federal funding, might be required to provide a VPAT that says the information technology that we're offering to users is accessible. So it's important to know, and if you have to fill out your own VPAT you're gonna need to know more than what we're covering here but we are happy to help with an accessible technology services if questions arise about this stuff. There is a fourth addition that is the international version, the INT version and that incorporates all of the above standards. And so if a vendor does business with federal agencies in the US as well as with European businesses then they may in fact just fill out an INT version because it covers everything. And so that would be acceptable for us too the INT version and the WCAG version. So this is what a blank VPAT looks like. It essentially is three columns. There's criteria which will vary if you're using a section 508 or European Union version but for the WCAG version what we have for criteria are the WCAG success criteria. So that's what we're seeing there and it specifies whether they're level A or level 2A. Then there is a conformance level column and a remarks and explanations column. The conformance level is actually a multiple choice column. So vendors are expected to claim either their product supports this success criterion or it partially supports it which means some functionality to product does not meet the criteria but mostly it does. Does not support means the majority of the product functionality does not meet the criteria. So there is kind of a sort of partly cloudy partly sunny distinction there. Is it does not support or is it partially supports? A vendor may opt to say partially supports because it sounds better but if you read the fine details you may discover that really it does not support. There's so many exceptions that this just is not a well supported product in terms of that particular success criteria. There's also a not applicable and not evaluated option for the conformance level column. The most important column in VPAT is that third column remarks and explanations where detailed remarks are provided to justify what they said in the middle column. So they choose partially supports then we wanna know what, especially what does not meet the criteria because that really helps us to understand the limitations of this product. Even if they say supports we wanna see remarks and explanations. We wanna know why they say that their product supports the success criterion because that gives us a lot more information about how usable this product is gonna be and how much the vendor understands what's being asked of them. So we've asked for accessibility from vendors and they've responded by giving us a VPAT, hopefully. And now we're at step two we need to validate the accessibility information that we have received. So looking further at the VPAT, first of all, there is required metadata at the top of the VPAT. There are actually 11 required fields very clearly identified in the instructions as being required. And I picked five that I think are especially critical. One is the name of the product and the version. So we know that what we're looking at is a match for the product that we're gonna be using. The report date is also important. So it was this VPAT two years old or more. If so, does that mean they haven't made any changes in two years to the product or is the VPAT itself out of date? Contact information. And that shouldn't just be a generic help email. It should be a specific person or a specific group that can answer questions about accessibility. Somebody filled out the VPAT. We would love to be able to talk to that person to ask follow up questions. Evaluation methods used. How did they fill this out? How did they evaluate their product? What tools did they use? This helps us to understand whether the VPAT is credible or not. And what standards and guidelines are being reported here. And that should be obvious from the version, the addition of the VPAT that they've chosen. But just reinforces that we are reporting here on WCAG 2.1 level 2A. So a quick guide to reading a VPAT, if you're not an accessibility professional, you can still get a lot by just sort of exploring the VPAT with these questions in mind. First of all, who completed the VPAT? We're seeing more and more VPATs that are filled out by an independent accessibility consultant. And that is preferred because it's a trusted, credible source and presumably independent. Although even that should be scrutinized carefully because how did they test a product? Well, probably the vendor provides them with a few functional workflows to test. They can't test everything for products that are especially complex. And so the results they come up with are gonna be a little bit influenced by the relationship with the vendor. Did they follow instructions? Those required metadata fields, if they didn't do that or if they filled out the form itself incorrectly, then that may suggest that VPAT is either new to them or it's not something that they take seriously. Do they seem to be knowledgeable of accessibility? And this is where, again, just knowing a little something about those three success criteria that I just mentioned, you can really hone in on those and see if their answers make sense given what you now know. Finally, the last two bullets are really what this is all about. After reading the VPAT, do you know more about the accessibility of the product? And after reading the VPAT, what follow-up questions do you have for the vendor? This is just a conversation starter. So that's important to know too and to keep in mind that it's not the absolute truth when they give you a VPAT, we can't say, okay, they claim everything's accessible. So we're good. This is an entry point to having a conversation with them about their product and about the accessibility of their product. And so as you're reading it, keep an eye out for follow-up questions that might arise. So I wanna look at just a few quick examples. Here's one, and these are all real-world examples that have crossed my desk over the last few years. Here's one, you got your criteria, you got your performance level. Most are, well, there's kind of a mix of partially sports and not applicable and supports. What do you think of this VPAT? What jumps out at you as being good, bad, potentially problematic? Feel free to, since we've got a small group, unmute and speak or type into chat, either one is fine. What could you like missing a whole column? Indeed, and Ana, you raise your hands that you're about to say that. Yeah, so the VPAT is a word doc and so people can do whatever they want with it. It's intended to be editable, but in this case, they chopped off the third column. So there are no remarks and explanations. And as I said, that's the most important column and we have no idea what partially supports for non-text content means or for any of those things. We don't have any idea what to make of that and we know nothing more about their accessibility by looking at this. What about VPAT 2? This is another, we've got the really bad ones first. Your audio is not so great. Okay, so yeah, so we have the third column but that information is not even helpful. And basically they just keep on pasting the same comment instead of explaining the actual explanation. Yeah, and I find it interesting that they felt a need to define not applicable. It's like that's the one thing that probably doesn't require any additional explanation but they did define that and didn't say anything about support, support, supports. Yes, Anne, you're muted. Thought I had that undone. I actually have a question about the not applicable. Is that incorrect? I mean, does everything on the list in that first column, does it need to have a conformance level and is not applicable? Is that considered a conformance term? Does there have to be an activity in there like the supports? Yeah, great question. Not applicable is a valid response and ideally there will be some remarks that explain why but this comes up most frequently with things like if you look at 1.2.1 audio only and video only and then there's a whole series there that are related to audio and video. So captions, audio description. If this is a product that has nothing to do with video and doesn't support video or audio, then those will be not applicable for this product. And then in the third column, that's what they would say is that this particular product doesn't support something like that. Is that what they're saying about criterion is not relevant? Is that what they're trying to say or is that just too generic of a description? I think actually in this case, that would be okay for this product that although they use it for so many things. Which is what Anna pointed out. Yeah, and I have a hard time believing that all of those success criteria are not applicable for a product. And they've given me nothing to no remarks and explanations for the items that they call supports. And so there's just not enough information here for me to think this is a credible VPAT. If they have lots of information for why they feel their product supports, the success criteria that get a supports rating, then I would believe they're not applicable or be more likely to believe that. But in this case, I just feel like they probably didn't understand the VPAT. Thanks. So example three, much more information now finally in the third column, just looking at 2.1.1, the success criteria related to keyboard. They say their product partially supports and under marks they say all functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. However, there are minor exceptions. For example, the calendar widget on the manage section is not keyboard operable. However, alternatively, the date can be directly entered into the date field. So just imagine that most things are keyboard accessible, but this is one exception that they've acknowledged. And it is the counter widget is not accessible but there is a workaround. So even a person can't trigger that counter widget, they can still enter a date. So what are your thoughts about this response? Okay, I wanna raise my hand again. I don't know, I'm shooting in the dark. But how does the person who is feeling in the date know what is operable and what is not? So again, I'm trying to learn and understand. So that's what stands out to me is that the calendar widget is not keyboard operable but they can enter a date directly into the field. Is that a confusion? It's a good question. And it's also important to just keep in mind we're just thinking about keyboard accessibility. So it gets bigger than that if you start trying to think about how's the screen reader user gonna interact with us and those kind of questions. So that's all separate, just keyboard only. You're tabbing through, you get to this date field. You discover that you can't get to the calendar widget. There's no way to pop that up without a mouse but you can enter a date field. You can enter the date into this field. And so for me, the takeaway and if I'm just trying to get a sense for whether the vendor knows what they're talking about, they do speak intelligently about this item that they are describing it accurately. This is what this success criteria is all about is being able to do things with keyboard exclusively. I also like that they're being transparent, that they are acknowledging that this widget is problematic and that there's a workaround. All of those things to me are positive. We can get into a debate then about how critical it is that a keyboard user be able to access the calendar widget because that is different than entering a date. They can see the month and they can, they're not sure what date to pick but they know it was on a Friday. There are certain advantages to actually having access to the calendar widget. So it seems like a nice workaround but and that's a bigger question. There might be a dialogue with the vendor to sort of figure that out. Yes, Anya. I had a question. So this is what we're covering here is the interaction between the university, say procurement and the vendor. The VPAT potentially provides really helpful user information. Do we pass any of this on currently to the users? Not necessarily. And the VPAT, we actually do within the accessible technology website where in the very early stages of creating a set of web pages that documents different products. And within that, if there are VPATs available we will be linking to those VPATs. And so that would be one source of information. But the VPAT is not easy reading and I wouldn't expect users to turn to that as their source for understanding the interface. Hopefully, companies that are serious about accessibility will provide public facing documentation of keyboard shortcuts for using this product or instructions for how to use this product with assistive technologies, that sort of thing. And so those same pages will link to that content as well, specifically for users. So the VPAT really... This is what you and I touched on the other day, right? Who's up like a next step could be to actually provide guidance to our users on the products we operate. Right. Got it, thanks. Yeah. Yep, the VPAT really is intended for people making purchasing decisions so they can better understand the limitations of the product. So one more example, this again is focusing on the keyboard success criteria 2.1.1. They say partially supports. They say a rating of partially supports has been given because users can operate all functions in the product using keyboard through standard controls. But there are some limitations and once again, they have two limitations that are specifically identified. The reason that I selected this one is because it also says at the bottom, a roadmap has been identified to remediate both of these known issues. And so how to read a VPAT slide, one of the questions was what follow-up questions do you have when you're interacting with a vendor? And the biggest follow-up question if they've identified accessibility problems should be when are you gonna fix those problems? You've identified, you've got all these problems. They're very specific if it's a good VPAT. What's your status on fixing those or what's your roadmap? And if we're gonna deploy this now and we know that it has risks because you've identified it's got accessibility problems, we need to know when those are gonna be fixed. Maybe we hold off on deploying it until those are fixed or maybe we hold off on signing the contract until those are fixed. So this is where contract negotiation comes in. Identify problems, now what do we do? And that is a perfect handoff to Lynn. And I'll just keep driving if you like, Lynn and you can speak. No, that sounds great. Thank you, Terrell. And to Terrell's prior point also about getting requests from the federal customers about documentation, we've also been getting that for data security as well. And so we're seeing a high trend in that right now in federally funded grants and contracts also. So step three, we've talked about what to look for in the vendor. And I always use an analogy, I tend to lean a lot towards car analogies. And it's a lot, they're giving you VPATs and that's great but without any teeth to it, without anything in the contract, it's pretty much what we call in the procurement world is sales collateral. Someone might tell you this car runs great. It looks good on the outside. I'll give you a sheet of paper telling you all the things we've done. But unless when you drive it off the lot you have some type of warranty that says if it doesn't do those things, then it's on you, then it's as is at that point. And it's on you to fix it. And so that's what we're gonna talk about next is how to partner with the vendor to make sure that they can essentially back up what they're telling you in the VPATs. And so if I could get the next slide, that would be wonderful. And so one of our key things that we do in procurement and I recognize that not everybody has a procurement department depending on where you're from. And I speak to an audience in these presentations because since this is a public presentation not everybody is always from the UW, companies are structured differently. At the University of Washington, we have a procurement department that helps us with contracts. That's my department. But not all companies do that. Sometimes it's a one-stop shop or somebody is a person of all trades that will be doing all of these tasks themselves. And so if you engage with your users as early as possible and start talking about these requirements upfront as part of the negotiation process, that's really key. Because if whoever is negotiating your agreements be that you or somebody else, if they've negotiated everything else and then you come in at the 11th hour and go, hello, I need to get in some accessibility language, they're gonna feel a lot like, you've done a bait and switch on them. And that happens a lot in contract negotiation where if there's multiple layers of review or something wasn't thought out on the front end, getting something in after everybody has negotiation fatigue can be a little difficult. And so whatever your role is and accessibility, make sure that you're involved in the process before that decision is made so that you can set the table on the expectations with the vendor and they don't feel like we're like a chamois commercial. But wait, there's more. And I'm gonna keep putting that, we're dragging out the negotiation and everybody, yes, timeline is impacted. And so if you have other process partners, such as an accessibility team like Terrell or a CIO and they need to be involved in that process or you don't know how to read a VPAT, then that's a good time to get them involved early so that you're not doing that at the very end of the process. And next slide, please. And so how do you do that? And so where does it fit in? How does this work? And so at the university, we embed the policy into our boilerplate terms and our website information. And so every purchase order that goes out to our vendors says this is in conformance with or subject to the terms of UW general terms and conditions and in those terms and conditions, accessibility is embedded in there. However, in custom negotiated contracts or other ones that we review and no involve IT or accessibility items, we put a physical writer in and we'll get to that in a moment. But when we post all of our solicitations out to vendors and our request for proposals or quotations, we put an accessibility clause in there so that when bidders bid on this, they understand that this is what the university's looking for and this is what's gonna be expected if you get this bid. So you should tell us up front whether or not you can comply with this so that when we have all the proposals in front of us, we can pick one that conforms with our accessibility requirements. And the key part of all this is to be enforceable, it must be actually in the documents. Unfortunately, handshake deals and emails and someone saying, yes, we're really good at this, we're accessible, that's not enforceable later. And especially if they change their website or their solution later, if they make modifications to it to make it less accessible, then that can be a problem. I had that happen to a department where we hired a vendor to provide us with videos, they were captioned, they were accessible, everything was great. And then not long before deployment, they changed their solution and they made some changes and they took away all the captioning. And they didn't know, we tried to work with them and get it going and they didn't know when they could fix it and it was a key component for us since it was being rolled out to a lot of students. And so we actually ended up canceling the contract and going with a different vendor because that was a requirement in the contract that they agreed to and they changed and could no longer meet it. And that's a very drastic example. Usually your end goal is to never switch vendors and go through that whole process again if you can avoid it, working with them and having them be responsive is best case scenario and ideal for all parties. But in that particular case, the vendor had no option for us and no resolution. And so on our team, we train everybody about IT riders and accessibility. It's built into our standard core processes and our standard IT riders. And so if there's a vendor that says, well, we might be accessible or we don't understand and we get a lot of departments who say, Lynn, I'm not an accessibility expert and the vendor's telling me they can do X, Y, Z and I'm not sure how to read this VPAT, what do I do? And that's where we bring in Terrell and say, absolutely, we have a partner that can help you. But part of this training that Terrell and I are doing today is also geared towards people who may not have a Terrell and a team like Terrell and Anna and so, or Anne-Marie. And so they might have to say, oh, I need to review the VPAT myself in my organization to make this happen. And so the tools that Terrell gave you will help you vet that accessibility and say, okay, this vendor is mostly accessible. They have one little thing that is not accessible and only two people are using this, that's probably maybe okay, or this is really not accessible at all and we're gonna roll this out to thousands of people, that's kind of a big risk. What happens and I happen to know that some of the people using this need accessibility tools. And so that's where you come in and say, okay, I'm buying this car, I'm buying this product does it need a new headlight which is easily fixable or does it have a long list of repairs and I'm getting ready to drive across country. What are my real risks in buying this thing? And that's part of risk assessment when you're looking at these. And so when you decide to accept accessibility that is less than desirable or less than perfect, you can do that, but it should be somebody who understands those risks that if someone said, Lynn, you were hired at the university yesterday, can you approve this deviation and this risk? And I probably wouldn't even know how to find my desk or who to email at that point. I might not be the right person to be making that choice. So in our organization, we usually have a director or an executive level supervisor make those decisions because the financial impact of the product not being accessible rests with their department and they should know and understand those risks or know who to consult. They might say, well, I'm not an accessibility expert either but I know how to get ahold of Terrell's team. And so, and I know how to get the tools I need to make that decision for my team. And so that's kind of where we coming in the process is making sure that it's official and it's just not a nice to have sales collateral from the actual vendors. So next slide, please. And this is a sample. This isn't our whole writer. We have a two-page writer that we've worked with for Terrell and we update it periodically but we actually embed this in our terms and we physically attach it to all POs and contracts and it actually goes and spells out liability requirements, accessibility requirements and is it negotiable? Absolutely. But those edits need to be reviewed by somebody who understands and is responsible for agreeing to those edits. Sometimes if it's something minor, Lynn, there's a typo or Lynn, we can do this or let's point back to the indemnity in the contract rather than the indemnity here. If you understand indemnity and can connect those two things and you're the responsible party for negotiating which our team is, you can sometimes help with that. If they sometimes make other edits such as commercially reasonable or things like that that impact what the accessibility really means then you might wanna get somebody else involved and talk about that. And normally our team will work with you if you're at the UW will work with you on this and Terrell. We see the term commercially reasonable cost around a lot, not just of accessibility but for a lot of things. And what that means in practice is if it isn't hard it doesn't cost any effort or there's no real definition to commercially reasonable. So for one company, commercially reasonable could mean if it doesn't cost us any money or effort or another company might say, well, minimal effort we'll do it if it's not too hard. And since there's no real standard they could come back and say we don't have to do anything because we don't feel it's commercially reasonable at all. So that basically negates your entire writer and all of those good reviews that you did they put in a little disclaimer that says, if we wanna, and that's kind of what that means. And so you have to watch the edits to the writers like anything it is negotiable but you wanna make sure that you understand what you're agreeing to and what those things actually mean in practice for you. And so that is all I have on my piece and I think probably be a great time to open it up to any questions or comments or anything else we can help with. Thank you, Terrell and thank you for driving. Thank you, Lynn. So what I haven't really been following chat looks like there are a few things maybe those have all been addressed anybody else have questions, comments from your experiences. I'm curious, what is the, how would you rate the level of maturity we have as an institution in this space, Lynn in the procurement area? I would say that we are one of the leaders in the university space in this. We do have, Terrell works a lot more with peer institutions in this space than I do but because we are in R1 and we're so large we are actually a leader rolling this out and one of Terrell's colleagues and of course my Cheryl Bergstahler has written two books on this topic. And so we're very fortunate to have that in-house as well but we have a lot of smaller institutions that ask us for assistance. And when we teach procurement classes and IT specifically is one that a lot of other institutions struggle with because they may not have a whole procurement team or even an IT department or their procurement person one institution that at a convention that I went to they actually were so short staff they were hauling boxes at the loading dock in addition to doing procurement, reconciling pro cards and doing a bunch of other stuff. And so they may not have even remotely have the type of resources that we're fortunate to have. And so they attend some of our classes and say, how do I do this? And how do I get this in here? And so I would say our level of maturity is pretty good, especially because Terrell's taught even I'm late to the game on teaching classes with him the past couple of years but he's been teaching them long before I have. Thank you. I've just been fortunate enough to be included as you know how this is great. How do we get it into our actual process? So it's been a wonderful partnership for us. We'll say, I don't know if you're encountering this Lynn and your conversations with others in the procurement space but I am discovering more and more institutions that have accessibility as an official step in the procurement approval process. So every purchase above a certain dollar threshold has to go through accessibility and accessibility has to sign off on that before it can proceed. And so I don't know how common that is and whether that's maybe smaller institutions as opposed to R1s but I am hearing of more institutions that do have a pretty formal seat at the table. No, that's wonderful. I just got back from an IT conference last week that was not university focused. It was for commercial and there were very few higher eds actually there and there were over I think 4,310 people at the conference and there were a good 300 vendors I believe and some of the vendors did presentations and I think I saw maybe one presentation on accessibility and I did not see any discussion about it in this entire conference which is one of the biggest in the nation. And so, we're very much ahead of the curve and I actually sat next to a person at IBM who is not a small player in the market and they actually looked at me and they said, who's really thinking about accessibility in the market anyway? And I looked at her, I said, we are. So the sales rep at IBM was actually shocked that this was even remotely on our radar and their perception was that this is not an important thing and our perception is drastically different. Samantha, you had your hand up a little earlier. Did you still have a question? I guess I was just hoping, hi everyone, I'm Samantha at the information school and I was wondering what the process is for getting a contract checked before we close out on it with a vendor. When would we loop your team in? Are you gonna say your team is in Terrell's team or my team? Oh, sorry, Terrell's team. Anytime really, anytime somebody has a question about accessibility of a product, feel free to reach out to us and we're happy to entertain that. I do get a lot of referrals from Lynn and so as if it's a purchase that is going through procurement services, then I kinda trust that Lynn knows the optimum time to bring us in and whether our involvement is necessary. But otherwise, if something is being considered or negotiated independently of procurement services, then yeah, feel free. With any questions about accessibility, feel free to reach out to us. Help at uw.edu with something very specifically about digital accessibility in the subject and description. We will get triage to us. Thanks. And with most contractual items, accessibility included, try to get in front of the vendor as soon as possible because sometimes they take a while to review things or they can take a while to negotiate and if you're down to two days before you need to sign the contract, we pretty much don't have a whole lot of leverage at that point or a chance to switch vendors. And we're seeing some last minute brinksmanship in the IT space where vendors will say, oh, you've got two months, great. I'll have my legal team look at it. They'll go dark for six weeks and then two days before it's due, they'll say, oh, no changes, sorry, take it or leave it and then you're left holding the bag and you have to say, okay, now I have this risky thing that I have to take on, which is not good. And I don't have any other. I've been painted into a corner pretty much. And so, as early as possible is good. And if we see a vendor saying, no, I can't do this and you need help assessing the risk then I'll bring in Terrell, absolutely. Or other process partners, we do that as well with privacy and the size though as needed. If it's out in the weeds and beyond our capacity in what we do, then we're always delighted to bring them in. So it's good. All right, well, we are at the top of the hour and I know folks are having to jump off for other meetings and so we can stop now, but appreciate everybody being here. Hopefully it's been informative.