Accessibility in Procurement

00:06 - And that is a little more comprehensive than we’ll be diving into today.

00:10 - 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.

00:20 - 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.

00:32 - What can they do? What do they currently have? What are their current capabilities? And then second, to validate that information that’s received.

00:42 - And if you need help with that, that’s part of what the accessibility team does and has information on their website as well.

00:49 - And then including accessibility assurances in contracts– while it’s awesome to solicit and validate their accessibility, as we all know in a contract itself, what’s– the requirements that are actually in the contract are the best part.

01:07 - And that’s what’s going to actually put some teeth into it, because if what the vendor has could possibly change tomorrow.

01:16 - And so if the accessibility assurances are not physically in the contract and something changes, then you have no recourse.

01:24 - It’s a lot like if you hired someone to paint your office.

01:29 - And you said, OK, I would like the walls white.

01:32 - And the contract said we’re going to paint white walls, and that’s great.

01:38 - And if they didn’t paint those walls white, so you came in and those walls were red and you really didn’t want red walls in your office, you could point to that contract and go that’s not the color we agreed upon.

01:50 - 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.

02:08 - You need to change that at your expense because that’s not what we agreed upon.

02:13 - So having it actually in the contract makes us have some recourse.

02:19 - And it also has accountability for the vendor, for what they say they’re going to do, and what they can do.

02:27 - 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.

02:40 - And partnering with stakeholders is really key, and that’s what our team does.

02:45 - Most of the people on this call and viewing right now are stakeholders.

02:51 - We consider those our internal and external partners.

02:54 - And doing that early is best. If you’re not early, you’re late.

02:59 - Because if you don’t start at the beginning, then you’re scrambling at the end trying to get things done.

03:06 - Engaging people as early as possible is key and getting involved in the process from a procurement standpoint before a final decision is made, because– today is a great example.

03:18 - It’s biennium close. And if someone says we want to hire this vendor and this needs to be signed today.

03:24 - 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.

03:38 - Either the solution might get unplugged, might not get renewed, someone’s budget might expire.

03:45 - And then we don’t have that. We’ve lost all of those opportunities.

03:48 - It’s like shopping for a car when your current car is broken down.

03:53 - You don’t have a lot of leverage. You need a car.

03:55 - You have to get places. And so your options are dramatically decreased and your negotiating power.

04:02 - You’re pretty much stuck. And so getting a seat at the table when selecting vendors is really good.

04:10 - Terrill and I recently did that. We had a department looking at an enterprise solution.

04:14 - And Terrill was able to talk to them early in the selection process to say this is going to be a big solution.

04:25 - What about accessibility, because this is going to have wide visibility for all of our campus and high exposure, as well.

04:33 - And this is important even on non-high-exposure items, but being able to– from a procurement and an accessibility standpoint, making sure that they’re involved.

04:44 - 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.

04:56 - And then involving our other process partners besides the accessibility and keeping that holistic view of the process is good, as well.

05:06 - Because we also have our chief information services office, also called the CISOs office, and privacy as well.

05:13 - And so there’s a lot of pieces that are involved when we start thinking about buying specifically IT solutions.

05:21 - 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 with the University of Washington is we have general– what we call general terms and conditions that we attach to all of our orders.

05:44 - And those are– the accessibility language is in a link to our policies is embedded into our boilerplate terms and conditions and our website information.

05:54 - And so anything that we send out to vendors as a standard already has that built in.

05:59 - So it’s not manual. It’s not dependent on memory or process or an afterthought.

06:06 - It’s basically this is our baseline standard that we expect from all vendors.

06:11 - And we include the riders and terms and all of our RFPs that we do and in solicitations regardless of size.

06:18 - And so we don’t have any type of parameter say, oh, if it’s over $10,000, or oh, if it’s more than 10 users.

06:28 - Accessibility is important regardless of the size of the contract, regardless of dollar value.

06:34 - And so that standard for everything that we do, it’s basically policy.

06:39 - We do standard training for all of our procurement team members on all of our riders and accessibility.

06:45 - Since we’re essentially the last stop in checking everything and making sure it’s correct, all of our team receive standard training to make sure that all of these things happen.

06:59 - 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.

07:17 - And Terrill 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.

07:41 - And then if there’s any deviations, 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.

08:02 - 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 to the legal level or otherwise, and so somebody at a director or EVP level should be looking at that, since they are also the sponsors of accessibility at the University as well.

08:30 - And so that shouldn’t be somebody– “I’ve been at the University for two days.

08:34 - Someone hired me to do data entry for POs. And sure, I’ll approve that this vendor can’t be accessible. “ That doesn’t– that’s not really equitable or appropriate for someone to make those type of decisions.

08:46 - And so those deviations really should be the person with the ethical and fiscal responsibility at the University.

08:55 - And this next slide, we’re going to turn it over to Terrill And he’s going to start talking about the rest of the accessibility pieces.

09:03 - So thank you, Terrill. TERRILL THOMPSON: Great.

09:05 - Thanks, Lynn. So the rest of this presentation it actually is an encore presentation.

09:13 - This is something that I gave at TechConnect about a month ago or so.

09:20 - And then Lynn and I gave this entire presentation to a group of city and county representatives last week.

09:31 - But what we found is that we could very easily use a lot more time than we had in those venues.

09:38 - And so we booked this as a two-hour presentation, but probably it’s going to be closer to one hour.

09:44 - But we do have some room, a full hour, if we need it, to go over and to have some discussion and so forth.

