- Already it's 2 o'clock on the nose, everyone. So I'm going to go ahead and get us started here. Again, welcome, everyone. My name is Monica Olsson, and I'm the new Policy Associate here for Accessibility at the State Board for Community and Technical Colleges. And this is somewhat of a new role. 

And welcome to how to read a VPAT with our guest speaker Terrill Thompson. We are really delighted to have you here today, and learn more with us. I'm excited to share that over 50 individuals registered and plan to join us today. And that's quite the turnout for the beginning of fall quarter and in a global pandemic. So thank you for sharing your afternoon with us. 

You're here because you care about accessibility, particularly, IT accessibility, and you want to learn more. Maybe you're in a position at your institution where you regularly make procurement decisions, and you want to better understand how to consider and evaluate accessibility before you make those decisions. You might be in an accessible tech lead position or policy 188 coordinator position at your institution, and want to help educate others about how to consider accessibility when looking at information communication technology and procurement best practices. 

A couple of housekeeping items that I want to note. We do have a live captioner right here with us today. So if you would like to follow along and use live captioning, please make sure you've selected the CC button on the bottom of your Zoom screen. If you have technical issues, you may reach out to Shannon Bell or myself, or put a question in the chat, and we will help you to the best of our ability. 

The other thing I'd like to know is, as you probably are observing right now, we are using the Zoom webinar platform, not the meeting platform. So what this means is that you as the attendee can view the screen and hear the audio of your panelists and presenters, but we cannot see or hear you. So if you have a question during Terrell's presentation, we encourage and invite you to submit your question using the Q&A feature. At the bottom of your screen, you would select Q&A, and type in your question there. 

I'll be doing my best to take note of the questions as they roll in, and bring to Terrill's attention if there's something time-sensitive. We also have left the last 30 minutes or so of our presentation specifically for Q&A as well. So without further ado, Terrille, I have the pleasure of introducing you. 

Terrille Thompson is manager of the IT accessibility team at the University of Washington. A role in which he works to promote IT accessibility by building community, developing resources, delivering lectures and workshops, such as today, conducting accessibility evaluations, providing consulting and a support to a wide variety of constituents, and conducting research. Terrille has nearly 30 years of experience in the IT accessibility field. And we're really lucky that he's joining us today. So thanks again, Terrille. And I'm going to turn it over to you now. 

- Thank you, Monica. And thanks, everybody for being here today. As I glance through the participant list, I see a few familiar names, so it's good to see those of you that I do know and have worked with over the years, but good to see new folks as well. This is a topic that I've been given a lot of presentations on lately, and that is because procurement plays such an important role in the IT accessibility puzzle, and it's a challenging one. 

We, at the University of Washington, do have an IT accessibility team, as Monica said in my intro. I'm the manager of that team. And people come to us when they're making really high impact purchases of software that are going to be diploid University-wide and they're going to affect all students are all employees or both. And we get engaged with vendors then and we collaborate and try to ensure that that product is fully accessible. 

But we purchase thousands of IT products, so that's not a sustainable solution. They can't all come through us to review them for accessibility. And so everybody who has the power to make a purchasing decision needs to know at least a little something about how to ask for accessibility, and how to judge whether a product is going to create accessibility problems or not. 

And so that problem has been the reason why a couple of years ago I started giving more talks about accessibility and procurement and looking at VPATs and trying to explore together how can anybody review accessibility of technology without necessarily being an accessibility expert. And so that is was what led to this presentation, which I've given a number of times or presentations like this. And I'm happy to share this with you all today. 

So let me share my screen. So, again, I am Terrille Thompson, Manager of the IT Accessibility team. So we are part of the Accessible Technology Services department, which is in UW-IT, the central IT organization on campus. And our hub for communicating to campus on all sorts of things related to IT accessibility is uw.edu/accessibility. So I'll share some additional web resources throughout the presentation, but if you just remember that one, uw.edu/accessibility, then everything else is just an additional directory on top of that, so it'll be pretty easy to remember. 

So I am going to use a few acronyms, and I'll just share the most prominent ones upfront here so you will be prepared for them. First is W3C, that's the World Wide Web Consortium. And they have created the Web Content Accessibility Guidelines or WCAG. 

And they also have created a specification called ARIA, which stands for Accessible Rich Internet Applications. And the W3C is not involved in the VPAT, but that is an important part of what we're going to be talking about today, that is the Voluntary Product Accessibility Template. So each of these are going to define more specifically as we get to them. 

So I want to talk a little bit about the process for considering IT accessibility and procurement from the University of Washington perspective. So I don't have an insider knowledge on how procurement happens within your domain, but at the University of Washington, if it reaches a certain dollar threshold, it goes through procurement services. But there's a lot of technology that's purchased that doesn't meet that threshold, and so that's kind of a Wild West where anybody can purchase on their credit card. 

So we do have formal procedures if a purchase goes through procurement services. And we try to communicate to everybody who can purchase technology that you have to apply the same procedures as you're making purchases. Even though it isn't officially required, it is officially required to go through procurement services, but everybody should consider these steps. 

So this is all spelled out at uw.edu/accessibility/procurement. We've got a lot of information there that mostly quotes from procurement service's own policies and procedures, paraphrases them, and summarizes them, but that is a really good place to go for additional information. We've basically broken accessibility down into three phases within the procurement process where accessibility needs to be a consideration. 

First of all is upfront, when you are shopping for a product and you solicit accessibility information, so that may be in an RFP or maybe less formally just as you are talking to vendors about their products or doing research online, you need to ask about accessibility in order to find accessibility information. So we actually have specific language that gets plugged into RFPs. And that is-- I actually have a slide here that quotes from that, but you can find that on our procuring accessible IT website as well. 

Second, after you ask for accessibility information, hopefully vendors provide accessibility information in response. If they don't, then they're not answering the question. So that would hopefully be a red flag against them. But if they do, then we face the challenge of validating that accessibility information. Is what the vendor said credible? How do we know that? That really is a big piece of what we want to explore in the presentation today. 

Third, assuming that the accessibility is not 100%, and I'm willing to say after many years in this field and 20 years at the University of Washington, I honestly don't think I have seen a fully accessible product ever. They all fall short in some way, some more significantly than others. But where there are shortcomings, then we want some assurances that the vendor is going to address those shortcomings. And that they're going to be a good partner, and work to improve their accessibility over time. 

