 website about partnering with procurement and some tricks for doing that and that is a little more comprehensive than we'll be diving into today and so I encourage you to go there when you're procuring IT and check out some ideas and a lot of the great information they have on doing that. High level, some of the most important things to do when you're thinking about buying IT in general is first off to solicit accessibility information from your vendor and you know what can they do what do they currently have what are their current capabilities and then second to validate that information that's received and if you need help with that that's part of what the accessibility team does and has information on on their website as well and then including accessibility assurances in contracts while it's awesome to you solicit and validate their accessibility as we all kind of know in a contract itself what's the requirements that are actually in the contract are the best part and that's what's going to actually put some teeth into it because if what the vendor has could possibly change tomorrow and so if the accessibility assurances are not physically in the contract and something changes then you have no recourse it's a lot like if you hired someone to paint your office and you said okay I would like the walls white and the contract said we're going to paint white walls and that's great and if they didn't paint those walls white say you came in and those walls were red and you really didn't want red walls in your office and you could point to that contract and go that's not the color we agreed upon that's not what we talked about whereas if your contract didn't say that at all and it just said paint and they painted it any old color they wanted then you would have no recourse to come back to that contractor and go wow we didn't talk about your red walls were not at all what we talked about you know you need to change that at your expense because that's not what we agreed upon so having it actually in the contract makes us have some recourse and it also has accountability for the vendor for what they say they're going to do and what they can do otherwise it's more of a handshake informal type of deal where that's nice but you can't really do anything about it if it doesn't happen next slide please and partnering with stakeholders is really key and that's what our team does most of the people on this call and viewing right now our stakeholders we consider those are internal and external partners and doing that early is best if you're not early you're late because if you don't start at the beginning then you're kind of scrambling at the end trying to get things done engaging people as early as possible as key and getting involved in the process from a procurement standpoint before a final decision is made because you know like today is a great example it's biennium close and you know if someone says oh we want to hire this vendor and this needs to be signed today we have a deadline in two hours can you please do that our chances of getting accessibility in and having that conversation and being successful is pretty low at that point because we're under a deadline either the solution might get unplugged might not get renewed someone's budget might expire and then we don't have that we've lost all of those opportunities it's kind of like shopping for a car when your current car is broken down you don't have a lot of leverage you need a car you have to get places and so your options are dramatically decreased and you're negotiating power you're pretty much stuck and so getting a seat at the table when selecting vendors is really good tarot and I recently did that we had a department looking at an enterprise solution and tarot was able to talk to them in the early in the selection process to say you know this is going to be a big solution what about accessibility because this is going to have wide visibility for all of our campus and high exposure as well and this is important even on non-high exposure items but being able to you know from a procurement and an accessibility standpoint making sure that they're involved so that if the vendor has questions and doesn't understand what we're asking for on the front end that we can assist with that and facilitate that on the front end and then involving our other process partners besides accessibility and keeping that holistic view of the process is good as well because we also have our chief information services office also called the SISOs office and privacy as well and so there's a lot of pieces that are involved when we start thinking about buying specifically IT solutions and next slide please and accessibility as a standard when you're incorporating it into your processes where does it fit in how do we do this and so what we do at the University of Washington is we have general what we call general terms and conditions that we attach to all of our orders and those are the accessibility language is an link to our policies is embedded into our boilerplate terms and conditions and our website information and so anything that we send out to vendors as a standard already has that built in so it's not manual it's not dependent on memory or process or an afterthought it's basically this is our baseline standard that we expect from all vendors and we include the writers and terms in all of our RFPs that we do and solicitations regardless of size and so we don't you know we don't have any type of parameters say oh if it's over $10,000 or oh if it's more than 10 users accessibility is important regardless of the size of the contract regardless of dollar value and so that's standard for everything that we do it's basically policy we do standard training for all of our procurement team members on all of our writers and accessibility since we're essentially the last stop in checking everything and making sure it's correct all of our team receives standard training to make sure that all of these things happen and then once a vendor is selected if there are any concerns or questions with the vendor or they're struggling with accessibility or requirements we partner with our accessibility team to vet those vendors prior to them being approved for use and Terrell and his team are really instrumental for us in answering vendor questions being able to ask the right questions and evaluating them to ensure that what they're telling us is correct and if there are any gaps in either their VPAT or our understanding in closing those gaps and making sure everybody understands and then if there's any deviations you know say there's only one vendor in the market which is always an unfortunate situation that and we have to use that vendor and there's no other choice that somebody with executive authority is reviewing that and understanding what you're agreeing to oftentimes because their department is actually the ones who are going to take on that risk in the event something happens or there is an accessibility issue that gets escalated you know to the legal level or otherwise and so somebody you know at a director or EVP level should be looking at that since they are also the sponsors of accessibility at the university as well and so that shouldn't be somebody you know I've been with the university for two days someone hired me to do data entry for PO's and sure I'll approve that this vendor can't be accessible yeah it doesn't that's not really equitable or appropriate for someone to make those type of decisions and so those deviations really should be the person with the ethical and fiscal responsibility at the university and this next slide we're going to turn it over to Terrell and he's going to start talking about the rest of the accessibility pieces so thank you Terrell. Great thanks Lynn so the the rest of this presentation it actually is an on-core presentation this is something that I gave at Tech Connect about a month ago or so and then Lynn and I gave this entire presentation to a group of city and county representatives last week but what we found is that it we could eat very easily use a lot more time than we had in those venues and so we booked this as a two-hour presentation but probably it's going to be closer to one hour but we do have some room at full hour if we need it to go over and to have some discussion and so forth and we also have a number of examples we want to look at at the end so the kind of the purpose of this presentation and the reason that it came about is because now that we do have IT accessibility and an IT accessibility writer that is part of the standard UW terms and conditions more and more procurement is including accessibility which is great so that first step in the Lynn's first slide that listed the three steps the first step was to solicit accessibility information that actually is happening if IT is being procured through procurement services then that always happens that the bidders for solicitation are asked about accessibility so the next piece then step number two is verifying the information that they provide and as Lynn has said my team when we are I should say a little bit more about my team I guess we are accessible technology services so we're a small department within UW IT and I supervise a team of four full-time employees and then there are a couple of other people that dedicate a portion of their position to the work that we do but we're a pretty small group and if you think about all of the IT that's purchased through the university it's impossible for our little team to be involved in all of those purchases and to to provide the accessibility consultation that we do so when we do get involved we tend to we evaluate products we evaluate VPATs which we're going to learn about today and we have conversations with the service owner or manager the people that are making decisions about what to what to purchase and we have conversations with the vendor and so we get involved at a very deep level but we can only do that you know with really high risk high exposure purchases so that leaves you know probably Lynn could probably give you a number but thousands I'll say of IT purchases that you know sort of don't get subject to that level of scrutiny but still put the university at risk if they are inaccessible and there are you know groups of users who are unable to use those technologies so so the goal of this presentation then is to educate everyone um at least we've got 18 people here today but we're recording this session so to be available and I encourage you to spread the word but everybody who makes a purchasing decision needs to know at least a little bit about how to evaluate the responses that vendors come back with when we ask is your product accessible so we're going to talk mostly about that step too today of evaluating the responses received from vendors and trying to get some sense of whether a product is accessible so as we're talking about these things we are going to use the acronyms that are shown on this slide the w3c that's the worldwide web consortium the organization that owns many of the web standards html css as well as the web content accessibility guidelines which is the second bullet um abbreviated WCAG um some sometimes pronounced a little differently than that but that's how i pronounce it and those are the standard for accessibility and we'll talk more about those at a considerable length also the w3c owns the aria specification that stands for accessible rich internet applications and we'll talk about that in depth as well and finally we're um the kind of the the focus of a lot of what we're talking about is the voluntary product accessibility template or vpat which is the tool that vendors use in order to communicate how accessible their product is so when you with step one in that three-step process ask for accessibility information typically when you do that a vendor if if they know anything at all about accessibility their response is going to be a vpat that they have already prepared in many cases smaller vendors are not familiar with us and so it may be new to them um but that ultimately is what they provide because that's what we ask for that's part of the um the terms and conditions we actually specify that a vpat is the way to communicate whether your product is accessible or not so this is actually a quote from uda procurement policy 7.2.15 um and it also is um included on that page that was linked from the lens first slide uh uw.edu slash accessibility slash procurement um this is the actual language that's included in the policy and that is University of Washington bidders and vendors shall be required to demonstrate the information technology provided to the University of Washington conforms to or addresses each of the w3c WCAG 2.1 level 2a success criteria wherever demonstrating such performance is practical vendors may do so by providing a vpat using vpat 2.3 or higher and then it goes on to talk more about some specifics related to the vpat so we're going to explore all of this um on future slides but essentially this is just sort of laying it out there it's part of the policy that we need to meet wCAG 2.1 level 2a that is our standard for it and the means by which we expect vendors to document that is with a vpat specifically using vpat 2.3 or higher and the relevance of that i'll talk about in a moment so let's define some of these terms wCAG 2.1 uh you already know now that wCAG is web content accessibility guidelines 2.1 is the most recent version this is an international web accessibility standard and it's been around actually for a very long time it's a new a new thing the um the web was invented by tim burners lee in the early 1990s and soon thereafter he formed the worldwide web consortium the w3c and soon after that organization was formed they became aware of the fact that the web could um erect barriers for people and this was not the vision at all they they had intended for the web to be the great equalizer that provided information that it's you know everyone could have information at the fingertips which um you know was unlike anything that had ever happened before and the fact that this could actually shut people out and could cause accessibility problems was not at all consistent with their vision so very early on in after the organization was formed they formed a subgroup called the this is another acronym that's not included in my list but the wai the web accessibility initiative which then began working on the web content accessibility guidelines so they published version one in 1998 and then every 10 years after that they have they've released an upgrade so it's a long process involves a lot of stakeholders and a lot of a lot of discussion a lot of vetting of the ideas that are generated from those discussions a lot of research and ultimately they went from 1.0 to 2.0 by 2008 and then I incremental upgraded to 2.1 in 2018 and that's where we stand today 2018 the version that was released at least a few years ago is the current version version 2.1 and within that there are there are broad concepts and within those concepts there are guidelines and within those guidelines there are success criteria so the the lowest level is success criteria which are sort of a checklist of the details of how you make it accessible and I'll say it because even though the w in WCAG is web they actually were written to be more generic particularly in 2.0 and 2.1 they they intentionally were trying to cover pretty much anything with the user interface and so a lot of the issues that are identified in the success criteria are not just web issues they're software issues they're also applicable to anything anything with a screen you know information kiosk um if it has a user interface then some success criteria within WCAG apply to it so each of the success criteria and there again this is where the details lie and there are 78 success criteria so quite quite a few things to know about um each one of those is assigned a level and level a is the highest level these are the highest priority the most critical things that are going going to absolutely affect users and block them from from having access if these success criteria are not um not addressed um they there also is some consideration for difficulty so as they were coming up with the various levels um the they were assigned based both on severity and difficulty so you you have some things that drop to a lower level not because they're unimportant because but because they're more difficult to implement level 2a are kind of the mid level success criteria and then level 3a are either less critical or more difficult so um early on when WCAG particularly WCAG 2 when it was released with this um level a 2 and 3a um sort of system for for tagging success criteria there were a lot of questions about you know how accessible is accessible enough you know are we supposed to just meet level a or level 2a or or all 78 success criteria there are a lot of open questions about that and um since that was 2008 when 2.0 came out you know we've had a lot of years to sort this out and there have been a lot of legal complaints including legal complaints against higher education and um that has all both within higher education and without all signs indicate that level a and 2a are the expected level that that we will meet this comes out again and again and again in settlements and resolutions and it has found its way into policy and so it's become very clear now that WCAG 2.1 level 2a is the benchmark that's what we need to strive for if we also meet level 3a success criteria that's great but what we're going to be held accountable for are the level level a and level 2a success criteria so to give you a sense of what um what these are exactly um we need to look at some some specifics and 78 may seem daunting um and my goal here is to simplify so um anybody who's making purchasing decisions again needs to be able to evaluate a product at some level for accessibility and it's unreasonable for for each of those people to become an expert at the level of understanding all 78 WCAG 2.1 success criteria um it's just not going to happen so I think there are three that are particularly important um within the context of reviewing VPATs and so so let's focus today on just those three the first is uh 1.3.1 that is info and relationships and that is a level a success criteria so the highest level and this is important because it encompasses so much that is so critical when we're talking about accessibility that um headings for example need to be coded as headings so you got big bold text that is the main heading of a of a page that needs to be coded as an h1 and secondary headings subheadings within that need to be h2 if there's a deeper level of heading so you get subheadings new sections within the the level two heading sections and those would be h3 and so the idea with headings is they form an outline of the content so that falls under this particular success criteria as does all these other things related to semantics as we often say in in the web development world that you use tags that specifically state what this thing is and what its relationship is to all the other parts so form fields is another example where you've got labels for form fields and a cited user can see that relationship because of proximity but um having it properly tagged ensures that people who can't see and are using a screen reader to access content either audibly or using braille they get those same relationships so the label is actually attached to the form field that all happens behind the scenes in the code now same thing with accessible table markup if you've got a really big table lots of rows and columns then a person who has no eyesight they're reading that with a screen reader linearly going across a row and then down to the next row and then down to the next row that can be really daunting to try and figure out where you are but if the table is marked up appropriately and you've got columns that are explicitly identified as columns then or as table headers column headers or row headers then you know that helps the screen reader user to stay connected with all the parts and to understand exactly where they are at all times within that table so the all those sorts of things headings labels on form fields accessible table markup that's all you know using the the the tagging environment applies to websites it applies to pdf documents it applies to word documents using that structure that semantic tagging in a way that is accessible that all falls under info and relationships so that's why that's so critical it arguably is the most important accessibility issue the second success criteria I want to focus on is accessibility by keyboard this also is a level way so it too is super critical but I've included this one because it's so easy to understand and so easy to measure it basically means all functionality is operable through a keyboard interface so not using a mouse so if you've got something for example a common example is a drop down menu we've got a navigation menu on a website and you hover over a top level menu item with a mouse a sub menu appears then that is you're perhaps dependent on that mouse hover so how does it work for somebody who's using a keyboard can that keyboard user tab to the sub menu or can tab to the menu and can they trigger the display of the sub menu and then can they navigate through the sub menu and access all of its parts so anything that a mouse user has access to a keyboard user should have access to as well because not everybody can use a mouse there of course we've talked about screen reader users people who are using a non-visual interface they are not going to be mouse users typically but you also have people who physically are unable to use a mouse and therefore they may be using some other sort of assistive technology or they may just be using the keyboard pressing tab to navigate through an application and other keys as makes sense maybe enter or space to click a button maybe the arrow keys to move through something up or down or a left or right maybe escape to close something that pops up those are all sorts of keys that are often supported within an accessible interface so doesn't require any assistive technology doesn't require any accessibility checker tools or anything like that to test for keyboard accessibility and so that that is why this is here the third success criteria is name role and value this is 4.1.2 this 2 is a level a issue and that basically means when you have more than just a digital document but you have a web application where you have things changing dynamically on the screen in response to user behavior then that calls for aria and you know other other techniques and technologies but aria is a specification from the w3c that makes accessibility possible when you have a dynamic application like that and so since so many of the the tools that we are purchasing are web-based applications and do these days have a lot of interactivity that happens on the page in response to user behavior aria is invariably a necessary ingredient to making those applications accessible so it's really important to at least understand what aria is aria is complex so it's not it's not reasonable to under to expect anybody making a purchasing decision to be an aria expert there are few aria experts but it's important to understand what it is and what what function it plays in the overall scheme of things so i actually want to spend a little more time to just to provide that a basic background of what aria is it again stands for accessible rich internet applications it is a w3c specification so it is markup that gets added to html to improve accessibility for assistive technology users so where html can do the trick then it's good enough you don't need aria but there are places where html does not adequately communicate what's happening in in an interactive application and therefore aria needs to be added in order to establish those communications so let's look at an example and i apologize if any of you are not coders and that this is a really simple html example so hopefully it'll be clear but essentially we have two html elements here one is a button and one is a div and the div contains some content that in this case just says this section contains more info it has an id so what happens is when somebody clicks on the button which says more info somebody clicks on that button then that changes the div so that imagine that it is hidden by default they click more info that div then becomes visible so in response to clicking on the button something has changed on the web page so this is a very simple and very common sort of interface element in on web pages and web applications hiding things by default and then exposing them when a user clicks on something um but it's not accessible if a screen reader user who can't can't see the page um they land on the more info button and it says button more info they know that's a button they know that they click on it something's going to happen but then they click on it which they would do by pressing the space bar or the maybe the enter key and and then this div appears it becomes visible but they have no idea that it just became visible they have no idea what just happened or where um it's just silence so they click on the button nothing happened they click on the button again again nothing happens so they're they're confused and they're lost the only way to make that accessible is with aria and in this case it's just two aria attributes that get added to the html one of those is aria controls it's aria dash controls equals and then the id of the section that is being controlled by that button so you're establishing an explicit relationship between the button and that section of content the other is aria dash expanded which is either true or false so it's true if the content is visible that content is expanded or it's false if the content is hidden and then that just gets changed with javascript when somebody clicks the button then the value of aria expanded changes and the screen reader then passes that on to the user to let them know the content has changed or that the the item has has expanded or it has collapsed and then through aria controls the screen reader it's not super well supported by assistive technology but jaws the most popular screen reader does provide a means to jump directly to the controlled content so once it says expanded they can jump right to that that content that has just appeared so so that's a you know a simple example just to give you an idea again you don't need to memorize aria attributes aria controls are expanded if you're a web developer that's all good stuff to know but as somebody making a purchasing decision you just have to know that aria is important for any sort of dynamic web application so you've got three success criteria under your belt now and that leads us then to evaluating a product for accessibility so vendor has been asked to provide some documentation of their accessibility they provide us with a voluntary product accessibility template or a VPAT and this is a standard means by which it vendors can provide documentation on whether and how they meet accessibility standards it's been around for a long time and there are various versions of this and they originally were built based on old section 508 of the rehab act standards these this was an accessibility a law that required still does require federal agencies to ensure that their it is accessible but the original set of accessibility standards for section 508 were published around 2000 and are very old and are not WCAG 2.1 so we are required to meet WCAG 2.1 level 2a and if they provide us with a VPAT based on old section 508 standards that's not going to answer our question about how their accessibility how they do on accessibility as measured by WCAG 2.1 so so they need to provide a reasonably current VPAT that addresses WCAG 2.1 conformance and the the earliest version to do that was VPAT 2.3 so it needs to be at least based on 2.3 the latest version is VPAT 2.4 which has some enhancements over 2.3 they're also within the various versions there are multiple additions and this should be hopefully clear if they're they're trying to document that they how well they meet WCAG 2.1 then they will fill out the WCAG 2.1 addition not the section 508 addition not the European Union addition they could fill out the international addition which encompasses all of those standards including WCAG 2.1 but ultimately what we need to know is how well they meet WCAG 2.1 did have a question in the chat a good one from Jeremy Thompson asking if it would be appropriate to include VPAT information what are what it is and what standards are required under our corporate social responsibility section for suppliers looking to do business with the UW and basically what Jeremy's asking is the procurement team my team has corporate social responsibility section on our website for suppliers and would it be a good idea to put our request of VPAT information there and I think that's a great suggestion and something we could probably talk about offline excellent thanks for bringing that up Jeremy and thanks Lynn for for being the person who can make that happen right at least get the conversation started yes I'm I'll talk to our content owners there as well and see if we can get a consensus on that that would be great cool all right are there any other questions actually right now before we get into looking specifically at the VPAT that's what's going to happen next is we're going to do a deeper dive into the VPAT form not seeing any in chat right now but if anybody has any feel free to post them and oh we have one um has Terrell's team looked at providing accessibility review as a service um we sort of and we do that informally as a service not as a formal service but this is a large part of what we do um but there we do sort of have to consider um the fact that we are maxed out and so there's kind of an informal process by which you know we take into account the the level of risk and so um typically we review products when it reaches a level where you know this is going to affect a lot of people or potentially it's going to affect a lot of people students faculty staff visitors um the more of an impact it's going to have then the more likely it is that we'll take it on but I want to be clear that I wasn't expecting you to do it for free and that it might be a capacity building service in the sense that if you charged for it then you would have more capacity to do it right yeah there definitely are conversations about that but we don't have not offering that as a formal service at this point okay any other questions before we move on all right if not well this is a blank VPAT this is a 2.3 WCAG edition and we've got three columns so there's a criteria column a conformance level column and a remarks and explanations column and the criteria column consists of WCAG 2.1 success criteria so looking down through the list here we see the ones that we've talked about 1.3.1 info and relationships 2.1.1 keyboard and this screenshot doesn't go far enough to include the the one about ARIA but you can kind of see what some of the others are as well as you look through that what how this is supposed to be filled out is you've got one row for each WCAG success criterion the conformance level column is a multiple choice column and so and this is clearly spelled out in the instructions that the expected answers there are either it supports so the product supports the success criterion it partially supports it which means some of the functionality the product does not meet the criterion but maybe overall it does does not support means the majority of the product functionality does not meet the criterion or it might be not applicable or it might not be evaluated it's always great to say I don't know if you truly don't know and a lot of vendors try to try to sort of fudge through this and fill it out without really knowing and you know we're going to look at several examples that sort of help us to judge how competent a a vendor has been in filling out this form also that third column is arguably the most critical that this is where we learn the details of exactly how their product supports or does not support or partially supports the success criterion so that is there to provide detail and in the end we should have enough information to make an informed decision about this this product's accessibility and the amount of risk we're going to be taking on if there are certain groups of people who can't use it there's also required metadata at the top of the form and again the instructions are very clear they actually say in instructions there are 11 required fields there are five of those in particular that I think are the most critical for our purposes and those are the name of the product and the version number we want to know which version they're amazing this report on we want to know the date of the report and we want to contact information for follow-up questions and that's not just a generic help email address which sometimes vendors will provide in that that form field but we want somebody specific who can answer accessibility questions and somebody filled out this form and so that's the person who should be identified in in that form field also evaluation methods used what techniques or what methods did you use in order to come up with the answers that you provided and what are the applicable standards or guidelines and that should be if they're using the WCAG 2.1 VPAT then that is the applicable standards and so that should be self-explanatory but it is important to explicitly state that so we have a good question in the chat right now okay is a VPAT similar to a personal data processing agreement in that once a vendor agrees to a VPAT it is only good for that specific purchase with that specific department or can it be used with another department if they use the same vendor and that sounds like a question for you Lynn well I would say that kind of depends on how we word the VPAT language in the contract I would say that if you know the departments are all agreeing to if they're all buying the same product the be basically the product in the VPAT will be the same for all of the departments but the accessibility standards they agree to in the contract are individual for each contract and are negotiated in the contract and so if one department says we agree that whatever your VPAT says looks good that contract language doesn't transfer over to another department they could use that same contract language if they wanted to and they could point to the same VPAT if they wanted to but I think it's probably not a blanket statement that will apply across departments as to the level of accessibility they want to agree to and each of their agreements. It seems like and I'm a procurement outsider Lynn's a procurement insider but it seems like from my perspective there is a lot of sort of siloed purchasing that happens and so the same product licensed by a number of different groups within the university a lot of times and the process is different for all of them and I can think of one case in particular where it was the same product or the same service and the same VPAT but different decisions reached as to what to do with that information and so one group decided this is too big of a risk and we're not going to we're not going to proceed any further because they can't address their accessibility problems and the second group decided they're willing to take on that risk it wasn't that that big of a concern to them so ideally I think we would be on the same page you know everybody you know it would be more sort of centralized and and you know if a company cannot demonstrate accessibility and cannot commit to improving their accessibility then that should be you know a stance that we as a university take that you know our policy is everything has to be accessible and therefore we can't proceed to do business you know with a company that's going to put us at risk but when you got you know the right hand saying no and the left hand saying yes then that that sort of sends mixed messages to the vendor that's my perspective as a procurement outsider I don't know if you have anything to add to that one yes I don't want to hijack your part of the presentation with procurement stuff but what can happen with some vendors is that you know a lot of them will give you their standard boilerplate contract and Jeremy was in procurement for a long long time much longer than I've been in so he knows too and so they'll give you their standard form and it'll have nothing in it whatsoever about accessibility and so a department will do the right thing and they'll go okay procurement take a look and we'll say oh you know we need to have accessibility commitments from them and let's talk about liability and all the other good procurement stuff and we'll get them to negotiate that and then days months weeks years later they'll go to another department and they'll say here's our standard boilerplate and the other department will either perhaps go rogue which is not recommended or they'll say oh you know we need this you know it's buy and close we need this in one hour we can't be bothered with any of that we're going to waive it all and so if they do that what the other department all that good stuff the other department got into for their contract for accessibility will not apply to the other department and it will not transfer over and so if the vendor has accessibility issues with department A that did the right thing then we can actually have we have recourse to have that vendor remediate their accessibility and fix it and not be responsible for that ourselves whereas department B does not have that recourse and if the vendor does not have anything accessible they have no requirements whatsoever and so essentially each new contract is a brand new day with accessibility language unless we use a master contract that procurement has negotiated but individual department contracts currently not so anyway thank you terrell welcome and i saw as you were explaining that i saw the number uptick on the chat was that a follow-up question or yes jeremy said he appreciates the clarification and it would help if there were a means to track vendors who have already agreed to one so it's possible to have a head start negotiations if another department uses the same vendor and it would i know some departments are looking at tracking licenses and other items and that's another reason why it's often good to go through procurement as soon as possible because what we can do for you is in the example i gave if the vendor is giving us pushback on terms we can say well you know you agree to it with department a and that's the least we're going to take you know we already have set a standard for terms and conditions and we know it's possible so you know we want at least that level of protection in any other contract we sign with you so we can at least if we can't do anything else we can at least try to standardize it and get to the right person who can do that and currently that's you know sort of on us and our records to do that but as Jeremy indicated it would be very nice to have some type of database for a lot of these terms as well come on financial transformation so yep yep i second that okay so um so let's look look a little closer at this vpat then we've got three columns um and we've got required metadata and so we have a general idea of how you have this this structure and how it is supposed to be filled out um and so a quick guide to reading a vpat um you could ultimately um you know look at it in depth and really try to understand the inner workings of this product and get a better sense of how accessible it is and what the problems are and that ultimately is what should happen but often you can learn a lot just by following some really quick steps and you don't have to do dig any deeper because you learn so much just from these quick steps um first of all did they include all required metadata so again there are 11 required fields five required fields on my list did they did they provide all that if they didn't then that's kind of telling you know perhaps just in their ability to follow instructions but I think it also gives us a clue as to whether they're familiar with this form or not if they're cutting corners and not not filling it out properly not providing all the required information then that in and of itself um since you know a a uh an implied message about their commended accessibility I think so related to that did they fill the form out properly um again conformance level is a multiple choice question if they entered something else in that column they don't understand um the how the form works and uh finally this is where a lot of vendors fall short their remarks and explanation column is key to us understanding the limitations of the product and so it needs to be sufficiently detailed so we can make an informed decision and if they provide very little detail in that column um and we still are left with lots of questions then um that's not it's not correctly filled out um that's uh it really is impossible for a single form to tell us everything we need to know about a product and so this is a conversation starter a VPAT is not the answer to whether a product is accessible it is um the start of a conversation that you can have with the vendor so part of what we want to explore here as we look at sample VPATs you know what what can we learn from these VPATs and what follow-up questions emerge from what we see here things that we need to know more more information about so the third step then is to look a little closer um at just a few specific success criteria so just to simplify things you can hone in on these three success criteria that we have talked about because you know if you have now a basic understanding of those three then you can see how they responded to those three and see if their responses make sense and as you're doing that questions to ask yourself are first of all who completed this VPAT um sometimes vendors will have an independent accessibility consultant do that for them and that that is preferred because they even though they're getting paid they they are independent they do um presumably have no bias and they're going to get us give us an honest evaluation um did they follow the instructions again that um that does communicate something about their commitment if they if they just sort of blaze through it and didn't pay attention to the details um do they seem to be knowledgeable of accessibility or are their answers to the prompts a little off like they don't really seem to make sense as you understand um the success criteria and ultimately 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 so some example questions that you might ask not is your product accessible um that is too generic and it's a yes no question and and so probably if you're talking to sales they're going to say yes and then they're going to hope somebody can back them up with actual information um but if we ask a there are better questions to ask um that can get better answers for example in your VPAT you said this related to 1.3.1 info and relationships could you please elaborate on that what are some specific examples of how your product meets the success criteria um also getting beyond just the product and this is really important also and looking at the company because if they if they've just gone through and they have patched their accessibility problems for this one product but it really isn't ingrained in their culture and it's not going to be part of their the product life cycle you know as it goes back around again um then you know we're going to be facing this problem again of inaccessible new products coming out of this company so we want a company that understands accessibility is committed to it and we know that as we continue to do business with them over time it's going to be a productive and positive relationship with accessible products and services as as a deliverable so to get into that these are more sort of human questions not technical questions and not requiring accessibility expertise but just tell us how your company addresses the need for accessibility throughout the product life cycle and what is your methodology for testing your products for accessibility and who does that testing which tools and assistive technologies do you use what sort of training do your designers engineers and quality assurance personnel receive on accessibility and i'll tell you from from experience there are some companies who can answer these questions they sound like really hard questions like we're trying to stump the vendor but um there are some that could elaborate extensively on all of these we're actually using right now we're using zoom and so that's a good example um where they could they could go into great depth about yeah all of these questions and they they have a committed accessibility team which actually includes quite a few udub grads who have worked three people who have gone on from being students on our team have gone on to work for zoom as part of their accessibility efforts um but um and that's there are many other examples too of vendors who understand accessibility and have integrated it into their culture um but there are also a lot of companies that um are not not so mature when it comes to accessibility um and it's pretty easy to to spot that so here's here's an example we have six examples that will um we'll have a look at here um the first is a two-column vpat and we know that this is supposed to be a three-column report they've left off the most critical column of all didn't provide us any remarks or explanations about their claims here so they've got a few things that they say they partially support um other things they say they support but regardless of what their answer is there we need to know the details and they didn't provide the details and these are all actual real-world vpats that we've looked at over the last year here's another one that have they have a remarks and explanations column but there's um the only time they filled that column out is when an item was not applicable which is probably the only time they really don't need anything in that column all the others should have some details they didn't provide those details so both of these are you know examples of bad vpats that um should you know if if they're you're comparing products and you know you've got product a b and c product a and b um have actual vpats that you know follow the instructions include information that's meaningful um and otherwise the products are are equivalent then I you know I would toss out product c for a vpat like this um example three here we have an actual answer to the keyboard success criteria and they say it partially supports and they say all functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes so they've accurately described sort of paraphrase paraphrase the success criterion so they know what they're talking about it seems then they say however there are minor exceptions for example and so this is where the detail comes in what are the exceptions this is the kind of thing that we want because now we can we can know okay not just that some things are not going to be accessible with the keyboard but what things are those and how critical are they to the functionality of the application so the exceptions are the calendar widget on the manage section is not keyboard operable however alternatively the date can be directly entered into the date field so um so first of all if they hadn't included that however statement they just said the calendar widget is not accessible with keyboard then my follow-up question would be how critical is that calendar widget if everything else is accessible by keyboard the only thing that a person who can't use a mouse can't do is access that calendar widget how critical is that to the functionality of the product but they've actually answered this that there is an alternative if a person can't access the calendar widget they can enter the the date directly so not really a problem they've got it they've identified a minor problem but they've also identified the solution so this is a really good example um I would be pleased with this response here's one uh with that uh 4.1.2 name role value success criteria so this is the aria um success criteria and they say their product partially supports this the web application provides the correct name role state and other important accessibility information for most form controls with the following exception so similar to the one we just saw it says there are some exceptions and here are the exceptions dynamic filter results are not announced to screen reader users some calendar widgets are not using appropriate roles and this actually goes on and on and on and on it's a very lengthy list of exceptions and uh so the issue I have with this is is this truly partially supports it almost seems like you know if you get you know there is kind of a fuzzy line between partially supports and does not support but when you reach a certain number of exceptions they sort of become the rule rather than the exception and so I would argue that maybe this is actually does not support but it might be worth having the conversation with the vendor they do seem to understand the success criteria and so you know I trust their evaluation here and I trust their reporting and I appreciate the transparency of their reporting but um but I want to know you know more about how critical all these exceptions are because it sounds like there's so many of them it sounds like it's going to be really hard for somebody who's using assistive technology to perform the essential functions of the job so and to remind you we are I don't know that we actually talked much about laws and policies but we do have a uh you know all of the legal settlements and resolutions that say you know we need to meet WCAG 2.1 level 2a and so that that falls under the Americans with Disabilities Act and section 504 the Rehabilitation Act so we are under federal law to ensure our programs and services are accessible but beyond that we have a state policy policy 188 that specifically says all state agencies including higher education institutions within the state of Washington need to have IT that meets WCAG 2.1 level 2a so it's spelled out there as well um so so we know that we need to do this um but being realistic very few products if any fully meet WCAG 2.1 at level 2a um and you know that's that's our goal and our policy actually expresses that as a goal that's our target we are working towards that um but it probably every vendor is going to fall short and then the question becomes really just one of functional accessibility how can a person who can't see they're using a screen reader how can a person who physically can't use a mouse how can a person who is using speech input and controlling the computer entirely with voice you know how are they able to perform the functions that this product or service requires and for students that means are they going to be able to perform the required functions of their curriculum for employees it's going to mean are they able to perform the essential functions of their job and so um so then it's it's a question of degree of severity and of level of risk that we're willing to take um so if a product falls short in some areas that's expected but those can't be critical errors that are going to be showstoppers and prevent somebody you know some groups of users from being able to perform the essential functions made possible by this application so the next example here has three success criteria there's one for captions is one for audio descriptions and both of those are video related um and then there's the the one we've been looking at info and relationships so I want to mention I've included the first two here in the screenshot because they are not applicable this is not a video product and so captions and audio description are not applicable and it says that in the remarks and explanations column but they chose to express that as supports instead of not applicable and that's subtle but it's kind of like you know reading through advertising with a critical eye um and you know to me it could this could be an honest mistake but to me it seems they chose supports intentionally because if you look at a vpat and it has supports and on almost every success criteria that looks like a really accessible product and so they're trying to spin it that way um when in fact it should be not applicable for those two success criteria so keep a critical eye as you're as you're evaluating vpats on the info and relationships um item this is actually similar to a previous example where they have a very honest and transparent list of exceptions um but it's a very lengthy list and this actually goes on and on and on for several pages all of the exceptions and so again I you know question whether partially supports is the right um label there um probably it should be does not support but that's a conversation that needs to to happen uh the final example goes back to the keyboard success criteria again um they say that their product partially supports this and they explain why um it's because users can operate all functions in the product using a keyboard through standard controls a rating of partially supports has been given due to the following isolated issues that do not substantially hinder use of the functionality and so that you know that again I keep saying that's really the heart of my question is does this hinder a person does it block a person prevent a person from using the product if they can't do it without a mouse and they say up front no it does not I want to know more and they provide more they say the publications imports functionality is not operable with the keyboard alone users users may elect to not use this functionality and complete the task of entering publications manually so that sounds okay perhaps they say that that's not critical but I do want to know more um is it really you know is the process of entering publications manually not using the publication import functionality um you know is that equivalent or is it going does that mean that their job is going to take many hours more than it would take if that particular feature was accessible with keyboard if it's going to take many hours more then it's not really equivalent and then we want to have a discussion about that issue needs to be resolved the other thing is the rich text formatting toolbar functionality is not operable with keyboard alone but keyboard shortcuts do exist and users may elect not to use this functionality so the the fact that keyboard shortcuts do exist seems to actually contradict the fact that it's not accessible with keyboard I think if you can perform the same functions with a keyboard shortcut um then that is probably um satisfactory for um you're for making that accessible by keyboard claiming that's accessible by keyboard so so I think probably that's not that's not really a huge problem but the other piece of information that's here in concluding their comments they say a roadmap has been identified to remediate both of these known issues so I want to see the roadmap I want to know when they expect to fix those you know can we get a timeline for you know what issues they plan to fix and by when and that will really help us to evaluate our risk maybe you know maybe there's some critical issues that are included on their roadmap and maybe we want to delay our deployment until they have satisfied those issues or maybe we want to um make the um you know are doing business with them contingent upon them fixing those issues and sticking with the timeline that they've identified in the roadmap so it'd be great and we we actually have some history of this um and this is you know this falls to Lynn and and crew within procurement services but actually getting into the contract you know this roadmap incorporated by reference so that um you know they are held accountable for meeting the timeline you know of of the things that they have pledged to to fix and really that's the ideal scenario I think because so few products are fully accessible there are always going to be issues that that need to be resolved and so having a roadmap that you negotiate with the vendor that identifies the biggest priority issues and and you know documents a timeline by which we could expect those issues to be resolved that really is the best outcome I think. No we do have a question in chat good timing um we have a question that says do you find that if products aren't designed designed to be accessible from the beginning then the v-pads are just disasters? Yeah I think that probably that may be an over simplification or it may not be I think that probably is more more often the rule rather than the exception that there are a lot of products that a lot of vendors that really don't they have not thought about accessibility that's the first time they've ever heard of accessibility and that shows both in their v-pad and in their product and I can can almost guarantee that if kind of a converse of what the question says but if the v-pad is bad if it's one of those like the v-pad with the third column missing then the product is also going to be bad it's going to be a reflection of the fact that they really don't know anything about accessibility so so there definitely is a correlation there. I really like your example about getting the roadmap into the contract we've done that on a few of them and that's great because that way we have recourse if the vendor falls off the map or doesn't do those type of things and so you know we have repercussions and we have options basically in case they don't meet those timelines. And I think we have actually made payment contingent upon meeting the the goals within a roadmap if I'm not mistaken that happened with at least one vendor and I know of other institutions that have attained that too that's a difficult thing to to get an vendor to agree to but if they're confident in their ability to to pull off accessibility then they may in fact agree to those sorts of terms in order to get a contract with the University of Washington because they want to do business with us but you know we'll pay you if you if you meet you know the the obligations for an accessible product that you have outlined here you know these showstopping issues if you you know fix those then we'll pay you otherwise we won't. Yes that's I am seeing that more and more and it's a new concept for IT vendors it's starting to trend it's very common in all other industries you know especially service consulting construction they're very familiar with that. IT vendors are not as familiar with it but ones who are transparent and honest about what they want to do and what they're agreeing to usually have no heartburn with it. Okay well any other questions I actually didn't do too bad on time just 15 minutes over the top of the hour this by the way I don't know if you want to watch a rerun but it will be the video will be archived it's going to be up on our access technology website in the webinar archives page there'll be a link to it from there and that will include the the slide deck as well as the video and so you could send if there are other people that you work with who make purchasing decisions and feel free to send them to the video as well so they can they can watch this and get the information and I'll type that URL into chat as we're giving a couple more minutes for questions if anybody has them hopefully that's the correct URL I did it from memory so if somebody wants to try it and see if it works that'd be great. Awesome just tried it and it worked. Okay great well thanks everybody for coming it was a great great conversation. I'm glad it was cooler today to do this rather than having to do it in 100 degree heat but hopefully it says there's useful information for you guys. Thank you Darryl.