09:51 - And we also have a number of examples we want to look at the end.

09:55 - So the purpose of this presentation and the reason that it came about is because now that we do have IT accessibility and IT accessibility rider that is part of the standard UW terms and conditions, more and more procurement is including accessibility, which is great.

10:19 - So that first step in Lynn’s first slide that listed the three steps, the first step was to solicit accessibility information that actually is happening.

10:29 - If IT is being procured through procurement services, then that always happens that the bidders for us, for solicitation, are asked about accessibility.

10:45 - So the next piece then, step number two, is verifying the information that they provide.

10:52 - And as Lynn has said, my team, we are– I should say a little bit more about my team, I guess.

10:57 - We are accessible technology services, so we’re a small department within UW IT.

11:03 - 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.

11:14 - 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 provide the accessibility consultation that we do.

11:29 - So when we do get involved, we tend to– we evaluate products, we evaluate VPATs which we’re going to learn about today.

11:41 - And we have conversations with the service owner or manager, the people that are making decisions about what to purchase.

11:48 - And we have conversations with the vendor. And so we get involved at a very deep level, but we can only do that with really high-risk, high-exposure purchases.

12:00 - So that leaves there– probably Lynn could probably give you a number– but thousands, I’ll say, of IT purchases that don’t get subject to that level of scrutiny, but still put the University at risk if they are inaccessible and there are groups of users who are unable to use those technologies.

12:23 - So the goal in this presentation then is to educate everyone.

12:27 - At least we’ve got 18 people here today, but we’re recording this session so it’ll be available, and I encourage you to spread the word.

12:35 - But everybody who makes a purchasing decision needs to know at least a little bit about how to evaluate the responses the vendors come back with when we ask is your product accessible.

12:48 - 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.

13:00 - So as we’re talking about these things, we are going to use the acronyms that are shown on this slide.

13:06 - The W3C, that’s the World Wide 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, abbreviated WCAG.

13:24 - Sometimes pronounced a little differently than that, but that’s how I pronounce it.

13:29 - And those are the standard for accessibility.

13:33 - And we’ll talk more about those at considerable length.

13:38 - Also the W3C owns the ARIA specification. That stands for Accessible Rich Internet Applications, and we’ll talk about that in depth-as well.

13:49 - And finally, we’re– 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.

14:06 - So when you go step one in that three-step process, ask for accessibility information, typically when you do that, a vendor if they know anything at all about accessibility, their response is going to be a VPAT that they have already prepared.

14:23 - In many cases, smaller vendors are not familiar with this and so it may be new to them.

14:31 - But that ultimately is what they provide because that’s what we ask for.

14:36 - That’s part of the terms and conditions. We actually specify that a VPAT is the way to communicate whether your product is accessible or not.

14:49 - So this is actually a quote from UW Procurement Policy 7. 2. 15, and it also is included on that page that was linked from the Lynn’s first slide, UW. edu/accessibi lity/procurement.

15:10 - This is the actual language that’s included in the policy.

15:15 - And that is “University of Washington bidders and vendors shall be required to demonstrate that information technology provided to the University of Washington conforms to or addresses each of the W3C WCAG 2. 1 Level AA success criteria wherever demonstrating such performance is practicable.

15:35 - 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.

15:46 - So we’re going to explore all of this on future slides.

15:52 - But essentially, this is just laying it out there.

15:55 - It’s part of the policy that we need to meet WCAG 2. 1 Level AA.

16:00 - 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.

16:14 - And the relevance of that I’ll talk about in a moment.

16:19 - So let’s define some of these terms. WCAG 2. 1– you already know now that WCAG is Web Content Accessibility Guidelines.

16:28 - 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.

16:36 - It’s not a new thing. The Web was invented by Tim Berners-Lee in the early 1990s, and soon thereafter, he formed the World Wide Web Consortium, the W3C.

16:50 - And soon after that organization was formed, they became aware of the fact that the Web could erect barriers for people.

17:02 - And this was not the vision at all. They had intended for the Web to be the great equalizer that provided information, that everyone could have information at their fingertips, which was unlike anything that had ever happened before.

17:17 - And the fact that this could actually shut people out and could cause accessibility problems was not at all consistent with their vision.

17:25 - So very early on in– after the organization was formed, they formed a subgroup called– this is another acronym that’s not included in my list, but the WAI, the Web Accessibility Initiative, which.

17:38 - Then began working on the Web Content Accessibility Guidelines.

17:42 - So they published version 1 in 1998 and then every 10 years after that, they have they released an upgrade.

17:52 - So it’s a long process. It involves a lot of stakeholders and a lot of discussion, a lot of vetting of the ideas that are generated from those discussions, a lot of research.

18:03 - And ultimately they went from 1. 0 to 2. 0 by 2008, and then a incremental upgrade to 2. 1 in 2018, and that’s where we stand today.

18:16 - 2018, the version that was released a few years ago, is the current version, version 2. 1.

18:23 - And within that, there are broad concepts. And within those concepts, there are guidelines.

18:31 - And within those guidelines, there are success criteria.

18:34 - So the lowest level is success criteria, which are a checklist of the details of how you make IT accessible.

18:45 - 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.

18:57 - They intentionally were trying to cover pretty much anything with a user interface.

19:04 - And so a lot of the issues that are identified in the success criteria are not just web issues.

19:11 - They are software issues. They are also applicable to anything with a screen.

19:17 - An information kiosk, if it has a user interface, then some success criteria within WCAG apply to it.