So we need to have faith that they are on board with that, otherwise, we're putting ourselves at risk by using their product. So with that in mind, we want to include accessibility assurances in contracts, that involves a lot of negotiation. Again, on our IT website, we do have some recommended language as a starting point so that you can get plugged into contracts. 

And we actually at the University of Washington have an accessibility rider. It's part of the UW standard terms of agreement that all vendors must sign off on. But when it comes to the accessibility rider, a lot of vendors will redline that and send us back an edited version. 

And then it ends up being a negotiation of how much risk are we willing to take if they don't have an accessible product, and they're not willing to commit to making that accessible maybe at the level that we want. There's probably going to be some compromise, and so that's some negotiation needs to happen. But, ultimately, they do need to be expected to work on their accessibility, otherwise, it is a much higher risk for us if we purchase a product that's not accessible and deploy that product and we have no expectation that it's ever going to be made more accessible. 

So I won't read all the text on this slide, but this is the information that is recommended for being plugged into RFPs. Sometimes it gets edited a little bit depending on the product and the circumstances. But the heart of this is that we are expecting accessibility as measured by WCAG, there's that acronym, the Web Content Accessibility Guidelines. 

And, specifically, version 2.1, level AA. That is our expectation. For all IT that we create or that we purchase that we deploy, it needs to meet with WCAG 2.1 level AA. And the standard means by which vendors document their accessibility and, specifically, whether they are compliant with WCAG is the Voluntary Product Accessibility Template or VPAT. And so we accept VPATs as a means of documenting how well your product does on the WCAG standards. 

And we actually have quite a bit of additional information here in this text that specifies what our expectations are related to the VPAT. We expect version 2.3 or higher. So it needs to be a reasonably new VPAT. And we expect them to complete it accurately. And most of the text on this elaborates a little bit on that. 

But there are some things the vendors tend to skip over that we consider important. And so we want them to understand that we're taking this seriously. This is not just a checkbox that we are going to say, OK, they submitted a VPAT we're good to go. Let's move on. 

So this is all rooted in laws and in policies. So I'll just spend a little bit of time on this. But at the heart of it is federal law, Section 504 of the Rehabilitation Act, which has been around since 1973. That required that recipients of federal funding ensure that their programs and services are accessible. 

The Americans with Disabilities Act of 1990 expanded that so it wasn't just recipients of federal funding. It was a much broader group of entities that were needing to comply with that law. And, essentially, that expanded to all of society. In many ways, society needs to be accessible. Programs and services that are provided to people without disabilities need to also be accessible to people with disabilities. 

And so both of those laws were enacted before technology was anywhere near what it is today. The web was in its infancy in 1990, just being invented. And since then, the web has grown exponentially and software has grown exponentially. And we now are using technology to deliver our programs and services extensively. 

And so we still, though, need to be sure our programs and services are accessible. So the fact that we're delivering them using a different means than we were back then doesn't change the requirements. Still the focus is programs and services and ensuring that those are accessible. There have been over 500 legal complaints filed against higher education institutions for having inaccessible IT. So that just sort of reinforces that this is a requirement based on federal law. 

Washington State Policy 188. You probably are all familiar with, but it applies to all of us. It's state agencies, including higher education institutions. It specifically states that. 

The heart of this policy is that people with disabilities have access to and use of information and data, and are provided access to the same services and content that is available to persons without disabilities. And it goes on to adopt WCAG 2.1, Level AA as the standard that we all are expected to meet for the technology that we're using. So that gets us then into the standards. 

I've mentioned this already a few times, but WCAG, from the W3C, is the standard not just for web accessibility, but really for anything with a user interface. The principles that are built into WCAG apply to all sorts of technologies. It is an international accessibility standard, and it really has been around since the very early days of the web. 

I mentioned that the web was invented, Tim Berners-Lee did that in 1990 or thereabouts. He created the very first web page, which still exists today. It's a fully accessible web page, but it's pretty simple. Mostly text, but headings. 

And in the very first HTML specification, Tim Berners-Lee specified that HTML headings needed to be in order and that you shouldn't skip levels within the heading structure. And also Alt text on images was there in the very first specification. So accessibility has been there since the beginning. 

And after the web was invented, the W3C was formed as an organization that would oversee the web and maintain standards and develop standards, and so forth. And they recognized very early on that accessibility could be a problem. And that was contrary to the vision the web was intended to be the big equalizer breaking down barriers and access to information. 

People around the world would have unprecedented access to information like never before. And the fact that the web could perhaps cause some people to not have access, that it could actually be a barrier rather than an equalizer, was contrary to the vision. And so the W3C formed very early on. The Web Accessibility Initiative, that was a group within W3C, they began working early in the '90s on the very first Web Content Accessibility Guidelines. 

So that took, in W3C fashion, many years because they brought lots of stakeholders together. They wanted every voice to be heard. And that results then in a very lengthy process. But the very first WCAG version 1.0 was published in 1998. So it's been around for a very long time. 

It was updated 10 years after that, version 2.0. And that is actually pretty close to 2.1, but it has continued to evolve over time. So 10 years later, 2.1 was released. And that is the current standard. 

2.2 is on the horizon, we'll probably see that soon. And there's a 3.0 that is in the early stages of development. So this is a moving, dynamic standard, but 2.1 is right now what the published standard is. 

Within version 2.0 and 2.1, we have various levels of organization within the standards document. But at the deepest level, we have very specific success criteria. So these are the nuts and bolts, what do I need to do to make sure my technology is accessible? 

Well, you need to have Alt text on images, as an example, because a lot of people know about that one. If you don't have Alt text on images, then somebody who can't see the image doesn't have access to it. So Alt text provides a description that assistive technologies can read. 

So that's an example of a success criterion. And there are actually 78 of those built into WCAG 2.1. And each one is assigned a level. So you have level A, level AA, and level AAA. And that speaks to a couple of things. 

One is the significance. Level A success criteria are a higher priority than level AA or level AAA. So these are things that if you don't meet the level A success criteria, there are going to be groups of users who just don't have access to your content. There are insurmountable barriers. 

Level AA is a little bit less significant, but, nevertheless, pretty significant. Level AAA, less significant still. Although, it's not just significance. Also they considered difficulty of implementation as they were coming up with the level assignments. So there are some in level AAA that are actually quite significant, but very difficult to implement. And so they have then got that lower level because it's unrealistic to expect all content to comply with this particular success criterion. 

