- [Mike] Thank you for joining the webinar today, we will begin momentarily. Thank you for joining the webinar today, we'll begin momentarily. All right, good morning, good afternoon, everyone. My name is Mike Mooney, I'm the Digital Marketing Manager at TPGi. And I wanna thank everyone for joining us today for this excellent session on VPAT 101: Introduction to the Voluntary Product Accessibility Template. Our speakers today are Brian Elton and Mitchell Evan, senior accessibility engineers at TPGi. And before we get started, I just wanna go through a couple of housekeeping items. The session is being recorded and will be emailed to everyone after this session. We do have live captions available and you can use those as needed. And lastly, if there's time at the end of the webinar, we will do Q&A. Please use the Q&A box provided by Zoom to submit your questions that our experts can answer at the end of the session. And if anyone needs any accessibility support or VPAT questions, feel free to reach out to us after the webinar and we can help you and support your goals. And with that, I will let Brian take over, Brian. - [Brian] Great, thank you very much, Mike. Hi everybody, good morning, good afternoon or good evening, depending on where you're joining us from. Welcome to VPAT 101: Introduction to the Voluntary Product Accessibility Template. As Mike already mentioned, my name is Brian Elton and I'm a Senior Accessibility Engineer with TPGi and I'm joined today by my colleague Mitchell Evan, who is also a Senior Accessibility Engineer at TPGi. - Hello. - Say hi. Oh, there he is. Mitchell's located in Berlin, Germany while I'm located in Toronto, Canada. So we've got a good part of the globe covered and hopefully we've got participants from all over the place as well. All right, so let's get started. What are we gonna talk about today? Here's our agenda. First of all, we'll just have a quick little introduction to what is the VPAT, we'll talk a little about why should I use a VPAT, a little short history, we'll talk about some of the parts of the VPAT, what makes up the actual report, how do I go about getting a VPAT report and finally, we'll wrap it up with, when should we get a VPAT report? So Mitchell's got up first, so Mitchell, what is a VPAT? - [Mitchell] What is a VPAT? That's what we're here for today. As mentioned before, it's an acronym that stands for Voluntary Product Accessibility Template, it is a template. If you wanna be strict about it, it's a template for creating an accessibility conformance report or ACR, that is it's like a resume or a CV for the accessibility of your digital product. It lets people know how accessible your product is for people with disabilities, that's its main and overarching purpose. And what kind of digital product are we talking about. And go to the next slide. Web based products, websites, and web applications, software as well, including especially mobile apps, native mobile apps, hybrid mobile apps. It can cover electronic hardware products like kiosks, personal computers, even telephones and office machines and all kinds of digital content and functionality. For example, communication platforms, like the one we're on here, any video, email, email campaigns, training content, any kinds of documents or the tools that create these things, content creation tools. And so when you think about the world we're in, always more digital than ever, that's always a truth. It's absolutely essential that all of these kinds of things work together and work well for everybody, including, especially people with disabilities. And so that's what VPAT can help in that process. So go ahead to the next slide, but why and how? Why we should use a VPAT as part of this accessibility effort. Why use the VPAT for reporting on accessibility? - [Brian] So as a product owner, you may have potential customers or buyers looking for documentation on how accessible your product is and you could provide this in any manner. So why should I use a VPAT? Well, the number one thing is that it's standardized way of reporting. So customers and buyers, they can make preliminary assessments of these products that Mitchell had just talked about, these products and services, and they could look got it in a known format. So it makes it easier for those potential customers or buyers to compare products from different sellers. And as a seller, somebody who's wanting to get your product out to multiple customers or buyers or whatnot, it saves you time because you can prepare a standard VPAT once and use it for multiple buyers. So that will help you compete for business and especially as we'll talk about it a little bit later, especially in the public sector, but what are some other benefits of the VPAT? Well, a really great one is that it shows transparency and a demonstration of commitment to accessibility. And it could also be used as a baseline for your internal accessibility policy. So if you have a VPAT that's been created, and it has some understanding of what is good and what is bad about your website, you can use that to help determine where you put your focus on fixing those accessibility issues. So Mitchell, how did we arrive at this standardized report? - [Mitchell] Well, we started to touch on the reasons and motivations for having one. And it really all started back in 1998 when the United States federal government began using the Section 508 regulation. It required since then government agencies to buy accessible digital products as much as possible. The federal government had some of the challenges that Brian just described, how to compare those products and get an initial read on their accessibility. So pretty quickly in the next couple of years, voluntary organization, I'll call the Information Technology Industry Council in collaboration with the federal government came up with this format that was called the VPAT at the time. And by the way, the registered trademark is still owned by that organization. And they allow anybody to use it to create reports in that format. Fast forward to 2017, so just five years ago, the US federal 508 regulations caught up with a changing digital world and harmonized with the Web Content Accessibility Guidelines version 2.0. So really caught up with that global standard and that change in the standard spurred complete rewrite of the VPAT template itself. So now with that rewrite, and go to the next slide, it's not just for Section 508 US anymore. 508, yeah, uses WCAG 2.0, Europe uses WCAG 2.1. You can focus just on WCAG, the Web Content Accessibility Guidelines, or combine them all in one report. And later on, we'll see how to choose where you want to focus on these different standards, but just know that the report is capable of all of these things. To start to show how it does that, we'll talk about the different parts of a VPAT report, what the template supports. Brian, you wanna talk about that? - [Brian] Sure thing, so a complete international VPAT, so the kind that Mitchell had just described, which includes all different types has four sections to it. So the first section is the cover page and outlines important information such as, name of the product or the version. Now this could depend on the type of product that you have this VPAT for, websites typically don't have versions. So we don't have a version for that, but if you have an application of some sort that has a version to it, then you wanna make sure that you specify that here. I also have the report date, now this would be definitely important for products that don't have versions such as websites. So the person who is reading this report will understand how recently this report was created. And some other items, product description and contact, but also the evaluation methods used. Which is an important part because as a buyer you'd want to ensure that the methods that were used to create this report match what your users use. So for instance, if you have users that are primarily JAWS screen reader users, but this report was created only using the NVDA screen reader, then you may wanna dig a little bit further into the report or into some of the things it talks about just to make sure it conforms just as well with JAWS. Now, I say that, but really the reports should be created using multiple screen readers just to ensure that we've got everything covered. We'll talk about that more in the next section with Mitchell. The next section is all around the WCAG or Web Content Accessibility Guidelines Success Criteria. So this is a table that has all of the criteria that are listed out, including AAA, there will be 78, but we don't necessarily do AAA, but there's a bunch of Success Criteria in the table along with a conformance level and remarks and explanations. And we'll talk a little bit about that as we go forward. Now, you can look at here in this full template before any edits have been made, shows that each one of the criteria we have where it also applies, and these we refer to the other sections within the report. So as we fill out something that has to do with non-text content, which is things like images, something where we might need some alternative text that would also apply in the EN301 549 criteria, that's the European standard, you would apply in those listed sections there, same thing and similar for Section 508. We'll see other sections that this particular Success Criteria would apply. So then may go to these next sections. So the third section here is the Section 508 report or part of the report. And this table here basically is broken down into functional based criteria, some are fairly generalized, and there are other that are more specific. So something more specific could be the ability to reach forward or an alternative user face in the software section. And these conformance levels are based on what has been entered into the WCAG table and could include multiple Success Criteria. So as I showed in the last one where the non-text content Success Criteria applied to certain sections of report, there are other Success Criteria that could also apply to the same parts. So for example, this first one 302.1, without vision, it would include Success Criteria such as the non-text content that we just saw and audio description, which is for prerecorded content, also for users who can't see. So both of those could be combined together along with anything else that has to do with users without vision. All of those conformance levels on the WCAG report would be combined to determine the conformance level within the Section 508 part. And then the fourth section is the European standard, this EN301 549 and this is very similar to 508, it's well aligned, there's some different wording, but it's still functionally based. And again, we use the Success Criteria from the WCAG section, the conformance of those different Success Criteria to then determine the conformance of these functional based sections of this report. So when we talk about the ratings, so the conformance, we have five options, supports, and I'm gonna read these out, they are quotes directly from ICI, the trademark holder of the VPAT. So just for clear understanding. So supports means the functionality of the product has at least one method that meets the criteria and without known defects or meets with an equivalent facilitation. I can come back to that in a second. Partially supports means some functionality of the product does not meet the criterion, does not support is the majority of product functionality does not meet the criterion. Not applicable, the criterion is not relevant to the product. And then non evaluated, the product has not been evaluated against the criterion. And this can only be used in WCAG 2.X level AAA. So when we are writing a VPAT, we are looking at WCAG Success Criteria that fall under A level, AA level, but we don't necessarily have to do for AAA. So if we decided that you're not doing a AAA evaluation for your VPAT, then that can be listed as not evaluated, otherwise all do every other Success Criteria and A and AA need to be included. So when we talk about the remarks and why a certain, this is a place where you can fill out why a particular Success Criteria or part of the 508, or the European standard reports, why it has the conformance level that it does. There are many different writing styles that could come into how it's explained. But really the key point is to give the readers of the report the information that they need to understand how accessible the product is. So when we see here we got to partially supports and does not, they're both considered a fail rating, as in there are parts of, at least under partially supports, there are parts of the product or website that do not meet the criteria. And so the remarks are crucial for understanding where it fails. A supports rating should also have remarks, because there are maybe cases where you do need to explain, as we noted it could be either that the criteria is supported or there is an alternative method that allows the user to accomplish the same thing. So where something like that is the case, we would use the remarks to explain why it is supporting, even though maybe directly there are some issues. If there's alternative methods that allow the product to pass a certain criteria. Then we just have an explanation there. The not applicable rating, that basically just means that the product doesn't have content relevant to this criteria. But one possibility could be anything having to do with video or audio. So if say your website has no video or audio components to it, then we can mark that as a not applicable rating. Now I say that, and then there is somewhat of a new directive from ITI that supports, actually should be used in place of not applicable when the criterion applies to the type of products. So if there's no video, then the argument is you could use supports because it does support that particular Success Criteria, already the Success Criteria that have to do with video. So you may see some that use not applicable, you may see some that use supports, either way it shows that there will be no issues with that particular Success Criteria as has to do with your product. Okay, we've talked about that a bunch. Now here's an example of back to that non-text content Success Criteria from the WCAG table. We can show here that if this is a web product, then we are going have under the criteria, we see the non-text content Success Criteria for WCAG, but we see it also applies to the different sections in the European and in the Section 508, having to do with web and 508 also has to do the software, but this is also applying in this particular case to the web portions of 508 and the European part. The conformance level here is an example we're putting partially supports and with an explanation. So the explanation is non-text content that is presented to the USer generally have a text alternative that serves the equivalent purpose with some exceptions. So right there, we're saying that generally speaking say all images for instance, have appropriate alternative texts, except for a few occasions and here we can list them out. So suggesting perhaps some image based controls with missing or inadequate text alternatives, or some image based links that do not sufficiently convey their purpose, so that there's not proper non-text content, not proper text alternative. All right, so that's a really quick overview of what a VPAT looks like and what the different sections are, and a little bit about how it would be filled out. But there's so much are involved and one of the things is how do I go about getting a report? And I'll turn that back over to Mitchell. Mitchell, do you think you might be on mute in case you're talking? - [Mitchell] I am back, thanks, Brian. Yes, how to get a report. Remember that a report is a summary. It's got these really high level pass, fail ratings, similarly general remarks, it is a summary. To get that information you really wanna take a step back and start with an accessibility audit. What is an accessibility audit? It's an evaluation of the content and functionality of your digital product. And think of this like bug testing is where you really wanna find where are any known issues in the product from which the VPAT is then prepared as a summary, a list of the results of that audit. As we've seen, the VPAT has a choice of accessibility standards, and you wanna know this before you even begin testing, there's a lot of overlap as we've seen but there are some differences. So you would want to know that before you begin the testing. The easiest recommendation that I give is to use all of the standards, Web Content Accessibility Guidelines, WCAG and Section 508 and EN301 549. And why would you want to do that? You could choose based on specific customers that you're selling to, or specific regions in the world where you're doing business. Now you can easily see that, well, today, you might have one customer, but you'd like to have 10 and where will they be? They may be all over the world. So right out of the gate, that's a good reason to go with the international version. And it makes it pretty easy to do so. Every one of these standards all use the shared common denominator WCAG level A and AA. Federal government only requires 2.0, but 2.1 includes all of 2.0. So if you've done 2.1, you've covered all your Success Criteria for everybody. And as we've seen in the examples that, or taking that non-text content example that Brian showed, it's really, really most of the time you're answering one question that covers all three standards simultaneously. And so you've really covered the world. So that's a really strong way to put your best foot forward is to use all the standards. Okay, so back to the audit. To prepare for the audit, you can go to the next slide, you wanna identify a sample for testing. It's not expected that you test every last edge case of the product, but that you get a representative sample of the different page layouts, the different types of content and all of the key functionality of your product to really portray its level of accessibility. And also knowing what your standards are, you wanna not forget some specific functions of a digital product, which are required. You'll find it by the time it's time to write the summary of the VPAT summary that these are essential for both the US and the EU accessibility standards of product documentation, like online help. You'd probably naturally want to include that, but sometimes we get a question, well, the help system, that's not that important, is it? Well, it is important and it's specifically called out separately in the reporting. So you don't wanna skip it. Easy to miss though also is support services, that could even include on not just online chat support, but even regular phone line support. There are specific criteria for how those services support your users, your end users with disabilities. So I don't wanna forget that. I mentioned this term authoring tool. Most people would think of an authoring tool as a dedicated tool, like a website builder or a content management system, but within the way these accessibility standards, again, both the US and the EU define it, it's anything that allows a user to create or modify content. So for example, if you even have, let's say a rich text editor on your website where one user can type something in and another user sees it, you're gonna need to describe the ways that that content creation will allow one user to create accessible content for another, so that's something, again, if you know which standards you're going toward, don't miss that in your evaluation. And by the way, it's really important for your buyers and your users. And last, as a special category, another question, that you might miss if you were just testing your code for bugs is third party content and code that is integrated into your product. This is important for all the standards, including WCAG. And even if you don't write the code yourself, but you have chosen the vendor that makes you the creator of your product, responsible for those integrated products. A great way to save time in doing this, well, you would need to evaluate those parts that you've integrated, or you could ask your third party vendors for their VPAT reports. I'm seeing this, for example, a lot in the financial industry where financial industry will go to their integrated providers and say, "Hey, we're gonna need your evidence that what you're selling us is gonna result in our accessible product." Starts to create an accessibility ecosystem. Okay, so those are some things that you want to make sure to cover in your audit evaluation. And I'll briefly talk about the testing procedures. This is a broad and deep topic in itself, of course, and really just to make the point here that a common question with folks starting out on this is, wow, there's all these tools I can use to do automated testing. And we provide one, for example, called ARC Toolkit from TPGi, those pure automated tools will never answer all of the questions, both from a user perspective and from a VPAT reporting perspective. So really the key point here is you always need manual, automated testing is very effective at some of the criteria or even many, but it will never be 100%. And so you always need to do manual testing, human testing as well from experts like we do all the time for TPGi. And other techniques include examining the HTML markup on the web and using assistive technology like screen readers that Brian mentioned. Again, not going into a lot of depth on how to do an audit of that sort, but just to say, that's what an audit should look like and include those things. And now we're getting ready to actually create the report based on what you found. What makes the VPAT report good quality, something that your buyers or customers can trust. So what we just talked about is how you went about the audit. Well, disclose that, disclose the testing methodology, provide clear remarks, like to justify the ratings like we saw. In most cases we do recommend that you work with reputable third party auditor, it gives you independence, gives you an assurance of the testing and the reporting are gonna be of high quality. And it does name recognition like a company like ours, TPGi, that's has been around for many years, got lots and lots of this work is recognized as a, that the report someone's reading is a trustworthy report, reliable and accurate. And keep up with the current version. If you're on an agile release cycle and it's releasing constantly, this isn't gonna happen. But so it's understood that if you're looking at a VPAT report that is weeks or months old, the product that it refers to has changed in the meantime and your buyer may ask you to say, "Hey, what's new and what's different?" But it's also understood that by and large that's gonna be still a fairly accurate report, but you can't let it go too far out of date. So those are some things, the recent see as some things that contribute to making your report reliable. Common question that we get, we go to the next slide is, well, what do I do if we do this audit, we have some issues and the VPAT report is gonna list some accessibility problems? Do create your report if accessibility is essential for buyers to evaluate and users to be able to use it. But some companies are just starting up their accessibility journey. What happens if the report contains such problems? My advice is to focus first on the end user experience from the perspective of people with disabilities and not just as a box checking exercise, that's gonna get you to something that is gonna work for people. And really accessibility buyers can still accept your product with known defects. For example, if it's a US government buyer, they can choose a product which best meets their requirements, best meets is not identical having zero bugs at all, and be ready to say what's your plan and timeline for fixing those issues. So back to that idea, hat the VPAT can be a baseline. If transparency is important, if a company is asking you for a VPAT, know that that you'll never succeed in selling to them if you don't provide one, and you can succeed, even if there are known flaws that you have a plan to work on. That gets us into timing questions. And for this, I'm gonna turn it back to Brian. When should we content creator get a VPAT report? - [Brian] Well, let's answer another question first, and that is, do I need a VPAT? Well, that answer is yes and no. The V does still stand for voluntary. And so, while the accessibility of your product is a legal requirement, your product does have to be meet a certain level of accessibility legally, a report that shows that level of accessibility, that is not a requirement. Now I mean, as Mitchell was just talking about, when the US public sector companies, when they're buying, they will require a VPAT with Section 508, that is something that's been in place for a very long time. And this is what they use to determine whether a product is accessible or is the best option as far as accessibility goes, from what options they've been given in order to buy software or services. So in that case, you would need a VPAT. And with these reports, there isn't a specific way that you have to provide them. I mean, you can have a link directly from your website to the report, or you can just have it at the ready and provide it on request. So back to the question of when to prepare a VPAT report. So if you decided that you need one, you would like if you'd want one, which is great. when should we do it? Well, we have some options, we could wait until a customer asks for one, but the risk there is that an audit that is necessary to prepare the VPAT, it takes time. And especially if you have a complex website or complex product. As Mitchell was saying, the audit has to have a representative sample of that product. And if it's a big product or a complex product, then that could be quite a bit of bits and pieces and components that need to be audited. And that could really take some time. And then you also, if you wait until somebody requests it, you don't actually know what your accessibility status is at that moment. So again, it puts you at a little bit of a risk. Another option is you could do the audit. So you've got that information at the ready, and then do your VPAT when you've been asked for one, or I mean, as we would recommend, be proactive. So this is the best way to go about it. Get an accessibility audit, use that to improve your product accessibility. Also use that to prepare a VPAT report and update it regularly. So continue to get accessibility audits so that you can regularly update that VPAT so it stays current, but the availability of this VPAT will also inform your current users of your accessibility progress. So if you have somebody that's already using your system or has already purchased it, and they knew what an accessibility was at one point as updated and are proactive with it being updated, they'll also have the benefit of seeing perhaps new features that have been implemented, or things that have been fixed in order to make your product more accessible. And of course, this all comes down to allowing you to gain that competitive advantage. And with that, we've come to the end of our slides and we can now open it up to questions. I see we do have a bunch in the Q&A section. There is also some questions in the chat. I encourage anybody who asked a question in the chat. Could you also maybe ask it in the Q&A, we'll just use that one as our queue so to go through the questions. I don't wanna miss any, and we have about 20 minutes or so, which is great. - [Mitchell] Great, I'm gonna highlight one that I saw on the chat already 'cause it follows Brian on what you were just talking about of the being proactive and the question was, how often do you recommend updating your VPAT reports? I can say that it's gonna vary depending on how much and how fast you are changing your product. So a very stable product that has really minor updates, from time to time might last for years. But I think a a yearly update of the VPAT is pretty common for people who are paying attention to their accessibility but I would think of it more, another way to think about, actually doing it on a schedule is a good way to do it. Another option for how to think about it is I know based on major release, which might be yearly, but might not. I know when something significant changes in your product, that warrants a change, warrants an update. Those are a couple ways to think about it. - [Brian] All right, let's go to the first question in the Q&A part. Is the expected use of assistive technology acceptable as part of supports? If something isn't accessible or usable as is, but it is if used with speech recognition software, screen readers, et cetera, is it considered acceptable to consider ICT conformant and or accessible if it is usability is dependent on IT? - [Mitchell] That's a tricky question. So an example would be you tested with JAWS and JAWS used kind of get its magical guesswork to repair a faulty webpage. I think this would get back to trustworthiness and transparency. If you were going to claim something that, I wouldn't pass that, but whether you passed it or not, that would be worth mentioning in the remarks. So remember the conformance level is a very blunt instrument. It's even less detailed than an ABC grade or a one, two, three grade if we're in Europe. It really doesn't say much, however you decided to answer that question and they might answer it differently on different exact situations and criteria. If you were getting into that distinction, you really wanna say in remarks how you came up with the answer. Brian, do you wanna add anything to that? - [Brian] No, I think you, you covered it all. - [Mitchell] Yeah. - [Brian] Okay, next question. Just talking about the use of partially supports or does not support values, summarize this. Oh, well, I'll just read it. I've used the formula of if more than 50% of pages or screens reviewed and they do not support for the given criteria. Then I've told my auditor to consider does not support, failures between 1% and 49% of screens, they get a partial. So yeah, the question is, are there recommended ranges for this thing? There is technique to look at partial supports versus does not support. And it could be based on percentages as was outlined here. That I would only apply to certain types of Success Criteria. And even then it depends. So if you're talking about the non-text content, so we're looking at images know, and if say, 25% of your images do not have alternative text, that could fall into a range where you would consider partially supports if 75% of them do have appropriate alternative text. But if say 55% of your images did not have alternative text, then that could be as a does not support. Those ones are something like that. But there are ones where the other thing I look at is user journey. So you could have a single say keyboard failure but it completely blocks the user from completing the main journey or the main reason for the website or the application. If keyboard only users are not able to complete that journey, then that to me is a does not so support. It could be a single failure and to me it would be a does not support because of the critical nature of that functionality. Sorry, Mitchell, you were gonna add on as well. - [Mitchell] Oh yeah, you heard me humming and nodding, yes. The only thing just to highlight of what Brian just said is that it's the some or most, so that the difference, so yes, half is the magic number, that's what some and most means. Some works, most doesn't, that's does not support. Most works and some doesn't, that's partially supports, that's its definition, but there is no definition of some of what, some functionality, some pages, some individual components, some flows, and that's again, where the remarks come in is justify why you gave it that and then you've done it right. - [Brian] Mitchell, I think this next question is for you, is the 508 the only VPAT that includes accessibility if it's considered an authoring tool? - [Mitchell] I don't wanna just say no, like that's really negative. So 508, it is accurate, that 508 includes, let me see, is 508 the only VPAT that includes accessibility if it's considered. Okay, is 508 the only version of the VPAT that deals with authoring tool accessibility? That's the way I'm reading that. Correct, the 508 version of the VPAT deals with authoring tools. The European EN301 549 also has mirrors, that's the same requirements for authoring tools. And I think I saw another, I'm getting this mixed up with another question I glanced at, like how that would work with WCAG, I'm gonna hold off on WCAG. So that's the that's the quick answer is 508 and the European standard. As I mentioned, you can do a combined international VPAT that reports both. I'm gonna jump to another question about authoring tools. I think it might have been in the chat because I don't see it here, but I did remember it and the question was, sorry, let me try this. - [Brian] It might be this one. Yeah, the question was for a particular client, is the VPAT at the product level as in software used to create or the output level website PDFs or both. - [Mitchell] Yeah, that was the related one I wanted to touch on here, which is I'm gonna go with a scenario. This client in question, let's say, might be a government agency or a school and I'm gonna use this, just for a variety we've talked a lot about government agencies. Let's talk about schools for a minute. The school has a learning management system. That's a learning management system is an offering tool. You use it to create content. And so that would call the learning management system, the product and the output would be a particular web-based learning course let's say. Well, both need to consider accessibility. You can't have one without the other, so it can be either really, or I should say it would be both. I would say that if you're gonna start with one, you really ought to make sure to acquire a learning management system that makes it possible. If you're only doing one or the other, do the tool. Because, okay, well maybe last year's learning didn't work. Well, a great way to fix that is get to a really capable tool that's good at accessibility and make version two of the course or the website or the document accessible with a tool that's really capable of doing that. But the answer is both. - [Brian] Okay. - [Mitchell] Where should we go next? - [Brian] Yeah, would a VPAT for software or a web app include contents of a support portal such as training videos, screenshots, et cetera? - [Mitchell] Yes and that's a great question. And that would fall under the documentation and support part of the reporting. - [Brian] Yeah and I think really to put it somewhat succinctly is that anything that's a part of your product, whether it's something's created in house or through an agency, or even as a third party product that's then been embedded within your product or that type of thing, or even a periphery service that your product relies on, you are responsible for the accessibility of that product. And that goes into a whole other discussion around the idea of procurement and how you go about, well, VPAT, there's one play, obviously plays a very big part in procurement, so not only do you wanna create your own VPAT for your buyers, you wanna ensure that when you are getting a product from somebody else from a third party, that they provide you with that same information so that you can make a good assessment of their accessibility. - [Mitchell] Yeah, so that's absolutely true. Anything built into your product is part of your product. Sometimes I see things, especially for large scale enterprises, lots and lots of software product, let's say. There might be a centralized support website and it doesn't really appear to be built into the software. Maybe there's a link from the software to all of the support and a completely different development team. So you might be inclined to treat them as separate things, but think about it from a user's perspective, is user needs to be able to read and learn how to use the product in order to use the product. And so that's the rationale of why there's this add-on piece that says and by the way, how is the documentation and support for that packaged product, even if it's separate, you still wanna report them together. - [Brian] The very next question after that was what is the implication if you don't test a report on third party integrations? So yeah, as we mentioned, because it is essentially viewed as part of your product, then you are responsible for it. Now, the implication is, again this is a report, a voluntary report on the state of accessibility on your product. So the implications of it are just that you have to report that something is not accessible. And perhaps you wanna use that to encourage the third party vendor to fix their accessibility. But if you are competing for a business with the US public sector and most of your competitors are using that same third party plugin, well, they're gonna all have the same reporting as part of it and that is just part of that transparency and knowing where the problems are. - [Mitchell] Yeah, that's all correct and I would add, it depends on how central to your product it is. I mean, if you have a thing, let's say mapping, mapping is a common one, "Oh, man, my maps aren't working as well as we'd like." Well, is your product all about mapping and without the mapping you can't do anything or is it like on page 27 of the support site, it's got a map to something, it's really a supporting function. Well, either way it's part of your product and you wanna report on it but really the severity of an impact on users and should be your buyers of your service or product ought to consider how big a deal it is if it's a really minor supporting function. So basically whether it's third party, from a user's perspective it doesn't matter if it's third party or first party developed content. Think of it from a user's perspective. - [Brian] Just a quick one, is there a sample of a well written VPAT report we could refer to? Not that I've dug into the reports in any great manner and can't verify them whether they're correct or not, but Adobe, if you just Google Adobe VPAT, they have a page on their site that has a link for every single one of their products that links them to their accessibility conformance reports. And what I've seen and it may look well done. I guess a mix of testing procedures would generally be used to test all the various criteria, manual plus automated. That is correct. As Mitchell has said, there are some things that automated thing will catch on its own without any intervention, very binary type of things. Whether the language is defined for a website as one example, but automated tools are generally there to help with the manual testing to point out warnings and places like that. But yes, you you'd want that the audit would have to involve both manual and automated testing. - [Mitchell] Yeah, I suppose you could just do manual, but it's more work that way. - [Brian] Yeah, I mean, at the end of the day, really manual is the thing that completes it and whether you use automated to get you there or not, that's up to you. I'd say in my head, I'm like, I would never do it without any manual testing. - [Mitchell] No, the tools are good, yeah. - Yeah, exactly. - And they really help, yeah. We use our own tools. - Yeah. - Yeah. - [Brian] Any thoughts on whether it is better to post the VPAT on our website or to only supply on request? - [Mitchell] I'm gonna say, I don't have thoughts on that. I mean, I would say, I suppose if you're on the fence, go ahead and I would say, don't be too worried if it's not perfect. If you look around, you'll find that other companies are posting VPAT. I'll say this, I would like to see more companies posted publicly, but you do not have to, you can just do it on request. - [Brian] Yeah, I mean, Mitchell and I, the nature of the business that we're in, we're very big advocates obviously of accessibility but also the transparency about accessibility. And for me, I'd love for everybody just have that accessibility conformance report or VPAT available on a website so you can easily get to it and you don't need to. And I think personally, from a business point of view, I think it makes sense because it does tell people that you care about accessibility, you are thinking about it and also posting documentation about what your plan is to fix the things that may be flagged as problems in that VPAT. I'm all for transparency personally. - [Mitchell] Yeah and one more reason you might wanna post it is, let's say you're a tool vendor that gets integrated into other people's products, or you help create content that gets integrated into websites, something like that. It should be a selling point. You should say, "Hey, look, we're quite good at this." A good way to brag about what you're doing or even brag about the journey you're on. If it's not perfect today say, "Hey, look, we're committed to quality here." - [Brian] Okay, this next question is a good one. How do we know the information in the VPAT is accurate? As a screen reader user I often find large information gaps between what the VPAT states and the actual accessibility of the product. - [Mitchell] Yeah, we didn't talk about, I will say that, we talk a lot to people who do procurement, like government procurement and that sort of thing. And sometimes we help agencies retest things that have already have had a disclosure like that. So that is one possibility is you could even hire TPGi to retest and validate. I think frankly more common is that spot checking is done by these agencies to check whether the disclosures are accurate. And those are some ways. - [Brian] Yeah and I think back to one of the comments there is that and we mentioned earlier in the presentation about using a reputable agency to do the audit and to prepare the VPAT, that can go a long way if the company has a good reputation and they can be more trustworthy, then you can more likely rely on the VPAT being accurate. But there are many agents or maybe companies that may do their own, they may update them on their own. I know if TPGi was to prepare a VPAT for a company, we would guarantee it's accuracy at time of writing. But if things have changed and updated and the company themselves did the updating, then as a company, couldn't say that it's still accurate. So yeah, I mean, it's challenging, but yeah, the VPAT should give you a good overview. You will want to dig in, as Mitchell said, you don't necessarily wanna take it at face value, but it's a good way to get started. So as Mitchell was mentioning with procurement, it's like, okay, we can look at these VPATs and if we take them at face value, here are the top five. All right, now we need to dig in a little bit and actually understand whether it meets this accessibility or not. - [Mitchell] Yeah, I'll give a couple more highlights on that one is, you may see a terrible one, it's completely internally inconsistent and terrible. Well, that tells you something but how to tell the difference between two ones that on their surface look good. I'll give two more answers to that, a summary there's a lot. One is contact the company that provided it. It's okay if they refer you to a third party like TPGi, who prepared it, or they themselves, but through themselves or a third party, ask them to answer questions about the content of it. If they have no way of answering those questions, they might have made it up. And the last thing I'll leave that on that with is if you use your favorite search engine to look for accessibility, procurement, a lot has been written on this, how to build accessibility into the procurement process. So you get a lot more good tips like that. I'm gonna point out I wanna really appreciate these great questions and we only have a couple more minutes. So we'll answer, let's say one or two more here. And Mike, can you address what we'll do with others that either have already been asked or if people have follow-ups afterwards? - [Mike] Yeah, like you said, we're at almost the top of the hour here. If you wanna cover one or two more, that'd be great. And then if anyone has any additional questions that we weren't able to cover today, just email ida@tpgi.com, and we'll get with Brian and Mitchell and get some answers to those questions. - [Brian] I think I see Mitchell may have answered one of the questions, just where to get the templates, the documents themselves to use. You can you get them from ITI, so itic.org. - [Mitchell] Yeah, itic.org. - [Brian] Yeah, I posted the link in the chat. Okay, for a particular client is the VPAT at the product level used, we answered that one, that was in the chat. How is VPAT different than Benetech certification? I think we asked this question before and I don't remember. - [Mitchell] I'm gonna have to look into this. There's a gentleman at Benetech named Philip, who was working on something years ago and I've never followed up with him to see what they've done recently. I'm not familiar with where they're at. This will have to be a later follow-up. Last question, how about, let's see, if you use a vendor product like a captcha bot tool, and they're not, I'm gonna answer, let's do these two questions and they're not, how would you report? Quick answer, you'd report a third party the same as you would report for your own product if it's built into your product. And this last question, I know we're at our time, but it's actually a really common and important one. Do you have to update the entire VPAT or you can update segments as different parts of the website change? It's hard to update. Yes, in theory it would be possible to update a piece of it. But I think the real challenge here is, well, which part changes? I think in practice anything larger than a really small app or really small website, it's hard to say a piece of it changed. I mean, generally even every sprint, the list of changes is a dozen or 100 long. And so I think, yeah, in theory you could, but in practice to the way modern products are designed and developed just changes the norm. And it's hard to isolate changes. So I would tend to do periodic complete reaudits. - [Mike] Awesome, well, I really appreciate everyone's time in answering all the great questions that everyone had. Again, I can reconnect with Brian and Mitchell after the call and we can try to answer some of the questions that were in the Q&A, but if you have any specific questions that you need to get answered, email ida@tpgi.com. And we can try to answer those for you. But we'll follow-up to this session with a recording and also the slide deck. If anyone didn't get that before the call or the webinar, but I hope everyone has a great day, great week. And thanks, Brian, and Mitchell for your time. - [Brian] Thank you. - [Mitchell] Great talking with everybody. - [Brian] Thanks everybody. - [Mike] Take care, bye.