19:27 - So each of the success criteria– and again, this is where the details lie.

19:32 - And there are 78 success criteria, so quite a few things to know about.

19:39 - Each one of those is assigned a level. And Level A is the highest level.

19:44 - These are the highest priority, the most critical things that are going to absolutely affect users and block them from having access if these success criteria are not addressed.

20:00 - There also is some consideration for difficulty.

20:03 - As they were coming up with the various levels, they were assigned based both on severity and difficulty.

20:11 - So you have some things that drop to a lower level, not because they’re unimportant, but because they’re more difficult to implement.

20:19 - Level AA are the mid-level of success criteria.

20:22 - And then Level AAA are either less critical or more difficult.

20:28 - So early on, when WCAG, particularly WCAG 2 when it was released with this Level AA and AAA system for tagging success criteria, there were a lot of questions about how accessible is accessible enough? Are we supposed to just meet a Level A or level AA or all 78 success criteria? There are a lot of open questions about that.

20:54 - And since that was 2008 when 2. 0 came out, we’ve had a lot of years to sort this out.

21:03 - And there have been a lot of legal complaints, including legal complaints against higher education.

21:08 - And that has all– both within higher education and without– all signs indicate that Level A and AA are the expected level that we will meet.

21:23 - This comes out again and again and again in settlements and resolutions.

21:28 - And it has found its way into policy. And so it’s become very clear now that WCAG 2. 1 Level AA is the benchmark.

21:38 - That’s what we need to strive for. If we also meet Level AAA success criteria, that’s great.

21:44 - But what we’re going to be held accountable for are the Level A and Level AA success criteria.

21:51 - So to give you a sense of what these are exactly, we need to look at some specifics.

22:00 - And 78 may seem daunting. And my goal here is to simplify.

22:09 - So anybody who’s making purchasing decisions, again, needs to be able to evaluate a product at some level for accessibility.

22:17 - And it’s unreasonable for each of those people to become an expert at the level of understanding all 78 WCAG 2. 1 success criteria.

22:30 - It’s just not going to happen. So I think there are three that are particularly important within the context of reviewing VPAT.

22:41 - And so let’s focus today on just those three.

22:46 - The first is 1. 3. 1. That is Info and Relationships.

22:52 - And that is a Level A success criteria, so the highest level.

22:56 - And this is important because it encompasses so much that is so critical when we’re talking about accessibility.

23:04 - That headings, for example, need to be coded as headings.

23:10 - So you got big, bold text that is the main heading of a page, that needs to be coded as an H1.

23:19 - And secondary headings, subheadings within that, need to be H2.

23:24 - If there’s a deeper level of headings, so you get subheadings, new sections within the Level 2 heading sections, and those would be H3.

23:34 - And so the idea with headings is they form an outline of the content.

23:39 - So that falls under this particular success criteria, as does all these other things related to semantics, as we often say 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.

24:02 - So form fields is another example where you’ve got labels for form fields and a sighted user can see that relationship because of proximity.

24:12 - But 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.

24:25 - So the label is actually attached to the form field.

24:28 - That all happens behind the scenes in the code, same thing with accessible table markup.

24:35 - 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 then down to the next row and then down to the next door.

24:48 - That can be really daunting to try and figure out where you are.

24:53 - 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 that helps the screen reader user to stay connected with all the parts and understand exactly where they are at all times within that table.

25:15 - So all those sorts of things, headings, labels on form fields, accessible table markup, that’s all using the tagging environment.

25:26 - It applies to websites. It applies to PDF documents.

25:29 - It applies to Word documents. Using that structure that semantic tagging in a way that is accessible, that all falls under info and relationships.

25:43 - So that’s why that’s so critical. It arguably is the most important accessibility issue.

25:50 - The second success criteria I want to focus on is accessibility by keyboard.

25:56 - This also is Level A, so it too is supercritical, but I’ve included this one because it’s so easy to understand and so easy to measure.

26:06 - It basically means all functionality is operable through a keyboard interface, so not using a mouse.

26:14 - So if you’ve got something, for example, a common example is a dropdown menu.

26:19 - You’ve got a navigation menu on a website and you hover over a top-level menu item with the mouse, a submenu appears.

26:28 - Then that is perhaps dependent on that mouse hover.

26:35 - So how does it work for somebody who’s using the keyboard? Can that keyboard user tab to the submenu, tab to the menu, and can they trigger the display of the submenu? And then can they navigate through the 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.

27:01 - 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.

27:10 - 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.

27:18 - Or they may just be using the keyboard pressing Tab to navigate through an application and other keys as make sense, maybe enter or space to click a button, maybe the arrow keys to move through something, up or down or left or right, maybe escape to close something that pops up.

27:40 - Those are all sorts of keys that are often supported within an accessible interface.

27:45 - So it doesn’t require any assistive technology, doesn’t require any accessibility checker tools or anything like that to test for keyboard accessibility.

27:55 - And so that is why this is here. The third success criteria is name, role, and value.

28:05 - This is 4. 1. 2. This too is a Level A issue.

28:10 - 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 other techniques and technologies.

28:33 - But ARIA is the specification from the W3C that makes accessibility possible when you have a dynamic application like that.

28:43 - And so since so many of the tools that we are purchasing 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.

29:07 - So it’s really important to at least understand what ARIA is.

29:10 - ARIA is complex. So it’s not reasonable to expect anybody making a purchasing decision to be an ARIA expert.