So in the early days when version 2.0 was first released with this level A, AA, and AAA model, there were a lot of questions about what level is the baseline? Do we have to meet all 78 success criteria, or is it just a subset? And that has since been clarified mostly through the law through legal settlements and resolutions that have very clearly stated that the expectation is level A and level AA. 

And so policies have been formed around that expectation, including policy 188, which specifies that we must meet WCAG 2.1, level AA, which also includes the level A success criteria. So we're talking about 50 success criteria. Ideally, we meet all 78, but we specifically need to focus on those 50. 

So that's a lot, 50 success criteria. I mentioned at the onset that we're trying to make this topic accessible to people who are not necessarily accessibility experts. And WCAG is not easy reading. If somebody sits down and tries to make sense of it, it's not easy. 

For the purposes of reviewing technology for accessibility and trying to understand whether a product or service that we are considering for purchase is accessible, we can just focus on three success criteria. So that may be oversimplifying a little bit. But I think we can learn so much from these three success criteria that it really does provide a good foundation. 

So that's the heart of my message here and this talk is three success criteria. I'll explain each of them. And then we can dig a little deeper and look at some examples to see what we can learn from these three success criteria. 

So the first of those is 1.3.1 Info and Relationships is the name of it. And that is a level A success criterion. And this I've selected as one of the three because it is so important. And the editors and authors of WCAG will tell you that we really can't cherry-pick, that there are no success criteria, particularly if they're level A, then all level A success criteria are equally important. None are more important than the others. 

But I would argue that if there's anything that is more important than anything else it is communicating the structure of a web page or a digital document. It goes a long way toward making that accessible as opposed to completely inaccessible if it has no structure. So an example is headings. 

If you've got a document that is all text, and you've got visible headings, subheadings, sub subheadings to organize that and break it into different chunks, then, visibly, you can glance at that document, you can see those headings. And they're usually recognizable because they're bigger and bolder and set that text apart. And that helps you to jump through the document, scan it, look for sections that are particularly of interest to you. And then you can hone in on the particular section you're looking for. 

So you don't have to read every word starting from the top of the document all the way through line, by line, by line, by line, and try to make sense of that. For a screen reader user, if those headings are not tagged as headings, H1, H2, H3, using HTML terms, then a screen reader doesn't have the same structure. 

They don't understand the relationships between all the parts. They don't know how the document is organized. It's just one linear block of text from beginning to end, which is extremely cumbersome to try and figure that out and try to navigate. So headings really are super important. 

But it's not just headings. Labels on form fields. If you're trying to fill out a form and it's not clear what the prompt is for a particular form field, then that can be very difficult to fill that form out. 

If you're looking at a data table and you've got many columns and many rows of information and you're navigating through that with a screen reader moving linearly across the row and it's populated with a bunch of numbers and every cell sounds the same, you really need to be able to track which column you're in, which heading you're in. And the key to that happening is having appropriate markup, appropriate code under the hood, that establishes that this is a column header and this is a row header and this is a heading and this is a label for this form field. 

All of that information needs to be explicitly communicated via the code. And it's an HTML idea, but it's universal when we're talking about digital documents. PDFs have an underlying tag structure, that the same issues that apply to web pages also apply to PDFs. Microsoft Word, same thing. Any sort of digital document format supports structure semantics in some way. And that all needs to be done properly in order for accessibility to happen. 

So what I just explained may sound a little bit technical. And so you're being held accountable for three success criteria here. And the main idea is just that structure information relationships is important. You just need to know that. And you need to have a general understanding of what that means. Maybe not the specifics. 

And when you read a VPAT, with that in mind, often you can tell whether a vendor knows what they're talking about or not. Because you have a general understanding of this success criteria. And so you can look for clues that they know what they're talking about when you see their responses. 

Second example is 2.1.1. Which is called Keyboard. Very simple. And that too is a level A success criterion. And I've chosen this one because it is so easy to test. It basically just means all functionality of the content is operable through a keyboard interface. 

So if a person can't use a mouse, which many people can't. Somebody with a physical disability, physically unable to use a mouse, maybe using the keyboard to navigate through content using the Tab key, Shift-Tab to go backwards. And maybe some other keys that makes sense. 

So if you land on something that seems like maybe pressing Enter now will click this button or pressing space may click this button or maybe using the arrow keys will move this slider. Keys that make sense. The interface needs to be operable just with keyboard. 

So anybody can test this. You don't need accessibility checkers. You don't need assistive technology. All you need is a keyboard, and you can test whether a product is accessible without a mouse. 

Finally, the third is included here because it plays such a critical role in modern web-based applications. So it is 4.1.2 Name, Role, and Value. Also level A. And essentially what that means is that the application is using ARIA properly. It may be that they're using HTML properly too, but ARIA definitely plays a role. 

Any time you have a web application where there are dynamic things happening, you click a button and a dialogue pops up or you hover over a menu item and a submenu pops up, anything that happens dynamically on the same page that you're on is going to require ARIA in order for that dynamic behavior to be made accessible. So understanding this requires that you know a little bit about ARIA. 

ARIA, as I mentioned at the onset, stands for Accessible Rich Internet Applications. It is another W3C specification focused on accessibility. The goal here is to supplement HTML with additional markup that makes accessibility happen. 

So HTML itself has some limitations when it comes to accessibility, communicating, all of the stuff that's happening dynamically in an application. And so ARIA steps to the plate to fill those gaps and communicate to assistive technologies in a way that makes complex user interfaces more accessible. So the name of this success criterion-- roles, states, and properties, has to do with all of that information being what's exposed via ARIA to assistive technologies. 

So best way to understand ARIA is to look at an example. And we're going to delve into code here. So I apologize if anybody is not a coder. But I will present this in a way that is hopefully palatable even to non-coders. 

But essentially here we have some HTML. There are two elements as they're called. Two components to a web page. One of those is a button. And that is indicated here in the code with a button tag. And a slash button tag is the end of that button. 

And inside of those, you've got the phrase more info. So this is a button on the screen, it would look like a button, and it would say more info. And then when a user clicks on that button, the div, which is that second component, appears. 

So this is what would happen with this interface. You've got a button, you click the button, and this content that previously was hidden suddenly appears. And that div has an ID of info one, that's going to play a role behind the scenes. But the content of that div just says this section contains more info. 

And, again, that probably would be invisible by default. You click the button, and it becomes visible. So that's not going to be an accessible experience for somebody who can't see what's happening. 

