 I'm going to share my screen. And I was in a meeting earlier today and did the cholorama. So I have no idea why I reverted back to black and white. It's a strange technical thing. And I re-voted my computer thinking maybe that would reset things, but that's such luck. So for some reason, this is kind of a retro sort of look and very contemporary content that we're going to be sharing. So I'm Terrell Thompson. I'm the manager of the IT accessibility team with PWIT Accessible Technology Services. And we're going to be talking today about accessibility in procurement. And I have with me here Lynn McGill of procurement services. And I'll let her introduce herself when it's her turn to speak, which actually would be really quickly here. I just want to share a few acronyms that we're going to be using in this presentation. So you're prepared for them because it is kind of acronym soup sometimes when you wade into the accessibility space. But we'll be talking a lot about the W3C, the World Wide Web Consortium. And I'll define each of these in more detail if we get into them. A key piece of the accessibility puzzle are the standards that we're trying to follow, the Web Content Accessibility Guidelines, or WCAG. And there's another W3C specification that plays a key role in, particularly, web applications. And that is called ARIA, Accessible Rich Internet Applications. Again, we'll get into what that means a little bit later. And a big focus of what we're going to be talking about is something that vendors provide in order to document their accessibility, which is a voluntary product accessibility template, or VPAT. And new, actually, this time since the last time I gave this presentation, we're also going to be talking about the HECVAT, or Higher Education Community Vendor Assessment Toolkit, which is a new development just as of the EDUCAUSE conference last week. So with that, I'm going to turn it over to Lynn to take off the conversation. Thank you, Terrell. I am Lynn McGill, Senior Contract Specialist with the University of Washington's Procurement Department. And I handle not all, but the bulk of the IT procurement for the academy side of the university. We have a medical center, and then we have what we call the Academy, which is the education side. And my team and I handle most of that. And so what we talk about is how we partner with the accessibility team and with the departments and how to get your stakeholders to partner with you to procure Accessibility. And so one of the first things we do is solicit accessibility information and one of the things we ask them to do. And so when you're working with a vendor initially, ask them, what is their accessibility? And then validate that, which is what Terrell is going to get to here shortly with the VPAT. OK, I have this information. What do I do with it? And then it's great to have that information. If you don't have those requirements physically in your contracts, then say something changes with the vendor later on, which has happened with some software. They do an update or something like that. You don't really have anything to fall back on if it's no longer accessible. So getting it actually in your contracts is really important to have that be enforceable down the road. And next slide, please. And so partnering with stakeholders. I don't know if you had parents like mine, but they said, if you're not early, you're late. And that's a very good analogy for contracts as well. Starting early is very important because the later you get into the process, the harder it is to make changes, your timeline is impacted. And so engaging your end users as early as possible is really key. What do they need? What is their timeline? Let's start way ahead in case there's discussions, evaluations we need to have. Getting yourself, if you're a contract manager or a project manager, getting involved in the process before the final decision is made. A lot of us have end users that come to us and say, we've talked to five vendors and we like this one. And we want you to sign this. And we need it next week because we need to implement this to start in two weeks. By then, they're not going to want to go back and start reevaluating vendors. And so the earlier the better that you can get them in front of you will help you actually get that accessibility conversation handled before it's too late. And getting a seat at the table when selecting your vendors as well, making sure that you have those conversations and that accessibility is something that's getting considered. And involving your other process partners, if you have them at your organization, we are fortunate to have an accessibility team like Tarrell's team and Anne-Marie. And we have a Chief Information Services Office as well and a Privacy Office. So those are some of the other things we consider in IT. So getting their input as well for things that you might not be an expert about or to help evaluate what's important and what's not. And accessibility is a standard. Incorporating it into your processes can often be the most difficult part. We want to talk about it, but when do we talk about it and where and why? And at the UW, we embed it into our boilerplate terms and website information. So we put it right out there as a standard. That way it doesn't get missed accidentally. We don't have to manually put it in there and think about it. It's there. And if a vendor reads those boilerplate terms and needs to have a conversation with us about that, then we can. But we've got the standard already essentially benchmarked right there. We include standard writers or terms into all of our RFPs, our request for proposals, or any type of solicitation or bidding or contracts regardless of size. $500 million. We want all of those to be accessible. We do standard training for all procurement team members on the terms writers and accessibility to make sure that everybody is doing things the same way and so that there aren't gaps depending on which team member handles things. So that's part of onboarding. And having our accessibility team that vendors prior to there being approved for use, that's something we're implementing more and more. Where if a vendor says, well, I don't know if I can do this or I have these couple of things that are not quite accessible. They can look at it more holistically and with a more experienced eye than our legal team can as far as what is OK and not OK. What's being used? What needs to be fixed? Can the vendor fix it? How many users are there? And then if there's any deviations to that, who can approve those? And with us, it's somebody with executive authority that says, OK, based on the expert advice from accessibility and our IT team. And the number of users are how this is being used. Is this something that's going to be campus-wide, public? Or is it going to be two people using this in two researchers in one department that are just using this one thing? They'll assess that level of risk as far as a risk management procedure. And so that way, it's not some poor person who's been with your company two days going, well, looks OK to me. Let's sign that. And so it should be somebody with appropriate authority to accept that risk on behalf of your organization. And next slide. So when we solicit accessibility information, one of the things that the UW has done is we've baked in procurement policies and standards as a public organization. And we have what's called procurement policy. This is 7.2.15, very official sounding. And this is our standard across the entire university. And this says, the University of Washington bidders and vendors shall be required to demonstrate that information technology provided to the University of Washington conforms to or addresses each of the World Wide Web consortiums WCAG 2.1, level AA success criteria whenever demonstrating such performance is practicable. Vendors may do so by providing a VPAT using VPAT 2.3 or higher. The VPAT templates are available from the IT technology industry, Information Technology Industry Council. There are four different editions of the VPAT based on different accessibility standards. Since IT procured by the University of Washington must meet WCAG 2.1, level AA, the most appropriate edition for our needs is what I can't talk today. The WCAG edition, the INT edition is also acceptable since it involves WCAG 2.1 guidelines. And note it is not sufficient for a bidder or vendor to simply provide a VPAT. And that's very important. That notation right there is that they can't just say, OK, we're accessible. They must take care to do so accurately and fill it out. And if they don't have enough expertise to do that, they should receive help from independent third party. Because since that's in our contracts, they're saying, yes, we can do this. So it's not just a pinky swear that we do that. It's actually in the contract and they're agreeing to do this. And the VPAT templates included detailed instructions and they should be expected to follow those instructions. And so this is it. Go ahead. Sorry, I was muted there. Thank you for that one. It's great to have that context. And particularly, procurement policy 7.2.1.5 is a lot of information here. The bolded parts are what we're going to be focusing on than the rest of this presentation. Looking at what is exactly? What is WCAG 2.1 level today? What does that mean? And there's a lot of information here about the voluntary product accessibility template or VPAT. But let's dig in a little bit deeper and explore that as well. So kind of the overarching goal here. Because the university purchases so many IT products, I think Lynn, last time you shared a number with me was like 43,000 purchases since the start of the fiscal year. So just a few months and we're already purchasing so much technology, it really is impossible for my little team to get involved in all those. And so it is a question of, is this a significant risk? Is it going to impact a huge number of students or employees or visitors? And if so, we definitely want to be involved in helping with that. But otherwise, everybody who makes a purchasing decision and is therefore assuming some risk on behalf of the university, they need to understand at least the basics. And so the rest of this presentation, I really want to focus on just kind of instilling the basics and providing you with enough of an overview so that you can make some intelligent decision or informed decisions about whether a product seems to be accessible or not. So what is WCAG 2.1? Since that's the standard, we need to understand that a little bit. That is Web Contact Accessibility Guidelines again is the acronym. It's an international web accessibility standard published by the World Wide Web Consortium or W3C. So that's the group that kind of owns most of the web standards, so HTML, CSS, all sorts of things related to the web are owned by the W3C and maintained by the W3C. And very early on in the history of that organization and the history of the web, they began working on accessibility because it became known to them, to the W3C, that the web, although it was intended to be this great equalizer, information that everybody's fingertips worldwide, that unprecedented level of access might actually not be the case for certain groups of users. And some people might actually find that the web erects barriers due to inaccessible content. And so that was contrary to the vision of the web. And so they began very early on working on developing these guidelines. And they published the first set, version 1.0, in the late 90s. And then every 10 years since then, there's been an upgrade. So version 2.0 came out in 2008. And 2.1 came out in 2018. And that is the current version, the version that we are obligated to meet via policies, state policy, and just in federal legal cases that have been resolved have all pointed toward WCAG 2.1 or WCAG 2.0, depending on how old the case was. But the 2.x version of WCAG at level 2A is very clear now that that is the bar that we're expecting to meet. So the levels are also important that WCAG is comprised at its deepest level of very specific, I'll call them checkpoints, but things that you must do in order to avoid excluding certain groups of users. So sort of a classic example is alt text on images. We have images, somebody who's unable to see using a screen reader, maybe listening to content or maybe using a Braille device to access content. They can't see an image, obviously, with those devices. And so having alt text is the accessibility solution. That is a level A success criteria. So that's one of the checkpoints. And it's assigned a level that has to do with both its significance because an image is going to be completely inaccessible that has no alt text. And it's ease of implementation. So it actually is really easy to add alt text to images. And so that is a level A. So level A is the highest priority. Level 2A is the second highest. And level 3A are things that either are more difficult or less critical. And so early on when WCAG 2.0 was published with this sort of structure, with all these success criteria and each one identified with a level, then there were lots of questions. What level are we supposed to meet? Do we need to meet all success criteria at all levels? Or is it acceptable just to meet level A? Or maybe level 2A? And that has sorted itself out over the years. It is now, as I mentioned, clear that level 2A is the bar. So we need to meet those 50 success criteria, 30 level A and 20 more level 2A. So probably the easiest way to explain this further is to just give you a few examples. And I'm giving you three examples. And I've chosen these three for a reason because 50 success criteria is a lot to master. If you're not entrenched in accessibility and it's not something that you do for a living, like those of us in Accessible Technology Services, then it's arguably unrealistic for you to master 50 WCAG success criteria. So if you just focus on three, then these can tell a pretty significant story about whether a web application is accessible. And also, I should mention that we're not just talking about web pages, web sites, or even web applications. Even though the W in WCAG is web, it really, these principles apply to anything with the user interface. So if users are intended to interact with it and it's technology, then WCAG applies to it. So the first of the three examples is success criterion 1.3.1 called info and relationships. This is a level A success criterion. And I've chosen this because it is so significant when it comes to accessibility, particularly for screen reader users, that headings sort of form the structure of a document. Anytime you have a visual layout, sort of has different sections of the page. And usually there are headings and subheadings and maybe some subheadings. And that really helps the site of user understand the relationships in all the parts. And those headings need to be coded as headings in order to communicate that structure to people that can't see it. So they're using assistive technology like a screen reader, they can jump from heading to heading to heading, or they can generate an outline that's built from the headings. And that really helps them to understand how all this content is built and what the structure of the page or the application is. So that really is critically important. And also under this category having labels on form fields. So as you're navigating through a form, you need to understand what's being asked of you as you're filling out a form field. And somebody who is using a screen reader again, they can't see the form and they're really dependent on it being coded properly. So labels are explicitly associated with form fields. If they're navigating a data table, then it's important for the columns to be identified as the column headers to be identified as column headers. And if they're row headers, those should be identified as row headers. So all this comes down to the tagging behind the scenes, communicating the info and relationships about all of the stuff that makes up the interface. And this is important in not just in web applications, but in PDFs and Word docs and any sort of digital document format. The second example is WCAG Success Criterion 2.1.1, which is just titled Keyboard at two is a level A. And it says that all functionality of the content is operable through a keyboard interface. So I encourage everybody to take the hashtag no mouse challenge and try your website or any sort of web application that you're maybe you're looking at making purchasing decisions. Try it without a mouse to see if you can use the tab to navigate through the components of the page. And then any other keys that make sense like space or enter to click on something or maybe the arrow keys to move through a menu or maybe escape to close something, those are all sort of standard keys that generally work if it's coded properly. So, and you should always be able to tell where you are. So as you navigate with keyboard alone through a website or web application, there always should be visible indication of where you are within the page. So this is included here because it's super easy to test. Anybody can do this as long as they have a keyboard and the ability to use a keyboard. And they don't need any accessibility checkers. They don't need any assistive technology. So this is something you can ask the vendor to demonstrate on the spot. Show us how you can perform that what you just did with a mouse. Show us how you can do that with a keyboard. So this is included because it's so easy to test. The third example, 4.1.2, this title name, role, and value, and I think this gets a little bit more complex, but to simplify it, I'll just say that this involves the proper use of ARIA. And so to understand that, obviously you're gonna need to know what ARIA is. So what is ARIA? Well, it stands for Accessible Rich Internet Applications and this is another W3C product. So this is a specification they came out with to essentially to sort of fill the gaps where HTML falls short. When you have a rich dynamic interactive web application where the user maybe clicks on something and that results in something else happening on the same page, then often HTML is not up to the task of communicating what just happened in a way that assistive technology users can make sense of it. So ARIA was created to, again, to fill those gaps and to make those interfaces accessible to assistive technologies. So, and it does that by communicating in elements, role, state, and properties. So I'm gonna provide a really simple example of this is a common thing that we see on a lot of websites. And if you're not a coder, I'll explain everything here. I think it's pretty simple even for non-coders to understand, but essentially here we have two elements on a web page. One is a button that says more info. And the other is a div, just a generic container of division that has content inside it. So this section contains more info. So probably that div is hidden by default. And what would happen is the user would tab keyboard user tabs to the button. They press the spacebar to trigger the button and that then reveals the content. The content goes from the hidden to being visible. So a screen reader user, if they can't see any of us so they're just relying on their screen reader to communicate what's going on, they land on the button and it's coded as a button. So they're informed this is a button and they're informed that it's the more info button. So they know, okay, if I want more, I can click this button and so they press their spacebar or enter key, whatever the key would be to trigger that button. And then the content is exposed but they don't know it was exposed. They have no idea that anything just happened. The screen reader tells them nothing. So maybe they click again and this time they hide it without realizing they're hiding it. And maybe they click again and expose it again. But again, there's no feedback that tells them anything is happening. So this shows where HTML really is not up to the challenge of making an interface even as simple as this accessible to screen reader users. So if we add ARIA, just a couple of ARIA attributes, they just plug right into HTML, then that makes this accessible. And my point here is not for you to become an ARIA expert and to know which ARIA attributes to use, but just that ARIA plays an important role in making dynamic interfaces accessible. So, and what this is doing is you've got an ARIA controls attribute which says this button controls this div. So they're connected by the ID of the div matches the value in ARIA controls. And so that explicitly forms that connection. So screen readers know, this button controls this content. And then the state of that content is either expanded or it's collapsed. And that is informed, the assistive technology is informed of the state via the ARIA expanded attribute. So it's false when the content is hidden. And then when the content is invisible, that changes to true. Screen readers notice that it changed to true and they informed the user that something has just appeared. So just two ARIA attributes make this interface accessible. So the reason I mentioned that is because as we started valuing products, then if it is a product that has some dynamic features, which most web applications are, then ARIA is probably gonna play a role. And so if vendors are talking about their claims related to accessibility, then they should be talking about how they didn't mention ARIA in order to make their interface accessible. So again, going back to Lynn's first slide, we first asked for accessibility, right? So we ask a vendor, provide us with documentation that related to the accessibility of your product. And that's asked for very formally. We have language standard RFP boilerplate language and we make that expectation known that they're expected to provide documentation and a standard means by which vendors will often document their accessibility is this form called the voluntary product accessibility template or VPAT. They've been using this for many, many years. It originated with section 508, which is federal law requires the federal government to ensure all of its IT is accessible. And the standards that were created to support section 508 were originally published in 2000, I think it was either 2000 or 2001. So very long ago, the VPAT was created so that federal agencies could get some documentation from vendors as to whether they met section 508. So that was the original purpose of this and it's evolved a little bit over the years. We're now up to VPAT version 2.4, that it's latest version is published in February 2020. And as the slide with all the texts from the procurement policy states that we accept VPAT 2.3 or higher, that's because VPAT 2.3 is the first version that included reporting of WCAG 2.1 success criteria. And so it's important not to get these versions confused because it is a common source of confusion that the version of WCAG 2.1 has nothing to do actually with the version of VPAT 2.3 or 2.4 is just coincidence that they have similar sorts of versions but those version numbers are unrelated to each other. So VPAT 2.3 or higher is what we're expecting because otherwise if we ask how does your product do on WCAG 2.1, then they can't answer that question if they provide an earlier version of VPAT. It's like comparing apples to oranges. So and also that slide with all the texts mentioned that there are four editions of VPAT. And because we are wanting to know whether they comply with WCAG 2.1, then that's the version and that's the addition that we are expecting them to provide or the INT, the international edition which encompasses all of the various accessibility standards. So VPAT essentially looks like this. You've got three columns and this is where, we now get to the second phase going back to lens original slide. They provide us with documentation, their accessibility. Now it's up to you as the person making purchasing decisions to be able to look at that documentation and to make some informed decisions about it. And so probably they're gonna provide a VPAT. And a VPAT consists of three columns. There's the criteria, which if they provided the right one should be WCAG 2.1, level A and two A success criteria. And then there's a conformance level column which is a multiple choice column where they identify how their product performs what level does their product conform to this particular success criterion. And then there's a remarks and explanation column which is intended to be comprehensive. Please explain your answer related to the conformance level. So regardless of what they chose for performance level we want more detail, we want an explanation. So the choices for conformance level are either product supports, partially supports does not support or it's not applicable or they didn't evaluate it. And so generally there's a little bit of a gray area between partially supports and does not support. And that actually is pretty critical that if the product partially supports this criteria it's sort of like the difference between partly Sonya and partly cloudy. Some functionality of the product does not meet the criterion, but it mostly does. So it's mostly Sonya partly cloudy. But if it does not support, then that means most of the product does not meet the criteria. So there are more clouds than sun in this case and it really is important for them to accurately choose their conformance level. But all of that should come out in the remarks and explanations because that's when they get into the negative details to justify whatever they chose as an answer. There's also required metadata at the top of the VPAT. There are 11 required fields in the instructions and it is incredibly common for vendors to skip those even though it clearly states an instruction is that they're required. I think that there are five in particular that are especially critical. The first is the name of the product and the version because you need to know that this documentation does in fact apply to the product that you're purchasing and the version of the product that you're purchasing. If it's many versions old and they have upgraded their product with new features, then that's important. We need to know whether those new features are accessible as well. The report date, similarly, if it's a couple of years old and they've updated the product since then, we need a refresh, we need a newer version of the VPAT than that. Contact information for follow-up questions is critical and often we'll get just sort of an info at email address which is not what we're looking for there. Somebody filled this VPAT out and therefore they are the accessibility expert related to this product in theory and so that's the person that we need to talk to if we have follow-up questions. We wanna know how they filled this out. What evaluation methods did they use? Is it just like with any sort of research, we need to know the methodology in order to understand and interpret the results. And then also, if they're using the right version of VPAT then this should go without saying but we want them to explicitly state what are the applicable standards and guidelines that you're applying here in your measure? So a quick guide to reading VPAT, first of all, who completed it? Was it done by an independent accessibility consultant? That again is preferred but often it's somebody from the organization for the company and if it was somebody from the company then it has somebody from the sales team, from marketing, did they have somebody that has accessibility expertise fill this out? Did they follow the instructions? And if not, then that alone sends a message that either a VPAT's new to them, this is not something they have experienced with or it's not something that they take seriously who's trying to push it through to meet the purchasing requirements. So both of those sort of toss up a yellow flag. Do they seem to be knowledgeable of accessibility? So as you read through their VPAT, particularly now, again, I've just kind of given you an overview of three success criteria that you kind of hone in on. Just look at those now that you know a little bit about them and see how did they answer those and did they answer them with any sort of credibility? After reading the VPAT, do you know more about the accessibility of the product? That is really what this is all about. And after reading the VPAT, what follow up questions do you have for the vendor because this VPAT is never, it shouldn't be taken as the truth. This is not proof of their accessibility. It is just a conversation starter. This is their perspective of how accessible they are, what can you learn from that and what further questions do you have, what do we need to talk about? So I wanna just really quickly go through a few examples, both bad and good. And these are all examples from within the last year to two years, all COVID examples products that I've been involved in review VPATs. And so just kind of give you a sense, they're all current in that the vendor has provided them recently. The first one here, if you think back a couple of slides ago I mentioned there were three columns. This is a vendor that chopped off the third column. So they only provided the conformance level but they didn't provide any remarks or explanations. So we really know nothing based on this. And in fact, there are a couple of items here that where they say partially supports. And so they're acknowledging that there's shortcomings to their product, but we have no idea what the shortcomings are. So obviously we can't make any decisions about this without knowing more about why they chose the levels that they chose. The next example has a remarks and explanations column, but they only put anything in if the conformance level was not applicable. In that case, they said criterion is not relevant to this particular technology. And they said that over and over and over again and arguably that's the only conformance level that doesn't require remarks and explanation because it's self-explanatory. All the others, they need to tell us why they chose supports. And the fact that they chose supports, supports, supports, supports for everything except the things that were not applicable. That too is always a red flag for me because I've never seen a product that is fully look at 2.1 or 2.0 level 2A conformance that they all have some shortcomings. And that's okay as long as that they're transparent about that at college they have some shortcomings and they're working on improving their product. The next example has a couple of success criteria that are kind of unusual if we read the success criteria. The first one is redundant text links shall be provided for each active region of a server side image map. And the second one talks about client side image maps. And these are our old leftover success criteria or checkpoints from that original section 508 standards. So back in 2000, 2001, we were actually seeing server side of client side image maps. Those don't even exist anymore that I have that I'm aware of whenever I see them. So the fact that a vendor provided this BPAT many decades old now as a current BPAT is clear that this is not gonna answer our questions about modern accessibility. Here's an example that is 2.1.1 keyboard. They say all functionality of the content is operable through a keyboard interface without requiring specific timings. However, there are minor exceptions. For example, they give an example of a calendar widget that is not keyboard operable. However, alternatively, the date can be directly entered into the date field. So they claim partially supports because of these exceptions and this particular exception. I really like that they're transparent about the fact that you can't access the calendar widget without a mouse, but also that they have a workaround that it is possible to enter a date directly into the date field without using the pop-up calendar widget. And so for me, this is all very positive that the fact that they're being self-critical for something that really isn't that big of a problem and that has a workaround is a positive for me as I'm reading this, I feel like they've got a credibility. Here's one related to name, role, and value. So this is the checkpoint again related to ARIA. They say that their web application provides the correct name, role state, and other accessibility information for most controls with the following exceptions. They've got a couple of exceptions identified. Dynamic filter results are not announced, screen reader users, and again, calendar widgets come up again, not using appropriate roles. So the question then in my mind just comes down to follow-up questions. How significant are these features? So they've got a couple of problems. They've acknowledged they've got these problems. Can a person still use the product? Can they perform the intended functions if they can't access the dynamic filter results? So that sounds like it's probably pretty significant depending on whether filters play a key role in the functionality of the product. And so all that needs to be sort of weighed, considering the overall functionality of the product and the impact, the issues that they're acknowledging have. So the VPAT is great, but against a conversation starter, we need to know more information to know the significance of these problems as they've identified. Here's one that is a little bit misleading. The reason I have it here is because of the multiple choice question, they've chosen supports for a couple of items related to video. And in the explanations, they say this web app does not contain prerecord and synchronized media. It does not contain video. So really the right answer there is not applicable. And maybe that's an honest mistake, but if somebody is not trained in reading a VPAT and they look at a VPAT that says support, support, support, support, supports, they may come away thinking, wow, this product really is good on accessibility. And so the Senate, again, me thinks that maybe this was chosen on purpose in order to have that subtle psychological impact. So, and then when I see partially supports, again, there's that sort of gray area between partially supports and does not support. They say for partially supports, this web app has proper information, structure and relationship context. So this is the info and relationships checkpoint. But there are some exceptions. And then it lists exceptions. And this actually goes on for many, many pages, the list of exceptions. And that, I would say probably crosses the line into does not support. It's not partially supports when you have dozens of exceptions. Here's another partially supports related to keyboard accessibility. And the main thing I wanted to point out here is the last symptoms in the explanations column that says a roadmap has been identified to remediate both of these known issues. So that's great. It's great that they've acknowledged that they've got these problems related to keyboard accessibility. And I now wanna know, yeah, what are they gonna do? It's always a question. You've acknowledged that you've got problems. What are you doing to fix those problems? I mean, can we expect them to be fixed? And so it seems like they are on that road. They've got a roadmap. They are planning to fix these issues. And so I would wanna see the roadmap. Yeah, can we get access to that? Or at least can you share the content of that? Give us some indication of when these issues are gonna be fixed. Because maybe we wanna hold off on licensing or deploying this product until those are fixed or maybe make our licensing or signing the contract contingent upon them fixing those problems. So there's actually another acronym here that I didn't share in the opening slide. There's a new product out there, a new tool called the Open Product Accessibility Template. So it is the VPAT, but it's an effort to digitize the VPAT. The GSA, the federal government is working just kind of behind the scenes on this. And it is open in that it's up on GitHub and a lot of people are contributing to it. But a few of the benefits are that that data will be self-validating in some ways. And so you can't skip required fields, for example. And you're gonna have to provide some information in the remarks and explanations column. And also it'll be easier if all of this information is digitized, then it'll be easier to make comparisons across products and feed all that information into a database. And so I just, this is an early project. And I really don't know what the timeline is. I just learned of it about a month ago. And so I thought I would share that because it does seem to have some promise. Or maybe it'll lead to better VPATs. So we can hope for that. I also wanna share, this is new, as of the EDUCAUS, EDUCAUS in late October. It was announced that the Higher Education Community Vendor Assessment Tool, or HECBAT, which is already used by over a hundred colleges and universities. And the focus historically has been on security. So this is a way of tapping into whether a product or how a vendor addresses security sort of within their product development life cycle and within their company culture. And so what's new is the accessibility has now been added to the HECBAT. And so there are a number of links here and I'll share the slides afterwards. These will be published up on the archives page, along with the recording of this session. So, and Ann Maria, if you haven't already done so, you can paste that in chat, perhaps that URL. So people will be able to access the slides. But I wanna share the accessibility questions because even though the University of Washington does not formally use the HECBAT, it's not really part of our standard procedures for evaluating products. But the questions that are now included in the HECBAT related accessibility are great questions. So as you're having this conversation with vendors, they're good questions to consider, either asking formally or just sort of informally, ask these as they arise when you're having this follow up conversation. So the questions are, first of all, contact information. Even that's in the VBAT, but it's also in the HECBAT now. We want the name, title, and contact information for the most appropriate accessibility contact for the product under consideration. So a specific person, not a help ad or info at email address. Has a VBAT or a accessibility conformance report, which often those are used synonymously, has one of those been created or updated for the product and version under consideration within the past year. So most of these are just yes-no questions. So and presumably a vendor has to fill them out honestly, otherwise they're committing fraud. So I would think that, yeah, a yes-no question, particularly since there are so many of them, it really does sort of get to the heart of whether a company is paying attention to accessibility. And also as yes-no questions, they're easily scoreable. Has a third party accessibility expert conducted an accessibility audit on the most recent version of your product? Do you have a documented and implemented process for verifying accessibility compliance? Have you adopted a technical or legal accessibility standard of performance for the product in question? Can you provide a current detailed accessibility roadmap with delivery timelines? Do you expect your staff to maintain a current skill set in IT accessibility? Do you have a documented and implemented process for reporting and tracking accessibility issues? Do you have documented processes and procedures for implementing accessibility into your development lifecycle? Can all functions of the application or service be performed using only the keyboard? Does your product rely on activating a special accessibility mode or light version or accessing an alternative interface for accessibility purposes? Do you have documentation to support the accessibility features of your product? So a number of institutions were involved in coming up with these questions through EDUCAUSE and this is the end result. And I think these are really great, great questions. Again, that could be part of our conversation as well. So with that, we've got just a few minutes left and I'm happy to open it up to any questions that you might have or answers if anybody knows why I'm black and white because of EDUCAUSE. If they have any questions that they think of after this, how would they get a hold of this, Carol? That's a good question. We can paste our email addresses in chat, perhaps. Put mine in there. There's mine. I have a question for you, Lynn, actually. One of your earlier slides, you mentioned that deviations from the, I think you're a friend of the IT accessibility rider that sometimes vendors will sort of ready that and will agree to this, but only under our conditions and here's our alternative version. And that often questions arise out of that. Who has the authority to decide whether that's okay or not? Or if they say, we're not gonna sign that, then who has the authority to say we can still do business with them? And you mentioned that it needed to be someone with executive authority. Who has executive authority? Is that defined in any sort of formal way? Not really. The Privacy Office kind of outlined it on their website, but in general, at the UW, that is mostly a director or EVP level manager and some departments don't have that type of title. Each department is structured a little differently depending on what they do. And so normally it's Dean, Director, EVP or above. We get a lot of questions about that because they're like, well, I enter these in and I'm the administrator, can I approve it? And if they're usually not the person responsible for risk and fiscal responsibility for their department and so they want it to be somebody who has that level of authority to commit the UW to that type of thing. Excellent. Okay, well, I thank you all for joining us today. Hopefully you got a little something out of it and can make some informed decisions if you're responsible for purchasing or if you have influence over others in your units who are responsible for purchasing, then it'd be great to consider accessibility, certainly. And we're happy, Lynn and I are both happy to help in terms of questions you're asked. Yes, absolutely. Contact me anytime. And if I don't know the answer, I'll ask Terrell and we will be delighted to help you navigate this. All right, well, enjoy the rest of your afternoon, everyone. Thank you. Bye-bye.