29:19 - There are few ARIA experts. But it’s important to understand what it is and what function it plays in the overall scheme of things.

29:27 - So I actually want to spend a little more time to just to provide that basic background of what ARIA is.

29:36 - It, again, stands for Accessible Rich internet Applications.

29:40 - It is a W3C specification. So it is mark-up that gets added to HTML to improve the accessibility for assistive technology users.

29:52 - So where HTML can do the trick, then it’s good enough.

29:57 - You don’t need ARIA. But there are places where HTML does not adequately communicate what’s happening in an interactive application, and therefore, ARIA needs to be added in order to establish those communications.

30:13 - So let’s look at an example. And I apologize if any of you are not coders, but this is a really simple HTML example.

30:22 - So hopefully it’ll be clear. But essentially we have two HTML elements here.

30:28 - 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.

30:40 - So what happens is when somebody clicks on the button which says “More info,” somebody clicks on that button.

30:48 - Then that changes the div. So that it– imagine that it is hidden by default.

30:55 - They click “More info. ” That div then becomes visible.

30:59 - So in response to clicking on the button, something has changed on the web page.

31:04 - So this is a very simple and very common interface element in web pages and web applications, hiding things by default and then exposing them when a user clicks on something, but it’s not accessible.

31:20 - If a screen reader user who can’t see the page, they land on the “More info” button and it says, “Button, more info,” they know that’s a button.

31:32 - They know that they click on it, something’s going to happen.

31:35 - But then they click on it, which they would do by pressing the space bar or the maybe the Enter key.

31:43 - And then this div appears. It becomes visible, but they have no idea that it just became visible.

31:49 - They have no idea what just happened or where.

31:53 - It’s just silence. So they click on the button, nothing happen.

31:56 - They click on the button again. Again, nothing happens.

32:00 - So they’re confused and they’re lost. The only way to make that accessible is with ARIA.

32:06 - And in this case, it’s just two ARIA attributes that get added to the HTML.

32:13 - 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.

32:24 - So you’re establishing an explicit relationship between the button and that section of content.

32:30 - The other is “ARIA dash expanded,” which is either true or false.

32:36 - So it’s true if the content is visible, that content is expanded, or it’s false if the content is hidden.

32:45 - And then that just gets changed with JavaScript.

32:48 - When somebody clicks the button, then the value of ARIA-expanded changes.

32:52 - And the screen reader then passes that on to the user to let them know the content has changed or that the item has expanded or it has collapsed.

33:04 - 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.

33:19 - So once it says “Expanded,” they can jump right to that.

33:22 - That content has just appeared. So that’s a simple example, just to give you an idea.

33:29 - Again, you don’t need to memorize ARIA attributes, ARIA controls, ARIA expanded.

33:34 - If you’re a web developer, that’s all good stuff to know.

33:37 - As somebody making a purchasing decision, you just have to know that ARIA is important for any sort of dynamic web application.

33:48 - So you’ve got three success criteria under your belt now.

33:52 - And that leads us then to evaluating a product for accessibility.

33:57 - The vendor has been asked to provide some documentation of their accessibility.

34:04 - They provide us with a Voluntary Product Accessibility Template, or VPAT.

34:10 - And this is a standard means by which IT vendors can provide documentation on whether and how they meet accessibility standards.

34:18 - 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.

34:34 - These– this is an accessibility law that required– still does require federal agencies to ensure that their IT is accessible.

34:45 - But the original set of accessibility standards for Section 508 were published around 2000 and are very old and are not WCAG 2. 1.

34:57 - So we are required to meet WCAG 2. 1 Level AA.

35:03 - And if they provide us with 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.

35:17 - So they need to provide a reasonably current VPAT that addresses WCAG 2. 1 conformance.

35:24 - And the earliest version to do that was VPAT 2. 3, so it needs to be at least based on 2. 3.

35:33 - The latest version is VPAT 2. 4, which has some enhancements over 2. 3.

35:40 - There are also, within the various versions, there are multiple additions.

35:45 - And this should be hopefully clear. If they’re there 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.

36:04 - They could fill out the International edition which encompasses all of those standards, including WCAG 2. 1.

36:11 - But ultimately, what we need to know is how well they meet WCAG 2. 1.

36:19 - LYNN MAGILL: Terrill, we did have a question in the chat, a good one from Jeremy Thompson, asking if it would be appropriate to include VPAT information, what it is and what standards are required, under our corporate social responsibility section for suppliers looking to do business with the UW.

36:40 - 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.

36:59 - TERRILL THOMPSON: Excellent. Thanks for bringing that up Jeremy.

37:02 - Thanks, Lynn, for being the person who can make that happen, right, or at least get the conversation started.

37:08 - LYNN MAGILL: Yes, I’ll talk to our content owners there, as well, and see if we can get a consensus on that.

37:14 - That would be great. TERRILL THOMPSON: Cool.

37:19 - 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.

37:35 - LYNN MAGILL: Not seeing any in chat right now, but if anybody has any, feel free to post them.

37:39 - And we have one. Has Terrill’s team looked at providing accessibility review as a service? TERRILL THOMPSON: We sort of we do that informally as a service, not as a formal service, but this is a large part of what we do.

38:00 - But there we do have to consider the fact that we are maxed out.

38:06 - And so there’s an informal process by which we take into account the level of risk.

38:14 - And so typically, we review products when it reaches a level where this is going to affect a lot of people, or potentially it’s going to affect a lot of people, students, faculty, staff, visitors.