And so they're using a screen reader, they land on the More Info button. That is articulated to them with a screen reader. It would say More Info button. And they click on that, some text appears, but the screen reader user has no idea that text just appears. All they know is they clicked on a button and nothing seemed to happen. 

So they may click on the button again, and maybe that hides the content. And they have no idea that the first time they clicked the button, that some new content appeared. So they're not getting the feedback they need in order to fully understand this relationship and what just happened when I clicked on this thing. 

So this is where HTML in-and-of-itself is not up to the challenge of making that interface accessible. Very simple interface, but it needs some ARIA. It just needs a couple of attributes on the button. 

If we add ARIA controls equals info one. That is referencing the ID of that controlled content. So it's saying the button controls this other content. The content that's in the div with the ID of info one. So it establishes that explicit relationship between the button and the div. And now the screen reader understands that there is this relationship. And it can communicate that to its users if it needs to. 

The other. Even more important piece is Aria expanded, which is currently false. That says that the content controlled by the button is not currently expanded. And so when a screen reader user lands on this button, it's now going to say More Info button collapsed. 

Because it's not expanded. The opposite of that is collapsed. So the user knows, OK, there's some content controlled here. When I click the button, that should expand that content. And then that content will be accessible to me. 

They click the button, the screen reader says expanded, and now they know, OK, I know what happened. I just clicked the button, I expanded something, some screen readers will provide a keyboard shortcut to allow the user then to go directly to that content that just appeared. Others don't do that so it's imperfect implementation or inconsistent implementation among screen readers. But if the two items are adjacent, the screen reader user can just go down and discover the content that just got expanded. 

So the important thing here, again, is not for you to learn ARIA and to memorize all the ARIA attributes. There's a lot of ARIA markup. And even your really skilled developers don't know at all. There's a lot to learn. 

But the bottom line is just understanding what ARIA is and the role that it plays in making dynamic, complex, rich internet applications accessible. And a lot of the technologies we're talking about in procurement are now web applications. And so this directly applies to them. 

So what is a VPAT then? I mentioned earlier that a VPAT plays a role in our understanding of a product's accessibility, that's exactly what it does. It stands for Voluntary Product Accessibility Templates. And this is a standard means by which IT vendors can provide documentation on whether and how they meet accessibility standards. 

So when we the question, does your product meet WCAG 2.1 level AA? They can reply by providing us with the VPAT that specifically tells us that. Here's how we meet WCAG 2.1 level AA or how we don't meet it. And as we will explore VPAT in more detail and you'll see that it's important. Both of those things are important in how we meet and how we don't meet. 

There are different versions of VPAT. It's been around for a very long time. It started with Section 508, which was around 1999, 2000. And those were very old standards. 

With the VPAT, the Section 508 required that federal agencies ensure their technology is accessible. Section 508 as a law has never applied directly to non-federal agencies. It doesn't follow federal funding like Section 504 does. So that's the source of a lot of misinformation. 

A lot of people think Section 508 is the law that we're all trying to meet. Whereas, it generally is not in higher education unless our states or our institutions have adopted the Section 508 policies as their own, which Washington has not. So we have no obligation to meet 508, but 508 did result in the first set of accessibility standards that were developed. And the VPAT was created for federal procurement officers who needed to have some means of telling whether a product was accessible because they were obligated to purchase accessible products. 

So it is voluntary, so the V in VPAT is voluntary. Vendors don't have to fill this out. But if they were doing business with the federal government at the time, they needed to fill it out because that's what procurement officers were asking for as documentation of accessibility. But we're not trying to be 508, we're trying to meet WCAG. 

And so the VPAT has evolved over the years. Version 2.3 was the first version that provided a mechanism for reporting on conformance to WCAG 2.1. There is some earlier versions that were WCAG 2.0. 

But since 2.1 is our standard, this is why in our RFP language, we specify that it must be VPAT 2.3 or higher. Otherwise, they're not going to be able to answer the question of WCAG 2.1 compliance. So we actually still get a lot of old VPAT based on the old Section 508 standards, and that doesn't answer our question because it's a completely different set of standards. 

The latest version is 2.4 that was released in February 2020. So, yeah, there are some improvements there. So it's good to probably keep an eye on the improvements over time, but definitely VPAT 2.3 you have to do that, or you're not going to be able to answer the question. 

So within each release, within version 2.3 or 2.4, there actually are four additions that's important too. Because they are based on different standards. So there is a WCAG 2.1 addition. Since that's what we're looking for, we need them to fill that out. Not the Section 508, not addition, not the European Union edition. 

The INT or International Edition actually would qualify because it incorporates all three of the others. So some vendors may, if it's a big corporation and they are doing business all over the world and with the federal government and they need to document their accessibility on all the standards, then they, in fact, do the INT because that's one VPAT that covers all audiences. And that's OK because it does include WCAG 2.1. So either the INT or the WCAG 2.1 editions are acceptable. 

So this is what a VPAT looks like. It contains three columns. It actually is pretty simple. You've got the criteria over on the left. Then you have a conformance level in the middle. And then you have remarks and explanations. So the criteria contains one row for each WCAG success criterion. 

So you go back and we look through that. They're all numbered. The ones that I had pointed out as being important 1.3.1 Info and Relationships. It's the fifth line down, Keyboard 2.1.1, and Roles, States, and Properties is off the page, but that would be down near the bottom. All of these others play a role as well. But, again, you can just look at those three and learn a lot about a company's accessibility. 

So the conformance level, that middle column, is a multiple-choice question. That's important because a lot of vendors fill this out wrong. A product either supports, partially supports, does not support that success criteria. Or it's not applicable, or they didn't evaluate it. 

So the difference between supports, partially supports, and does not support, there's a little bit of wiggle room there, but it is explicitly defined in the instructions. Partially supports means some functionality of the product does not meet the criteria. So maybe it mostly does, but there are a few exceptions. 

And, of course, support means it fully supports the criterion. Does not support is like partly cloudy versus partly sunny. The majority of the product does not meet this criteria. There are a few exceptions where it does OK, but by-and-large it does not meet the success criteria. 

So we just expect one of those answers in the conformance level column. The most important response, though, comes in that third column, remarks and explanations. Where they provide the details to explain why they chose the answer that they chose. 

Regardless of what their answer is, if they chose partially supports, we certainly want to know how they meet this criterion and how they don't. What are the nature of the problems that you know exist, and how significant are they in a person's ability to use the product? If they say supports, we still want to know why they say that. What is it your product does that meets this success criteria so that we can have some confidence in your answer. There's also required metadata at the top of a VPAT. There are 11 required fields in the instructions. I actually there are five that I am most interested in. The authors of VPAT. Your May field at all 11. I mean they're all required. 

And so, just follow the instructions. Fill out all 11 required fields. But in particular, we need to know the name of the product and the version. We need to know which version was reviewed. Because if they release many versions of their product, yet things change over time. And if we're looking at an older version VPAT that that's not applicable to the version that we're looking to purchase. That's significant information. 

We also want to report date. So, if they haven't updated their VPAT in the last five years. Then unless they haven't updated their product in the last five years. Then that report is out of date. The VPAT should keep up with the changes in the product. 

We also want contact information for follow up questions. And we want that to be somebody who can answer the accessibility questions. So, a lot of times on VPAT I see just a general help. Their contact information. And that is probably not going to be. It's not going to get us to the person we want to talk to. At least not easily. And maybe not at all. 

But somebody filled out the VPAT and so they presumably have some accessibility knowledge. They definitely have knowledge of the form itself. And why they chose the answers they did. That's the person we want to talk to. That's the person whose contact information should be provided. 

We also want to know how they did this. What evaluation methods did they use? And what are the applicable standards and guidelines. It kind of is a given based on which form they have chosen. But we want it to be clear that they are documenting their conformance to look like 2.1 level 2A. So, they need to explicitly state that in the required field. 

So, quick guide to reading a VPAT. First of all did they include all the required metadata? If they didn't, what does that tell you about them? There are 11 required fields, if they can't follow that instruction. And fill out all 11. It may tell us that they're hiding something. It may tell us they can't follow instructions. And therefore their credibility may be in question. 

Or it may tell us that they are just trying to get this passed through. Because it's a requirement. With our purchasing procedures. And they're just expecting to get it passed. And don't want to spend too much time on it. None of those are a good thing. 

So, that actually is important information. If they filled the form out properly and included all the required fields. That's a plus them. And number two. Do they fill the form out properly. And not just do they include all the required information but did they use one of the multiple choices in that second column. 

Does the remarks and explanation column have enough detail so that we can make an informed decision about the product's accessibility. That's the goal with this form is to make it possible for us to look at this form and understand more about the accessibility of the product. 

And then finally look a little closer at the three success criteria that we've been talking about. Just to see what you can learn about the product. And about the company from those three. And as you're doing that, ask first of all who completed the VPAT? And independent accessibility consultants is preferred. That way we're not reliant solely on the vendor. And then often it's their marketing team that fills this out. And tries to spin everything as a positive. 

If they hire an accessibility consultant to evaluate the product. And gives us an honest appraisal then that always is going to just yield better information. And more trustworthy information. 

Also did they follow the instructions. Do they seem to be knowledgeable of accessibility. Based on what you now know of those three success criteria? Does their answer make sense? Or does it seem like they're sort of out in left field and don't really know what they're talking about. 

And after reading their VPAT, ultimately this is what it comes down to, do more about the accessibility of their product? And what follow up questions do you have? Because VPAT is not the final answer. Unfortunately, we would love to have something like the energy star compliance tag for you. If that's there, you can trust that it is in fact energy star compliant. 

There's no such thing in accessibility right now. And so if they claim that they are accessible via their VPAT then we can't necessarily trust that. This should be a conversation starter we want to engage them and talk to them about their commitment to accessibility. And by reading a VPAT we can come up with some specific questions that we can ask. 

So, example questions that you might want to ask. Is your product accessible? Is not one of them. Because that is far too open ended and if you're talking to a sales rep then they're probably going to say yes. And then try to back that up later. But a better question would be in your VPAT. Here's what you said on 1.3.1 info and relationships. 

And I'm trying to make sense of that. Could you help us understand what you meant by that response. And can you elaborate on how your product meets the success criteria? And see what kind of response that you get from that. 

Please describe your company. How your company addresses the need for accessibility throughout the product life cycle. So, that anybody can ask that. You don't need to be a technical person to ask them about their company. And about their strategies for addressing accessibility. 

And this is really even if their product is inaccessible. If they care about accessibility and they've got some somebody who's in charge of accessibility. They've got some means of training their engineers. Or their quality assurance team on accessibility issues. 

And they're integrating accessibility into their company culture somehow. Then that would give me a lot of confidence over. Even if they've got a bad product now. There give me some trust that they're working to address those. And the product is going to improve over time. 

Also what is your methodology for testing your products for accessibility? Who does that testing, which tools and assistive technologies do you use. So, that it kind of ties in with the previous question. And we want to know more about their processes and their culture. And how they address accessibility. 

And same with the final question here. What sort of training? Do your designers, engineers, and quality assurance personnel receive on accessibility? So, I want to spend some time and look at the fields of VPAT. 

- Hello you all this is Monica 

- Hi Monica. 

- I'm pardoning here. I hope that's OK. Before you move on, I just want to let you know. I know you're going to dive into some examples here in a minute. We've got two questions for you. And I want to draw your attention to them. 

The first question is about how often it's recommended to ask a vendor for a VP power updated VPAT. For example is it just when signing contracts. Or with every contract renewal. I think that's a great question. 

And then another question is if it's possible to request a completed VPAT for free websites. Or software such as soundtrack.com. So, just thought you might want to consider those as you continue on in your examples here. Thank you. 

- Yep. So, on the latter question. Anybody can fill out a VPAT. And so and certainly free. There are lots of tools that are provided year for free. That do include the VPAT. I don't know about the one that you mentioned specifically. But we actually use the VPAT as a way of documenting internal accessibility too. So, web developers at YouTube if they're developing an application. 

Then they can use the VPAT as a means of sort of auditing their own application. So, it's available. It's freely downloadable off of the internet. And you can use that as a form. And I think it's perfectly reasonable to request this if anybody with whom we are looking to sign an agreement. Regardless of whether we're paying money for that product or not. Just because it's a way for us to understand more about the accessibility of that product or service. 

And the now I've forgotten what the first question was. Oh, how often do you ask. I do think those are the licensing points. Certainly, those are a good time to tie-in to that existing process. That when you're initially licensing the product definitely but probably at this point, we've got a lot of inaccessible products out there. 

And so, we need to revisit the accessibility of those products when it's time to renew the license. And if it's possible you're depending on the nature of your relationships with vendors to give them a heads up. That if we get a renewal date coming up. And we really need to do something about our accessibility. 