38:27 - The more of an impact it’s going to have, then the more likely it is that we’ll take it on.

38:32 - AUDIENCE: 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.

38:44 - TERRILL THOMPSON: Right. Yeah, there definitely are conversations about that.

38:48 - But we don’t– are not offering that as a formal service at this point.

38:56 - OK, any other questions before we move on? All right, if not, this is a blank VPAT 2. 3, WCAG edition.

39:11 - And we’ve got three columns. So there’s a criteria column, a conformance level column, and a remarks and explanations column.

39:22 - And the criteria column consists of WCAG 2. 1 success criteria.

39:30 - 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 one about ARIA.

39:48 - But you can see what some of the others are, as well, as you look through that.

39:55 - How this is supposed to be filled out is you’ve got one row for each WCAG success criteria.

40:04 - The conformance level column is a multiple choice column.

40:08 - 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 criteria; it partially supports it, which means some of the functionality of the product does not meet the criteria, but maybe overall it does; does not support, means the majority of the product functionality does not meet the criteria, or it might be not applicable, or it might not be evaluated.

40:40 - It’s always great to say I don’t know if you truly don’t know.

40:45 - And a lot of vendors try to fudge through this and fill it out without really knowing.

40:51 - And we’re going to look at several examples that help us to judge how competent a vendor has been in filling out this form.

41:02 - Also that third column is arguably the most critical.

41:06 - That this is where we learn the details of exactly how their product supports or does not support or partially supports the success criteria.

41:17 - So that is there to provide detail. And in the end, we should have enough information to make an informed decision about 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.

41:40 - There’s also required metadata at the top of the form.

41:43 - And again, the instructions are very clear.

41:46 - That they actually say in instructions, there are 11 required fields.

41:51 - There are five of those in particular that I think are the most critical for our purposes.

41:57 - And those are the name of the product and the version number.

42:01 - We want to know which version they’re basing this report on.

42:06 - We want to know the date of the report. And we want a contact information for follow-up questions.

42:12 - And that’s not just a generic help email address, which sometimes vendors will provide in that form field, but we want somebody specific who can answer accessibility questions.

42:25 - And somebody filled out this form. And so that’s the person who should be identified in that form field.

42:33 - 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.

42:50 - And so that should be self-explanatory, but it is important to explicitly state that.

42:57 - So– LYNN MAGILL: We have a good question in the chat right now.

43:01 - TERRILL THOMPSON: OK. LYNN MAGILL: 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? TERRILL THOMPSON: And that sounds like a question for you, Lynn.

43:21 - LYNN MAGILL: Well, I would say that depends on how we word the VPAT language in the contract.

43:29 - I would say that if the departments are all agreeing to– if they’re all buying the same product, basically the product and the VPAT will be the same for all of the departments.

43:43 - But the accessibility standards they agree to in the contract are individual for each contract and are negotiated in the contract.

43:53 - 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.

44:06 - They can use that same contract language if they wanted to.

44:10 - And they could point to the same VPAT if they wanted to.

44:14 - 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 in each of their agreements.

44:27 - TERRILL THOMPSON: It seems like I’m a procurement outsider.

44:31 - Lynn’s a procurement insider. But it seems like from my perspective, there is a lot of siloed purchasing that happens.

44:42 - And so the same products licensed by a number of different groups within the University a lot of times, and the process is different for all of them.

44:51 - 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.

45:06 - And so one group decided this is too big of a risk, and we’re not going to proceed any further because they can’t address their accessibility problems.

45:17 - And the second group decided they’re willing to take on that risk.

45:22 - It wasn’t that big of a concern to them. So ideally, I think we would be on the same page.

45:28 - Everybody– it would be more centralized. And if the company cannot demonstrate accessibility and cannot commit to improving their accessibility, then that should be a stance that we as a University take that our policy is that everything has to be accessible.

45:49 - And therefore we can’t proceed to do business with a company that’s going to put us at risk.

45:54 - But when you get the right hand saying no and the left hand saying yes, then that sends mixed messages to the vendor.

46:02 - That’s my perspective as a procurement outsider.

46:04 - I don’t know if you have anything to add to that, Lynn.

46:07 - LYNN MAGILL: Yes. I don’t want to hijack your part of the presentation with procurement stuff.

46:11 - But what can happen with some vendors is that a lot of them will give you their standard boilerplate contract.

46:19 - And Jeremy was in procurement for a long, long time, much longer than I’ve been in, so he knows too.

46:24 - And so they’ll give you their standard form, and it’ll have nothing in it whatsoever about accessibility.

46:30 - And so a department will do the right thing, and they’ll go, OK, procurement, take a look.

46:34 - And we’ll say we need to have accessibility commitments from them, and let’s talk about liability, and all the other good procurement stuff.

46:42 - 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.

46:52 - And the other department will either perhaps go rogue, which is not recommended, or they’ll say, oh, we need this.

47:02 - It’s biennium close. We need this in one hour.

47:05 - We can’t be bothered with any of that. We’re going to waive it all.

47:08 - 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.

47:21 - 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.

47:42 - Whereas Department B does not have that recourse, and if the vendor does not have anything accessible, they have no requirements whatsoever.

47:52 - 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.

48:07 - So anyway, thank you, Terrill. TERRILL THOMPSON: You’re welcome.

48:11 - And I saw– as you were explaining that, I saw the number uptick on the chat.

48:16 - Was that a follow-up question or? LYNN MAGILL: 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 in negotiations if another department uses the same vendor.