And so just a heads up that. We're going to have some accessibility requirements tied with that license renewal. And start working with them early if that's possible. But I do think tying into those kind of the existing lifespan of the license. Kind of makes a lot of sense. OK. So, and let me know if there are other questions that pop in. 

Meanwhile, let me jump over and look at a few examples just to kind of practice some of this. So, the first example here. We have criteria and we have conformance level. If this were a meeting, I might do this more interactively. Where I'll let folks type in chat. Is this a good VPAT or bad VPAT. And actually we could do that perhaps because we do have chat. 

So, what do you think? What's the problem with this VPAT, given what we just talked about. 

- This is Monica. You're absolutely right. We do have chat functions. So, attendees you are welcome to put in your thoughts about this VPAT into the chat. 

- And I say, what's the problem? And Vicki says no remarks. Initially when I read that Vicki I thought it meant you have no remarks. 

[LAUGHTER] 

But now I see that you're answering the question. Which is absolutely correct. It's a two column table. And we know that the VPAT has that three column table. So, they for whatever reason elected to remove the other column. And just go with the multiple choice. 

So, in that particularly is problematic because it's not all supports. There are at least a few items where they partially support. And we can't do anything with that. We have no idea how significant it is. That they don't fully support non text content. They don't fully support the no keyboard drop rule. This could be significant problems and we need to know more in order to judge. 

So, example two has all three columns. So, we know that's good. But and this is fairly obvious. So, I won't ask you to type in chat necessarily here. But the remarks even though they have remarks and explanations column. They have not used it properly. 

They have only filled that in for items that are not applicable. And that arguably is the only time they don't need to fill it in because not applicable kind of stands alone. We understand that not applicable means the criterion is not relevant to this particular technology. They don't need to tell us that they do need to tell us why they feel that for everything else here they support. We'll look at the success criteria. 

So, I also say that if it's a 100% supports VPAT. Then as I mentioned I've never seen a fully accessible product. And so I'm always very skeptical of something like this that claims full compliance particularly with no additional detail. These, by the way, are all actual VPATs. And pretty recent actual VPATs over the last year that have come across my desk. 

So, example number three. We've got all three columns. We've got standards that don't look quite like the standards that we have been talking about. And they're talking about server side image maps and client side image maps. This is the original section 508 standards from back in 2002 and 2001. And again this is a recent VPAT. 

So, this that kind of speaks to why we're not using those old section 508 standards anymore. They really are not applicable to the way the web works today. And not only that, but supports is probably not the best choice here not applicable is a better choice. Because they're not using server side or client side image maps. So, it's a not applicable question. So, the big problem here is they're using the wrong version of the VPAT. 

Next we have 2.1.1 keyboard. So, this is one of those that we should be looking at. And we understand that, that means everything needs to be accessible with the keyboard for people that are not using the mouse. So, they say partially supports. And they provide extensive documentation. All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. 

However, there are minor exceptions. For example, the calendar widget on the Manage section is not keyboard operable. However, alternatively the date can be directly entered into the date field. So, I can imagine that. I'm imagining somebody using this application they can't use a mouse. They land on the date field. And there's a calendar widget icon that they could use to select the date. But they can't get to it because it is a mouse only feature. 

But they can just enter the date into that date field and that will suffice. So, the fact that calendar widget is not accessible is exactly the kind of thing that we're interested in partially supports. We always ask are the shortcomings significant? Are they going to block a person from being able to use this product for its intended function? 

And in this case, the answer is no. A person can fill out the date field even if they can't access the calendar widget. And probably it's a lot easier just to type the data in than it is to use the calendar widget anyway. 

So, I actually am pleased that they have a really good command of what the success criterion is all about. And that they are being so self-critical that having access to that calendar widget raised a red flag for them. So, that really says a lot about their commitment to accessibility. They're really paying attention to details and they're holding themselves to a high standard. So, this is a really good example of the VPAT. 

Here's one for that. The last success criterion we talked about. The one about using aria 4.1.2. Name, role, value. And again, this is a partially supports. And their explanation is that the web application provides the correct name real estate and other important accessibility information for most form controls with the following exceptions. There's a dynamic filter result, which is not announced to screen reader users. And there are some calendar widgets that are not using appropriate roles. 

So, question about this one then is, how significant are those features? It that seems reasonable enough. First of all it seems like they understand what they're talking about. They may, or may not. Just be trying to convince us that they know what they're talking about. 

But it seems this answer seems right given what I know about ARIA. But now I wonder about dynamics filter results. And calendar widgets. Calendar widgets I mean that was a problem at the keyboard interface as well on that other VPAT. 

So, calendar widgets seem to be a consistent problem but the dynamic filter results in my mind are probably a bigger concern not knowing anything about this product. Because probably you need to filter your results. 

If you're sharing a set of results that includes hundreds of results. And you need to be able to filter those in order to use this product effectively. Then make changes to the filter. Through the filters you make changes. But as a screen reader user you're not notified that anything has changed. That seems like a pretty significant problem. 

So, this is where reading the VPAT trying to come up with follow up questions comes in where this is something I want to know more about. So, and I'm talking to the vendor. I'm your VPAT 4.1.2. 

You mentioned the dynamic filter results. With screen reader users potentially having a problem with that. Could you elaborate on that. And explain how the filter results work? And what the experience is going to be like for a screen reader user. And help us to understand that. 

So, that's a part of it. The other piece of that conversation then is. You understand this problem. You've documented this problem. And you've been very up front and we appreciate that transparency. But when are you going to fix this? What's your roadmap for turning that properly. So, that screen reader users have access to the dynamic filter results. 

And Meanwhile what we're waiting is there some kind of workaround? That can screen readers use this product or is that going to prevent them from being able to use it effectively. 

Example number 6. We have actually included three success criteria. I think mainly I'm interested in 1.3.1. In phone relationships but I wanted to show the others that are included here too. Both related to captions and audio descriptions. A video related success criteria because they did one of the other VPATs did. They chose the word supports. Rather than not applicable. When in fact these are not applicable because there's no video in this product. 

So, in that it might be an honest mistake, but it also could be that they are aware that supports looks good. And when somebody who is not really educated about how to read a VPAT. Reads a VPAT and they supports, supports, supports, supports, supports, supports. 

That sure looks like an accessible product. And so, I want to call their bluff here and say that's not an appropriate use of supports. That should be not applicable. And you're trying to convince me of something here. And I've lost a little bit of trust in you. But I'll give you a benefit of the doubt and assume that that's an honest mistake. 

But it does raise a yellow flag if not a red flag. So, at 1.3.1 info and relationships. We have this web app has proper information structure in relationship text. But there are some exceptions. And it goes on to list all the exceptions. And I won't name, the product. But I will say that this actually went on and on and on several pages of exceptions related to information structure and relationships. 

So, that's where partially supports versus does not support. Again there's a little bit of gray area there. But if it is mostly cloudy and you only get a little one little bit of blue sky during the day then probably that is more cloudy than sunny. And you should use the appropriate choice to identify the actual state of your application. 

But and so I would talk to them about this. It seems like you have a very long list of exceptions here when it comes to information structure relationship. So, can you talk a little bit more about these in the impact that they have on particularly on screen reader users. Because that is who is most impacted by this particular success criterion. 

Next example number 7. Again 2.1.1. This is keyboard. They say partially supports. They say that they chose this because users can operate at all functions in the product using a keyboard through standard controls. But there are some isolated issues that do not substantially hinder use of the functionality. 

So, that's a key piece there that's what we want to know, does the lack of keyboard support wherever that exists does it impede a person from being able to use the product for its intended functions. They say no. So, that's good. I want more and they provide more. 

They say the publication's imports functionality is not operable with the keyboard alone. Users may elect not to use this functionality and complete the task of entering publications manually. 

So, it's an optional feature. Maybe they don't need to import publications. Maybe they can just do manual entry. But that sounds kind of significant. It's not required that they do this but entering everything manually sounds a lot more time consuming than importing. 

So, I want to explore that more with them. I need to know the product better. And I need to know how significant that difference in approaches to this task might be. Also the rich text formatting toolbar functionality is not operable with the keyboard alone but keyboard shortcuts do exist. Users may elect not to use this functionality. 

I think that to me sounds like a again it's sort of being a little overly self-critical. That keyboard shortcuts do exist for the functionality. So, you can't access the toolbar itself. But you can use Control B to bold. That to me suggest that it's a different way of attaining the same thing. But if in fact this is true you can perform all of the same functions with keyboard. Then that really is not a failure. 

So, but the most important thing of all here is that last statement a roadmap has been identified to remediate both of these known issues. So, I want access to that roadmap. Any time they say that they are making. They're working on this. Bug has been filed that's another one that we see a lot. 

I want to see the bug. I want to know when they expect to have that finished. And let's work together to kind of agree upon a timeline that ideally would be built that into the contract. That we expect them to follow their roadmap and make improvements in accessibility along a documented timeline. 

So, I also want to mention a couple of additional resources beyond VPATs. That I think we all may be interested in. One of those is the HECVAT which has been used already mostly for documenting security issues with technology. 

The higher education community vendor assessment tool. 100 plus colleges and universities actively use. This is not integrated into our purchasing formally at the University of Washington. But I don't know about you all. If you're using the HECVAT. 

But they are releasing a new version at the educators conference this month. So, October 29th. I put a question mark there. But I think that is there is a session on October, 29th. Specifically, on the HECVAT update. And the new HECVAT in addition to addressing security and privacy has a bunch of accessibility related questions. 

So, vendors are going to be expected to fill this out. And the accessibility related questions may tap in a little deeper than what the VPAT does on accessibility practices, including how they integrate accessibility into their culture. And their product development lifecycle. 

So, keep an eye on the updates to the HECVAT particularly if you rely on the HECVAT as you're doing purchasing. Because that may play a key role in accessibility moving forward. 

The other is a new project called the OPAT. This actually is from some of the same people who are behind VPAT. The GSA. The federal government. But Open Product Accessibility templates what it's called. It's available on GitHub. I've provided a URL there. But I think you can Google open product Accessibility Template and probably find it. 

But they basically are creating. It's not a new VPAT. But it is a way to digitize the VPAT. Or digitize accessibility compliance reports on VPAT are an example of those. 

And some of the benefits as I understand it. I've only just started looking at this, I don't have a complete grasp of what all they're doing. But one thing is by digitizing this. Rather than having a template which is a form people can download it. They can chop off the third column. If they don't want that. They can skip required fields. They can enter incorrect information in multiple choice fields. 

And there's a lot of freedom now to mess things up. But if they digitize this there will be some self validation built in. And so, they have to fill it out accurately. They have to fill in required fields. Or else they get a validation error. So, that's going to cut down on the number of validation errors. 

Also if they have a standard digital form. Then that makes it possible to have a centralized database perhaps. Where you can compare products more easily across the different success criteria. And you can have better version control. 

So, able to track changes of the product over time to make sure product is moving in the right direction. Those sorts of things. So, this seems like a really good project. Definitely one worth taking a look at. And seeing how this might apply moving forward to the work that we're doing. So, that is all I have prepared but I am happy to answer any questions that folks have. 

- Thank you so much Terrille. That was incredibly helpful and super informative. There is a question and a comment in the Q&A feature, which I'll read out loud. I'm curious how you Deb might be approaching this idea that shared with us by William. 

He says it seems that many state agencies and schools use similar even the same version of software. Is there a pool or shared VPAT database? If one agency has verified and approved other agencies colleges et cetera could maybe use that for approval. 

It seems like a lot of work is duplicated to approve or not approve things like Matlab, Visual Studio, Google Classroom et cetera. I will share that there is not something like that in existence right now for the CTC system although that is a conversation and a desire that has been stated over the years. And something I'm interested in. Looking at I'm curious Terrille if the University of Washington is addressing that idea in some way. 

- We've been part of conversations related to that for many years. Through a lot of different organizations ahead is one the Association of higher education and disability has taken that up. We actually formed a small subgroup that explored that for a while. 

And kind of reached a dead end. And it has been a topic for often the access technology higher Education Network. And also maybe I wouldn't say reached a dead end because it's still an ongoing conversation. But has not resulted in anything tangible. 

And educators has also been exploring this and I would say that too is sort of an open ended conversation. Still on the table. But lots of issues keep coming up. In all these conversations about willingness to share. Are we as an institution liable? If we report on a vendor's lack of accessibility. 

I would personally I think not if it's objectively measurable. But that is a concern and whenever lawyers get involved they raise red flags like that and that has kind of been a showstopper. 

Also the credibility of information has been a question. How do we ensure that the person that's reviewing a product. And then posting they review. How do we know that they are credible. And are we all measuring things in identical ways. 