48:30 - And it would. I know some departments are looking at tracking licenses and other items.

48:36 - And that’s another reason why it’s often good to go through procurement as soon as possible.

48:42 - 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 agreed to it with Department A and that’s the least we’re going to take.

48:55 - We already have set a standard for terms and conditions.

48:59 - And we know it’s possible. So we want at least that level of protection in any other contract we sign with you.

49:06 - 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.

49:16 - And currently that’s on us and our records to do that.

49:20 - But as Jeremy indicated, it would be very nice to have some type of database for a lot of these terms as well.

49:28 - TERRILL THOMPSON: Indeed. LYNN MAGILL: Come on, financial transformation.

49:32 - TERRILL THOMPSON: Yep, I second that. OK, so let’s look a little closer at this VPAT then.

49:40 - We got three columns and we’ve got the required metadata.

49:44 - And so we have a general idea of how the structure and how it is supposed to be filled out.

49:50 - And so a quick guide to reading of a VPAT, you could ultimately 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.

50:06 - And that ultimately is what should happen. But often you can learn a lot just by following some really quick steps.

50:13 - And you don’t have to dig any deeper because you learn so much just through these steps.

50:19 - First of all, did they include all required metadata? So again, there are 11 required fields, five required fields on my list.

50:28 - Did they did they provide all that? If they didn’t then that’s telling, perhaps just in their ability to follow instructions.

50:37 - But I think it also gives us a clue as to whether they’re familiar with this form or not.

50:42 - If they’re cutting corners and not filling it out properly and not providing all the required information, then that in and of itself sends an implied message about their commitment to accessibility, I think.

50:58 - So related to that, did they fill the form out properly? Again, conformance level is a multiple choice question.

51:06 - If they entered something else in that column, they don’t understand how the form works.

51:13 - And finally, this is where a lot of vendors fall short.

51:17 - The remarks and explanation column is key to us understanding the limitations of the product.

51:25 - And so it needs to be sufficiently detailed so we can make an informed decision.

51:30 - And if they provide very little detail in that column, and we still are left with lots of questions, then that’s not– it’s not correctly filled out.

51:41 - That’s– it really is impossible for a single forum to tell us everything we need to know about a product.

51:46 - And so this is a conversation starter. VPAT is not the answer to whether a product is accessible.

51:55 - It is the start of a conversation that you can have with the vendor.

51:59 - So part of what we want to explore here as we look at sample VPATs, what can we learn from these VPATs and what follow-up questions emerge from what we see here things that we need to more information about.

52:16 - So the third step then, is to look a little closer at just a few specific success criteria.

52:22 - So just to simplify things, you can hone in on these three success criteria that we have talked about.

52:29 - Because 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.

52:39 - And as you’re doing that, questions to ask yourself are, first of all, who completed this VPAT? Sometimes vendors will have an independent accessibility consultant do that for them.

52:51 - And that is preferred because they– even though they’re getting paid, they are independent.

52:57 - They do, presumably, have no bias. And they’re going to give us an honest evaluation.

53:04 - And did they follow the instructions? Again, that does communicates something about their commitment if they just blaze through it and didn’t pay attention to the details.

53:15 - Do they seem to be knowledgeable accessibility? Or are they’re answers to the prompts a little off, like they don’t really seem to make sense as you understand 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.

53:48 - That is too generic, and it’s a yes/no question.

53:51 - And so probably, if you’re talking to sales, they’re going to say yes.

53:55 - And then they’re going to hope somebody can back them up with actual information.

53:59 - But if we ask a– there are better questions to ask that can get better answers.

54:07 - For example, in your VPAT, you said this, related to 1. 3. 1 Info and Relationships.

54:15 - Could you please elaborate on that? What are some specific examples of how your product meets the success criteria? Also getting beyond just the product– and this is really important also– and looking at the company, because 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 the product lifecycle as it goes back around again, then we’re going to be facing this problem again of inaccessible new products coming out of this company.

54:54 - So we want a company that understands accessibility and is committed to it.

54:58 - 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 a deliverable.

55:08 - So to get into that, these are more human questions, not technical questions and not requiring accessibility expertise.

55:16 - But just tell us how your company addresses the need for accessibility throughout the product lifecycle? And what is your methodology for testing your products for accessibility? 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 experience there are some companies who can answer these questions.

55:45 - They sound like really hard questions, like we’re trying to stump the vendor.

55:49 - But there are some that could elaborate extensively on all of these.

55:55 - We’re actually using– right now we’re using Zoom.

55:57 - And so that’s a good example where they could go into great depth about all of these questions.

56:06 - And they have a committed accessibility team, which actually includes quite a few UW grads who have worked– three people who have gone on for being students on our team have gone on to work for Zoom as part of their accessibility efforts.

56:22 - But– and that’s– there are many other examples, too, of vendors who understand accessibility and have integrated it into their culture.

56:30 - But there also are a lot of companies that are not so mature when it comes to accessibility.

56:36 - And it’s pretty easy to spot that. So here’s an example.

56:41 - We have six examples that we’ll have a look at here.

56:46 - The first is a two-column VPAT. And we know that this is supposed to be a three-column report.

56:55 - They’ve left off the most critical column of all– didn’t provide us any remarks or explanations about their claims here.

57:02 - So they’ve got a few things that they say they partially support, other things they say they support.

57:09 - But regardless of what their answer is there, we need to know the details and they didn’t provide the details.

57:16 - And these are all actual real world VPATs that we’ve looked at over the last year.

57:22 - Here’s another one that have– they have a remarks in explanations column, but there’s– 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.

57:39 - All the others should have some details. They didn’t provide those details.

57:44 - So both of these are examples of bad VPATs that should– if you’re comparing products and you’ve got Product A, B, and C. Product A and B have actual VPATs that follow the instructions and include information that’s meaningful, and otherwise the products are equivalent, then I would toss out Product C for a VPAT like this.

58:14 - Example three, here we have an actual answer to the keyboard success criteria.

58:20 - And they say it partially supports. And they say all the functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.

58:30 - So they’re accurately described– sort of paraphrased the success criterion.

58:35 - So they know what they’re talking about, it seems.

58:38 - Then they say, “However, there are minor exceptions.

58:42 - For example–” And so this is where the detail comes in.

58:47 - What are the exceptions? This is the kind of thing that we want, because now we can know, OK, not just that some things are not going to be accessible with a keyboard, but what things are those and how critical are they to the functionality of the application.

59:03 - So the exceptions are the calendar widget on the manage section is not keyboard operable.

59:09 - However, alternatively, the date can be directly entered into the date field.

59:15 - So first of all, if they hadn’t included that “however” statement, they just said the calendar widget is not accessible with a keyboard, then my follow-up question will 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.

59:41 - If a person can’t access the calendar widget, they can enter the date directly, so not really a problem.

59:47 - They’ve got it– identified a minor problem, but they’ve also identified the solution.

59:53 - So this is a really good example. I would be pleased with this response.

59:59 - Here’s one with that 4. 1. 2 Name, Role, Value success criteria.

60:05 - So this is the ARIA success criteria. And they say their product partially supports this.

60:13 - The web application provides the correct Name, Roll, State and other important accessibility information for most form controls with the following exception.

60:21 - So similar to the one we just saw, it says there are some exceptions.

60:26 - And here are the exceptions. Dynamic filter results are not announced to screen reader users.

60:33 - Some calendar widgets are not using appropriate roles.

60:36 - And this actually goes on and on and on and on.

60:39 - It’s a very lengthy list of exceptions. And so the issue I have with this is, is this truly “partially supports?” It almost seems like if you got– there is a fuzzy line between “partially supports” and “does not support. ” But when you reach a certain number of exceptions, they become the rule rather than the exception.

61:05 - And so I would argue that maybe this is actually “does not support. ” But it might be worth having the conversation with the vendor.

61:12 - They do seem to understand the success criteria.

61:15 - And so I trust their evaluation here. And I trust their reporting.

61:20 - And I appreciate the transparency of their reporting.

61:24 - But I want to know more about how critical all these exceptions are, because it sounds like there’s so many of them.

61:30 - It sounds like it’s going to be really hard for somebody who is using assistive technology to perform the essential functions of the job.

61:39 - So and to remind you, we are– I don’t know that we actually talked much about laws and policies.

61:44 - But we do have all of the legal settlements and resolutions that say we need to meet WCAG 2. 1 Level AA, and so that falls under the Americans with Disabilities Act and Section 504 of the Rehabilitation Act.

62:01 - So we are under federal law to ensure our programs and services are accessible.

62:05 - But beyond that, we have a state policy, Policy 180A, 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 AA.

62:22 - So it’s spelled out there as well. So we know that we need to do this.

62:28 - But being realistic, very few products, if any, fully meet WCAG 2. 1 at Level AA.

62:38 - And that’s our goal. And our policy actually expresses that as a goal.

62:45 - That’s our target. We are working towards that.

62:50 - But it– probably every vendor is going to fall short.

62:55 - And then the question becomes really just one of functional accessibility.

63:00 - 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 their computer entirely with voice, how are they able to perform the functions that this product or service requires? 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 then it’s a question of degree of severity and of level of risk that we’re willing to take.

63:42 - So if a product falls short in some areas, that’s expected.

63:45 - But those can’t be critical errors that are going to be showstoppers and prevent somebody, some groups of users, from being able to perform the essential functions made possible by this application.

64:00 - So the next example here has three success criteria.

64:04 - There’s one for captions. There’s one for audio descriptions.

64:07 - And both of those are video related. And then there’s the one we’ve been looking at, info and relationships.

64:15 - So I want to mention, I’ve included the first two here in the screenshot because they are not applicable.

64:24 - This is not a video product. And so captions and audio description are not applicable.

64:29 - And it says that in the remarks and explanations column.

64:33 - But they chose to express that as “supports” instead of “not applicable. ” And that’s subtle, but it’s kind of like reading through advertising with a critical eye.

64:46 - And to me, it could– this could be an honest mistake.

64:50 - But to me it seems they chose “supports” intentionally, because if you look at a VPAT and it has supports on almost every success criteria, that looks like a really accessible product.

65:03 - And so they’re trying to spin it that way, when in fact, it should be “not applicable” for those two success criteria.

65:11 - So keep a critical eye as you’re evaluating VPATs.

65:15 - On the Info and Relationships item, this is actually similar to a previous example where they have a very honest and transparent list of exceptions, but it’s a very lengthy list.

65:30 - And this actually goes on and on and on for several pages, all of the exceptions.

65:34 - And so again, I question whether “partially supports” is the right label there.

65:40 - Probably it should be “does not support,” but that’s a conversation that needs to happen.

65:48 - The final example goes back to the keyboard success criteria again.

65:52 - They say that their product partially supports this, and they explain why.

65:57 - It’s because users can operate all functions in the product using a keyboard through standard controls.