All these things I think are solvable. But another problem has been funding the conversations have been volunteers we want to see this happening. or people who want to see this kind of thing some sort of central database or we can all share information. We can share test results. And but we don't have the funding to support our doing that. 

And so it never has really gotten off the ground. But I do think that I encourage anybody with an interest to get active in those conversations. And probably the best place to do that right now is educators with IT accessibility community group. And that too is easy to Google and get it because it accessibility and you'll find that group and you can get involved in the discussions that they're having. But I will also say that Ward Naf has created something I think in the past. 

- Yes. I could speak to that a little bit. Ward Naf walk in community college created the ECT accessibility compliance tracker tool. And the goal behind the design of that tool is exactly this. To create a centralized place to share software VPATs and test results. 

I think the very similar roadblocks have been experienced in that project as you've mentioned. So, in I would say all of the advice you just shared with us is really wonderful. And I to encourage people to look into maybe joining the educators IT accessibility group and conversation. 

And William, if you have interest and capacity maybe to consider participating in some of these conversations. With Ward and myself we invite people to join in and moving this forward working with us. I'm going to take a pop a little look into the chat and make sure I haven't missed anything. I see another comment again from William that says. I think there's a lot of power when multiple schools approach vendors and tell them as a group. That we do not want to approve their inaccessible applications. Thank you for that comment. 

- And we one thing that we do at the University of Washington is. We have the capacity perhaps more than other institutions to actually work closely with vendors. And so we've got a dedicated staff person that has full time focusing on vendor collaborations on accessibility. And his capacity is he's out of bandwidth so you know he's really got to sort of choose which vendors he collaborates with. 

But those collaborations are often open to other institutions. And so if you want to have a voice at the table then you could you're using some of the same products we are. Know we have active collaborations with Zoom for instance. And Google and Microsoft and a number of their products. And lots of others. Can the Canvas collaboration is kind of a model. We started working with in structure many years ago. 

And that we reached out through Athon to find other institutions who were using Canvas that might be interested in joining us. In collaborating with them and working on their accessibility. And that ultimately led to a Canvas course that they hosted where we did most of our collaborating using the discussion forum. To log issues. And discuss those issues. 

And we and that still exists. We have over 100 about 150 participants now representing close to 100 institutions. And so many of those are either Canvas customers. Or Canvas would be customers, potential customers. 

And that at least in the early days really had an impact, I think, on Canvas accessibility because they saw how many people cared about accessibility and really dedicated some resources to making sure that their product met the needs. Particularly of those potential customers that were insisting on an accessible product otherwise they were not going to do this. 

- Thank you. That's great. I see another question that just came in. What thoughts do you have about accessibility testing of high priority user paths features versus full on blanket testing of a product? So, that question I think is about prioritizing what you test. When you are doing those reviews and assessments. 

- Yeah. This is important. And that is actually it speaks to how we do testing. Other institutions may approach it differently. And the accessibility consultants may approach it differently. We don't actually use a VPAT or any sort of look at checklists. We are looking at functional accessibility. And every collaboration we get involved with we sit down with the service owner or service manager at the University of Washington. 

So, it's the person that owns this product at the University of Washington. They're a key player in all this. Because they help us understand how we are going to be using the product and what the key workflows are. 

So, if we're sitting down to take the data as an example. If I am consuming a lecture that was recorded at opto. What am I expected to do? With this interface what are the common workflows the common functions that a person should be expected to be able to perform. 

And they'll make a list of those, and prioritize them, and then we step through that list. Step through each of those workflows. Each of those functions. Using assistive technologies. Using keyboard alone. And we're less interested in perfect compliance if there are some images here and there that don't have Alt text. If those images don't have anything to do with the function we're trying to perform. Then they're less critical. 

So, we are more about can we complete this task. And we do that with the vendor present and with the service owner present. And so everybody experiences this. Records those sessions. And then we can refer back and say, this is what it looked like when we met and did this testing it. And then it track improvement over time. Try to hold the vendor accountable for fixing those specific issues that we've identified. 

- That makes a lot of sense. Thank you. And says, I think you may be answering my second question right now. And what is the second question. Let's see. It seems like there's a lot of space between reading for three criteria on a VPAT and a full dedicated test of a product. But I feel that it just seems difficult to sustain with our resources. 

- Yeah. 

- Yeah. I think you were just addressing that. So, looking at those critical functional tasks that the end user would be required to perform to engage with the product successfully and prioritizing evaluation of those things. Is that true? 

- Even then. And this is a dilemma. And I honestly don't have solved. And I've never realized this I've sent maybe mixed messages here that I set out to convince you that this is easy and anybody can do it even without accessibility knowledge. But what I just described sitting down with the vendor and with service owner and testing the product. Is a very different thing than reviewing three items in a VPAT. 

So, that is a higher level and for us the difference is the impact of a purchase. And so we don't have as formal of a mechanism as we would like. But we're working on that. Internally there are efforts to better organize the procurement process. 

So, that ultimately, we'd like to have sort of a risk score for every purchase. And if something is a top tier risk where it's going to affect so many students. Or so many employees or so many visitors across the institution that this absolutely needs to be accessible. 

And that reaches a higher level. And that needs to go through accessible technology services. We need to test it. We need to talk to the vendor. We need to sign off on it. We're not there yet. We don't have that kind of authority. But we do test a lot of products that sort of reach that level. 

And we can recommend purchase or not. And then it's up to the person making the purchase. They have the choice as to whether they want to take on that risk or not. We can tell them what the risk is. 

So, but that is a very much higher level of accessibility scrutiny that major products need to rise to that level. It mostly is the other things that we don't have the bandwidth to review. And we honestly don't expect the purchasing agent to be able to review. 

Just because even if they could identify the functions. Maybe they could test with the keyboard. But we don't expect them to learn how to use a screen reader. And to test whether the screen reader. Because that is a very specialized skill. So, it's those lesser priority purchases that sort of at this presentation is more centered on. 

- That makes sense. Thank you. Again I just want to thank you Terrille for sharing your afternoon and expertise with us. It's been wonderful to have you. We are right at 3:30 on the nose. I will I'd like to share that this has been a recorded session. So, we will be sharing the video recording and the slide deck as well for future reference. People are welcome to email me specifically with questions. 

And with that again thank you Terrille. Thank you everyone for your attendance and attention today. And we're going to close today's session. 

- All right. Thanks, everybody for coming. 

- Thanks again. OK. Bye, bye now.