66:04 - A rating of “partially supports” has been given due to the following isolated issues that do not substantially hinder use of the functionality.

66:12 - And so that again, I keep saying that’s really the heart of my question is does this hinder a person? Does it block a person or 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.

66:28 - I want to know more, and they provide more.

66:30 - They say the publication’s import functionality is not operable for the keyboard alone.

66:36 - User users may elect to not use this functionality and complete the task of entering publications manually.

66:43 - So that sounds OK, perhaps. They say that that’s not critical, but I do want to know more.

66:50 - Is it really– is the process of entering publications manually, not using the publication import functionality, is that equivalent? Or is it going to 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, than it’s not really equivalent.

67:14 - And then we’re going 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 a keyboard alone, but keyboard shortcuts do exist.

67:29 - And users may elect not to use this functionality.

67:32 - So the fact that keyboard shortcuts do exist seems to actually contradict the fact that it’s not accessible with a keyboard.

67:39 - I think if you can perform the same functions with a keyboard shortcut then that is probably satisfactory for making that accessible by keyboard or claiming that’s accessible by keyboard.

67:53 - So I think probably that’s not that’s not really a huge problem.

67:57 - 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.

68:06 - So I want to see the roadmap I want to know when they expect to fix those.

68:13 - Can we get a timeline for what issues they plan to fix and by when? And that will really help us to evaluate our risk.

68:23 - Maybe there are some critical issues that are included on that roadmap.

68:27 - And maybe we want to delay our deployment until they have satisfied those issues.

68:33 - Or maybe we want to make the– our doing business with them contingent upon them fixing those issues and sticking with the timeline that they’ve identified in the roadmap.

68:46 - So it’d be great. And we actually have some history of this.

68:50 - And this falls to Lynn and crew within procurement services.

68:55 - But actually getting into the contract, this roadmap, incorporated by reference so that they are held accountable for meeting the timeline of the things that they have pledged to fix.

69:09 - And really that’s the ideal scenario, I think, because so few products are fully accessible.

69:14 - There are always going to be issues that need to be resolved.

69:18 - And so having a road map that you negotiate with the vendor that identifies the biggest priority issues and documents a timeline by which we could expect those issues to be resolved, that really is the best outcome, I think.

69:35 - LYNN MAGILL: We do have a question in chat, good timing.

69:40 - We have a question says, do you find that if products aren’t designed to be accessible from the beginning, then the VPATs are just disasters? TERRILL THOMPSON: Yeah, I think that probably– that may be an oversimplification, or it may not be.

69:57 - I think that probably is more often the rule, rather than the exception.

70:02 - That there are a lot of products that– a lot of vendors that really don’t– they have not thought about accessibility.

70:10 - That’s the first time they’ve ever heard of accessibility.

70:13 - And that shows both in their VPAT and in their product.

70:18 - And I can almost guarantee that if the converse of what the question says.

70:23 - But if the VPAT is bad, if it’s one of those like the VPAT with the third column missing, then the product is also going to be bad.

70:34 - It’s going to be a reflection of the fact that they really don’t know anything about accessibility.

70:38 - So there definitely is a correlation there.

70:46 - LYNN MAGILL: I really liked your example about getting the roadmap into the contract.

70:52 - 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.

71:00 - And so we have repercussions, and we have options, basically, in case they don’t meet those timelines.

71:10 - TERRILL THOMPSON: And I think we have actually made payment contingent upon meeting the goals within a roadmap.

71:18 - If I’m not mistaken, that happened with at least one vendor.

71:21 - And I know of other institutions that have attained that, too.

71:24 - That’s a difficult thing to get a vendor to agree to.

71:28 - But if they’re confident in their ability 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.

71:41 - But we’ll pay you if you meet the obligations for an accessible product that you have outlined here.

71:50 - These showstopping issues, if you fix those then, we’ll pay you.

71:54 - Otherwise, we won’t. LYNN MAGILL: Yes.

71:57 - That’s– I am seeing that more and more. And it’s a new concept for IT vendors.

72:03 - It’s starting to trend. It’s very common in all other industries, especially service, consulting, construction.

72:11 - They’re very familiar with that. IT vendors are not as familiar with it.

72:16 - 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.

72:29 - TERRILL THOMPSON: OK, well, any other questions? I actually didn’t do too bad on time, just 15 minutes over the top of the hour.

72:36 - This by the way, I don’t know if you want to watch a rerun, but it will be– the video will be archived.

72:43 - It’s going to be up on our access technology website in the webinar archives page.

72:53 - There’ll be a link to it from there. And that will include the slide deck as well as the video.

72:57 - And so you can send– if there are other people that you work with who make purchasing decisions, then feel free to send them to the video as well, so they can watch this and get the information.

73:11 - And I’ll type that your URL into to chat as we’re giving a couple more minutes for questions if anybody has them.

73:29 - Hopefully that’s the correct URL. I did it from memory.

73:31 - So if somebody wants to try it and see if it works, that’d be great.

73:37 - COLM FLYNN: If it work– TERRILL THOMPSON: Awesome.

73:39 - LYNN MAGILL: Just tried it and it works. TERRILL THOMPSON: OK, great.

73:43 - Well, thanks, everybody, for coming. It was a great, great conversation.

73:47 - I’m glad it was cooler today to do this, rather than having to do it in 100 degree heat.

73:52 - But hopefully it serves as useful information for you guys.

73:58 - COLM FLYNN: Thank you, Terrill. .