- Good morning and good afternoon everyone. My name's Anthony Priore. I'm the Digital Marketing manager at TPGi. We're gonna wait one minute as people sign in and we will get started briefly. I see a couple people trickling in, so we're just gonna give it one more minute and then we'll start momentarily. Okay, thank you everyone for joining us today for our webinar, VPAT 101 Introduction to the Voluntary Product Accessibility Template with Brian Elton. Before we get started, I just have a few housekeeping items I'd like to go through. So, firstly, this session is being recorded and we will email everyone the recording after the event. Secondly, we have captions available, so feel free to use those as needed. Next, we will have time for a live Q&A later in the webinar. So please use the Q&A box and we'll answer as many of the questions as we can at the end of the presentation. I just wanna say that the Q&A box is a little bit easier for us to keep track of. Sometimes if you throw questions into the chat box they can get lost. We will monitor both, but if you could put them into the Q&A box, that would be very helpful. And lastly, if anyone needs any accessibility support training or usability testing, we will send out an email with a link to schedule time to speak with one of our experts. So with that, I'm gonna pass it off to Brian. And let him get started, take it away, Brian.

- Great, thank you very much, Anthony. Hi, everybody. Good morning, good afternoon, good evening. Depending on where you're coming from, I can see in the chat we've got some people from, a couple of people took places in the US and one place in the UK. It's great. Yeah, welcome. Well, now I'm in Toronto, Ontario, Canada. And my pleasure to be here with you today. So, as Anthony mentioned, today's session is on the VPAT. We're just gonna kind of go through the basics, A real introduction to the Voluntary Product Accessibility Template. Yeah, and so our agenda for today, we're just gonna have a brief discussion of what is a VPAT and what it produces. Why we should use a VPAT? We'll give a little short history of the VPAT so you understand where it came from, motivation behind it. We'll go through some of the individual parts of the VPAT, the different parts that get filled out. We'll talk about how we can get a VPAT done, get a report, and when we should get a VPAT report. Right, so we'll start off, what is the VPAT? Well, I think, you know, we've said it a few times already. So the VPAT is an acronym for the Voluntary Product Accessibility Template. And the VPAT is that, it is a template that we fill out with all of our accessibility information, and once that template has been filled out, it becomes the Accessibility Conformance Report. So the ACR or Accessibility Conformance Report, that is the output of the template. But you will, for whatever reason, VPAT is more commonly used than ACR, you'll hear them interchangeably. But really that's what we're talking about is one's an empty template. The other is a filled out template, and, excuse me, this ACR, this filled out VPAT is really kind of like an accessibility resume for your digital product. It really lets people know how accessible your product is for people with disabilities. It should be noted that Voluntary Product Accessibility Template and VPAT, those are registered trademarks of the Information Technology Industry Council, known as ITI. So you often see it with a little registered symbol there. Alright, so what are the different types of products that are covered in a VPAT? Well, we have websites and web applications. We have software including mobile applications. We have hardware such as kiosks, personal computers, phones, other office machines. And then certain, you know, all kinds of like content and functionality. So this could be communication platforms like we're using today with Zoom, video, email training content, documents, and content creation tools. So when within these types, there's a range of content and functions. And really, you know, our world is more digital than ever. So it's more important than ever for our digital products to work well for people with disabilities. Now, why should we use a VPAT? You know, I understand that accessibility is important, but why are we using a VPAT format to report on? You know, as a product owner, you may have potential customers or buyers that are looking for documentation on how accessible your product is. And really that can be provided in any manner, right? So why do we use a VPAT? Well, basically VPAT is a standardized way of reporting, right? So customers and buyers can make preliminary assessments of ICT, which are your information, communication, and technology products and services in sort of a known format. Makes it easier for, you know, these potential buyers or users to compare different products from different sellers. And it also saves time for sellers. You know, you can prepare this format just once, and then you can use it for anybody that is interested in buying or using your product. And it helps you really to compete for business and in particular for public sector customers in the United States for federal. We have section 508, which is a requirement that you use the VPAT in reporting. But what are some other benefits of a VPAT? Well, it shows some transparency in your organization and a demonstration to your commitment to accessibility. You know, you recognizing that accessibility is important. You evaluated your product and you documented your product on how accessible it is, and it really shows that commitment and that transparency. And they can also use the results of, you know, the process of getting a VPAT, which we'll get to shortly, can use that as your baseline for your internal accessibility policy. You know, to see where you need to fix things first. You know, what are the most important things? Where is your product lacking the most? And, you know, what you should tackle first. All right, so let's take a step back and we'll talk a little bit about how we arrived at this standardized report. So in 1998 with the US Section 508, which I mentioned, Section 508 is a part of the... Rehabilitation Act of 1973. I had to think about that for a second. Having to do with digital products, excuse me, digital products in a federal government context. So whether it's things being produced by the federal government, being used by the federal government, being procured by the federal government, or, you know, and contracts being paid for with federal funds, that type of thing. So anything that had to do with federal US government, they required in 1988 with Section 5 required those, you know, any agency having to do deal with the federal government to buy accessible products and to use accessible products. And in 2001, the VPAT was developed with by ITI, as I mentioned, as the patent holders or the registered trademark holders in collaboration with the US Federal Government. They created this VPAT. So they had that standardized way of testing for accessible products for the federal government. We jumped forward to 2017. There was a refresh of Section 508, which harmonized it with the Web Content Accessibility Guidelines, and that was version 2.0. And so the VPAT was also then brought up to date and used, and became harmonized with WCAG as well. And then mostly latest version is version 2.5, which was updated in 2023. And this now includes WCAG 2.2, which is the latest version of WCAG. Section 508 still only requires WCAG 2.0, I will mention. And we can see that actually to that point in the different types of templates that can be used. There are four different types of templates. We have the 508 edition, and this is targeted for United States Public Sector, as mentioned, it is WCAG 2.0 and that's where Section 508 still stands. And it has additional section four, Section 508, which we will talk about some of the parts of that beyond WCAG. There's an EU edition for the European Union and Australia. It is with WCAG 2.1. I believe it should be getting updated soon. That hasn't already, but it also has, instead of Section 508, it has another component called EN 301 549. Again, we'll talk about that a little bit in the next section, but just some additional parts of the VPAT that are beyond just WCAG. We can use a VPAT that is just standalone for WCAG. So if we don't have to create, or we don't want to create a VPAT for public institutions in the United States or in the European Union, we may just wanna do one that is just WCAG to see how we comply against the WCAG guidelines. We can do that. And that has a version 2.2 that's been updated, as I mentioned. And then there's an international version, which contains all parts, right? So it has WCAG, it has Section 508, it has EN 301 549. And so that can be used for any situation. So let's talk about the parts of a VPAT. So a complete international VPAT has four sections to it. The first section is the cover page. And this outlines a bunch of important information, such as the name of the product or the version. And the version would be for something that is software based perhaps, where you actually have versioning. It has the report date and this is actually probably more key for things like websites 'cause websites, you know, typically don't have a version associated with them. You would then have a report date just to show how recently this VPAT was created for your website. It also has the evaluation methods that are used, right? And as a buyer, it's really important you'd want to check to make sure that the evaluation methods that are used match what you're expecting for your users, right? So if you're users are primarily JAWS screen reader users, but the report was completed with NVDA, you know, you may wanna dig a bit further into whether it'll conform just as well. Now having said that, the VPAT should be completed using multiple screen readers. We'll talk about that in the next section. All right, so that's your sort of cover page information that outlines name, report, date, evaluation methods, you'd also list, you know, like what version of WCAG was tested against. And that you report into the second section, which is the results of testing against WCAG. So each success criterion in WCAG is in a table along with a cell for the conformance level and for remarks and explanations. So on screen we can see the very first WCAG success criteria is 1.1.1 non-text content. The fully fleshed out template actually has this really nice additional information within that cell to say that, you know, this WCAG success criteria also applies to these sections of EN 301 549 and these sections of the revised Section 508 section. Because then you know where to pull information from when you're filling out these other sections which we're gonna talk about in just one moment. And then the conformance level we'll talk about it in a moment. In the template, it shows, you know, web, electronic docs, software, closed authoring tool. It is recommended if you have multiple products on multiple platforms. So if you have, say, a website and you also have a mobile application that you have separate VPATs for each one of those products instead of, you know, one and trying to smoosh it all together, you know. It kind of makes it seem as though you could do that in this template. You know, you could have your conformance level as it relates to the website. And then you could have your conformance level as it relates to the software, which would be mobile application. But it starts to get things a bit confusing. So I would say, you know, just do one for the website, one for your mobile app or whatever else it is that you're testing against. The third section is the revised Section 508 report. And this is a table that's broken down into functional base criteria. Some are generalized. So the first one is, sorry, the first section of this chapter three is broken down into this. Some things are generalized and others are more specific, you know, so we've got things like the ability to reach forward in hardware, or we've got alternative user devices in interfaces in software. So we've got functional performance criteria, we have hardware and we have software, and lots of different bits and pieces to that. Now, when we talk about conformance for things such as a functional performance criteria, this is things that we can put together based on what was entered into the WCAG table. And it could really include multiple success criteria, but the remarks should be different, you know, depending on what user we're talking about. So for example, you know the first one in the functional performance criteria, we've got 302.1 without vision. And this could include success criteria such as 1.1.1 non-text content and 125 audio description. You know, for prerecorded content, and it could be a whole bunch of other things. Anything that is related in the WCAG table that would be success criteria that is related to somebody who does not have vision. We would basically combine all of those conformance levels together to create the conformance level at this functional performance criteria section. And then our remarks and explanations would align with that as well 'cause, you know, you do conform with for non-text content, but you don't conform for audio description, then your conformance level is gonna be different than if you conform for everything. And I should say, I'll go back one slide here, the other section, so hardware and software, some of it may be related to the WCAG table, but a lot of times it's not. It's stuff that is evaluated separately. You know, especially when it comes to things like hardware, you're not gonna be able to evaluate hardware against, you know, the Web Content Accessibility Guidelines. We're talking about a physical piece of equipment. So that is a slightly different sort of evaluation there. In the EN 301 549 report, very similar to Section 508. You've got functional performance statements. So similar to the functional performance criteria, we have some other general requirements, and then there's also hardware and software in those sections. And, again, same idea. So if you filled out Section 508 from the WCAG table and all of your other testing, a lot of that information could then be copied over to 301 549. A lot of it's very, very similar. They're quite similar. So those are the four parts. And then as I, you know, talked about the conformance level, and so there's different VPAT conformance levels or ratings that you can give. So "Supports": these are all quotes from ITI from the actual template itself. So if something has a rating of "Supports", that means the functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation. "Partially Supports": some functionality of the product does not meet the criteria. "Does Not Support": means the majority of the product functionality does not meet the criteria. And "Not Applicable": the criterion is not relevant to the product. And then the final one is "Not Evaluated", and that means that the product has not been evaluated against the criteria. But that can only be used against WCAG 2. Whatever you're evaluating, 2.0, 2.1, 2.2., level triple A. Okay, so WCAG is broken down into single A, double A, triple A. So only triple A can be omitted from your VPAT. Single A, double A must be included. So you have to go through, you know, from your evaluations. Is it completely support it? Does the criteria and a success criteria, and does it completely support it throughout? Great. Then it gets a "Supports" rating. If there are some parts that do support it and some parts that don't, maybe the majority of it is supportive, then it can say "Partially Supports". But as soon as you start to go beyond below the majority of, in the 50/50 type range for a lot of them we're gonna talk about it "Does Not Support". So the majority of the product does not meet the criteria. When we have a "Partially Supports" or a "Does Not Support", those are both considered fail ratings, okay? Like WCAG is very binary in this sense, right? It's either pass or fail. Even if you have one image that is missing an alternative text that is a failure even though it could be one out of a thousand pictures or images. Is very binary in that sense. So if you have "Partially Supports" or "Does Not Support", those are fail ratings. And so when you're entering in the remarks, you really have to make sure that it's clear where the failures are coming from because that is the information that people are gonna use when they are evaluating a product. It's like, okay, so there's some images don't have alternative text, is that going to negatively affect my users or is it something that can kind of get past and I can look past for the moment? Support ratings should have remarks, they can be very brief, but you definitely want to have a remark in the support rating when you have something that meets the alternative, what was the wording? Sorry, I'm just gonna back one slide here. The equivalent facilitation. So if you have a workaround as a, you could also call that, if you have a workaround, then you would need to in that "Supports" remarks say what the workaround is. So yes, this is supported, but you have to do this in order to make it happen. A non-applicable rating means that the product does not have content relevant to that criterion. That could be used for something like if you're evaluating for multimedia, you know, video and audio and there isn't any video or audio in the product, you could put "Not Applicable" against those WCAG ratings. Now I will put an asterisk against that because there is a more recent directive from ITI that when you have what would be a "Not Applicable" rating that you actually put "Supports" in place, if not applicable. If that feature doesn't exist because in essence I guess it does support the fact that, you know, any video has captions. Well, if you don't have a video, there's no captions, but it supports you've supported that. I don't know why they did it, honestly. So you can go back and forth, I mean, "Not Applicable" supports. I would just, if you're using "Supports" and it's a feature not there, then in your remarks I would say there, you know, there is no video within this product or something like that. Okay, so let's have a, a quick example here. We'll look at that very first WCAG success criteria, non-text content. I have now narrowed it down because, say, all I'm doing is evaluating websites. So all of the applies to also applies to type information. I'm just keeping the ones that relate to web, right? And so in EN 301 549, there's one criteria that this applies to in a web context. Same thing with revised Section 508 as there's only one that this applies to. And, you know, in my example here I have a "Partially Supports" conformance level and why is it partially supported? Well, I have some remarks and explanations, which I say non-text content that is presented to the user generally have a text alternative that serves an equivalent purpose, which is what you want with some exceptions. And these include, you know, some image-based controls are missing or have inadequate text alternatives. Some image-based links don't sufficiently convey their purpose. The writing styles will change, you know, it really is up to you what that writing style's gonna be. You wanna be consistent throughout your VPAT and the amount of detail really, you just wanna make sure that it's enough that the person has, you know, the person who's reading it or, you know, evaluating has a sense of what the actual issues are. You know, we don't want to just say, like, yeah, some images don't have text alternatives. You kind of wanna have a little bit more detail around that so that there's a bit more information to inform the evaluator. And if they really need to, they can then maybe dig into your product a bit and, you know, check out, okay, I'm gonna go look for some of these image-based controls that I have an example here and see is that really gonna be a negative effect? Alright, so now that's a small snippet of the report, but obviously there's a lot more involved. So how do you go about getting a VPAT report or an ACR? Well, the first thing you need to do is to get an accessibility audit, right? So an audit will, you know, expose or show the accessibility, perhaps, defects of your product or where it's lacking in accessibility functionality. The VPAT ultimately is a report on the results of this audit. There's a lot more that goes into it because it's not just necessarily WCAG, you get more to fill out if you're doing the other sections. But it all starts with this audit on your website. So when you're doing an audit what are the parts of creating or getting an audit finished or getting an audit performed? Well, the first thing you need to do is you need to choose your accessibility standards. So it's gonna be relevant for your potential customers or the regions where you do business. The easiest thing to do is to choose all standards, right? So if we choose to do the international, it's going to include WCAG level A, double A, it is gonna include WCAG version 2.2, right? So, but if, you know, a buyer's only interested in 2.1 or 2.0, it's okay because 2.2 includes 2.1 and 2.0. If you have the possibility of the US customers in any level of government in public or private schools which receive public funding, then you want to include Section 508. And same thing goes for EN 301 549 for the European Union or Australia. So really the best thing to do is just to pick everything, right? Choose the international standard, get all of it filled out, and then you've got one document that's ready to go for any situation. Next thing you have to do is identify a sufficient sample for testing. So it has to be what we call a representative sample. So different page layouts, different types of content, key functionality of the product, and then also you have to make sure that you include things for the Section 508 and the EN 301 549 sections. You have to remember things like product documentation, like online help, support services, like online chat support, phone support. These things have specific criteria for supporting users with disabilities. And then gotta think about things like an authoring tool, you know, which are used to build websites or content management system those things also would apply if it is something that you're evaluating. So you have to look at things like your rich text editor, any sort of like CMS type of related things. You also have to be concerned about third party content. So any code or content that is created by a third party, it's like essentially once it's integrated into your product, you are responsible for it. So you have to make sure that you are aware of that when you are procuring either third party services, third party products, whatever it may be 'cause once you've taken ownership of it and integrated it with your product, you're now responsible for it. And then once you know what you're testing, then you have to know how to test it effectively. And we're now, don't just talk about automated testing, right? We have to make sure we're doing manual testing and human technical evaluation, right? So we can do automated testing which is nice to have a big lift, you know, kind of get through a lot of stuff very quickly. But automated testing is very limited in what it can find. The numbers typically are around, you know, 25%, 30% of errors can be found through automated testing. The rest have to be found through human intervention, manual testing; using assistive technology, using things like a keyboard on its own, using a screen reader, you know, looking at examining the markup and, you know, using dev tools, saying Chrome in order to examine to make sure that the right code is being used, semantics are being used. So there's a lot that goes into it. This session's not really about testing, so I'm not gonna dig too far into that, but you have to make sure that, you know, we are covering all of the different aspects of accessibility testing. So now that you're ready for the VPAT, what will make it really good quality for your customers? You know, something that your customers can trust. Make sure that you disclose the testing methodology and what we just talked about, right? We have that in the cover page. We wanna make sure that we cover every, you know, we clearly outlined everything that we used in our testing, make sure we have clear remarks to show why we've rated things the way that we have. You know, "Supports", "Partially Supports", "Does Not Support". We want to have clear remarks as why that's the case. And in most cases, we do recommend you work with a reputable third party auditor. You know, so in addition to, you know, getting good quality testing and reporting from, you know, experts in the field, people who are buying and see that the VPAT was created by a reputable company such as ours, like TPGi. It will give them, you know, that confidence and knowing that the VPAT will have been done well and accurately. The other thing is you wanna remember that the VPAT should list the testing date and/or the product version. And so we wanna make sure that we are keeping up with your current version of your product as it progresses. Okay, so accessibility is essential for buyers and for users, but maybe you're just starting out on your accessibility journey. So a common question that we get is, what happens if the VPAT lists accessibility problems? You know, what if I have a lot of issues in my website and I have this VPAT created and it's just showing a lot of problems. Well, the advice is to focus on the end user experience, right? For people with disabilities. You know, we're not just a checking boxes with, you know, the VPAT. So while you're working on the accessibility improvements, some buyers can still purchase your product, okay? So for example, the US government, they will select something or can select a product that best meets its requirements, right? So we can still publish a VPAT with the issues, but we wanna make sure that, you know, that we are clear about how we're gonna fix them. What's the timeline? What's the plan for fixing our issues? And remember that a big part of having a VPAT is the transparency that comes along with it, right? So if you have a VPAT, you know, available to your users or your potential buyers, and it's showing a lot of issues, a lot of accessibility problems, but you also offer up a document that shows how you plan to fix and remediate or the timeline that you're going to use to solve these issues, it shows people that you care and that you will work your best to make sure that your product is accessible as possible. And that transparency will go a long way. So don't shy away from having a VPAT that, you know, has a lot of issues. Put it up there, but put it up there with a caveat that, you know, we're gonna fix all these and this is our timeline for it. There are risks that come along with a poorly created VPAT and we really have to be conscious about this, right? So it is important for you to have a VPAT based on who your buyers are, who your users are, you know, if you don't have a well created VPAT, it could cost you valuable contracts. You could lose out on some contracts, you could lead to some compliance risks. So if you haven't had a VPAT created or it's not done very well, it doesn't accurately reflect your status of accessibility in your site, you could open yourself up to litigation. So, you know, we don't want to have that, we wanna make sure that our VPATs are accurate and that it comes down to the auditing of it. And it could also damage trust with your buyers, right? So if they look at your VPAT and it shows 10 accessibility issues when in fact there's a hundred accessibility issues. If they buy that product and then they discover afterwards that there's all these issues, man, that's really gonna be problematic for the trust for the buyers, right? So you really wanna make sure that you have a really, really well audited product and a well-written and well created VPAT to avoid all these things. And whenever possible work with a reputable third party company like TPGi to create your VPAT 'cause you have the best option of getting something that is accurate and well-formed. Okay, so that's all we have about what's in a VPAT and how to get one. So now how about when should we do, when should I create a VPAT or get a VPAT report? Well, first we have to answer the question like do I need a VPAT? Well, yes and no. The "V" in VPAT does stand for voluntary, okay? You know, the accessibility of your product is a legal requirement. Lots of different standards and legal requirements depending on what region you're in and who you're selling to and all the rest of it. There are lots of different legal requirements, but it is a legal requirement. But a specific report on that level of accessibility is not, you know, unless obviously it's required by, like I mentioned a few times, the US federal public sector, they require that anybody wanting to sell to them has a VPAT that reports Section 508. But in any other context is not necessarily required to have it, you know, in order to have that specific report. So it is voluntary and your reports can be something that you just have available on your website or available by request. You know, there is no specific way that you have to, excuse me. No, there's no specific way that you have to provide that report. But now you decided, okay, I need a VPAT, when should I do it? Well, you could wait until you get your customer ask you for one. But there's a lot of risks and we kind of talked about some of those risks, but an audit takes time. It is not a quick process. You know, the bigger a product is, the more complex it is, the bigger the representative sample is because you've got such a complex product, the longer it takes to do that audit. And so it could take a long time to produce a VPAT. And then you also, you don't actually may not know at that moment what your accessibility status is. You know, you could be saying to somebody, oh yeah, we're accessible, let me just get a VPAT written and you get an audit done and all the rest and I'll show you, and then they come back to it and you realize, oh no, I've got a lot of work here to do. So I don't recommend you wait until a client, or customer asks you for one. You could do your audit, get your status. That takes care of one of the risks. You understand what your audit accessibility status is if you get it yourself, you know, your product audited, and then just wait until somebody asks you for a VPAT. So it's a bit more of a quick process, but still, you know, it's much easier to just be proactive, you know, get that VPAT done. Be proactive in it, and it is ready for any time you need it, right? So be proactive, get an accessibility audit, improve your product's accessibility from that audit, knowing where the issues are. Prepare a VPAT report and update it regularly so, you know, new versions you want to, you know, maybe another audit or update your VPAT, make sure it stays up to date. Make sure you're always keeping your users informed of your accessibility progress. Even your current users, you know. It's important that somebody started using your product knowing that there was some accessibility issues, but there's a roadmap as you fix those things. Make sure you're informing everybody that, hey, guys, I know you signed on when we had this problem and this problem. Well we've fixed these things now. These features are now available to you. Please go and check 'em out. And with all of that, you would then, you know, gain that competitive advantage. All right. So that brings us to questions. I see a few in the Q&A. Okay, so question, do cameras, measurement, and data collection equipment with a digital screen require an ACR? That is a very good question. So, again, it would very much depend on the context. So there's... with hardware that it may be used in the federal government in the United States that could be subject to needing a VPAT or an ACR, in the hard, yeah, the hardware component of it. That could be something that would be required, but in the general sense it does not, right? So you've gotta remember this is a voluntary thing. You know, you could write a VPAT for your cameras or your data collection equipment, you know, anything with digital screen, you could write a VPAT for it and it would highlight places where it may be challenging. This will become more and more prevalent and something it's considered with the recent release of the European Accessibility Act, which has much stronger legislation around things like kiosks, which in essence these are a lot of the same sort of problems, right? So kiosk with a flat digital screen, you know, a lot of touch implementation, you know, there's are regulations in place now that they have to provide a whole bunch of different features and whatnot. So they could fall along that same line. But I don't think things like this would be specifically called out. The EAA I'm not too sure about, but if you're selling a particular data collection piece of equipment to the US federal government, then you may need to provide an ACR for that. That'd be a single use case. I could see that happening. If I'm doing multiple pages on the same website, how would that be structured with a VPAT since each page can have different conformance levels? Well, you're actually, you're not going to do a VPAT on multiple pages. It is an entire product. So you're gonna do VPAT on your singular website product. Now, if you have, you know, maybe different sub domains in your website, you could do a VPAT for the different sub domains. But if you have just say a main website, you know, companyx.com, that is what the VPAT would be on is on that entire thing. Now, when you get the audit, what you need to do is create an a representative sample of that website. There's gonna be a lot of common components like, you know, the header, the footer, a bunch of navigation stuff. They only need to be tested once. You know, if the header is something that's used throughout that website, you only need to test it once on one page. And then individual components of those different pages you would add to your representative sample. But, again, if things are repeated on multiple pages, then you'd only need to test it once. But the VPAT is for the entire website itself as a whole, not just page-by-page. Okay, in most audit projects it is not cost efficient to test the whole product. So you focus on critical user flows and representative pages, screens, components. How do you explain this in the VPAT to ensure all understand the issues may be found even if the criterion is marked as "Supports"? So there's lots of places in like the cover page to put notes and descriptions and whatnot. There's, you know, you can add a whole bunch of different context to the report to lay out things like that. I would say that if you don't have any comments to the effect, you know, you've gotta a product and you have a VPAT for that product. The assumption is gonna be that you did it on a representative sample. Okay, you didn't test every single page, every single component, every single page as it repeated. No, you did as I just described before, like you tested the header, it's fine. You tested the footer once and then that's what's repeated. Okay, that's it. So that part is fine. Now, if you only are testing, say, the one particular user flow, 'cause you want to, it's really critical for you. I mean e-commerce, you know, in particular, you may want to test the checkout, maybe the add-to-cart and checkout flow. And so if that's what, you know, your main concern is, that's all that you're able to audit in that particular time because that's what was critical for your business and your users and whatnot, then you can describe that in the VPAT, right? So you can sort of put all the relevant information. Again, I really wanna stress this that, you know, aside from the US federal government and maybe a couple other, you know, niche situations, they are voluntary. You don't have to have this. And, but if you want to do this and you wanna show, you know, again, that transparency and that commitment to accessibility, it's always a great idea to have it. But at that time, you only have the ability to, you know, to test that one user flow and you want to get that out there, you want to know what your status is, you want to get that information out to everybody, great. Do that and put it all in the notes. And then as you maybe get other parts of the site audited, you can update it, and update the notes on what it's part of. So there's lots of flexibility in there. What standard is used in the UK? That is a great question. I think that you would use the international, probably the EU standard would be the one that you would probably want to use. Again, I don't know of any formal requirements for this ACR within the UK. Please tell me if I'm wrong on that one. And so yeah, I would use a version that is as closely aligned to the UK as possible, which is the European Union version of it. You can also, you know, if you aren't really sure, you know, the additional EN 301 549, the Section 508, well Section 508 in particular, that is directly aimed at a US federal government. But if you are doing something that's more generalized, you just wanna have a statement out there, you just wanna have an ACR report, you could do just the WCAG version. And it gives, you know, that real sense of like, you know, you document the accessibility level as it relates to WCAG. The things beyond that for Section 508 and EN 301 549, they start to get into things like functional requirements, hardware, software, you know, different aspects of it. So you can kind of pick and choose, you know, again, when you're not bound by a requirement like the US federal government requirement, you can kind of choose which standard you want to put it out and they can be just as effective in, you know, explaining your status at that given moment and that transparency and understanding. Next question, I get pushback from software browser plugin extension makers to say they don't have to do their own VPATs because they can ride the coattails of their host program products. Yeah, so it's kind of like that third party plugin is like, you know, or third party service code, whatever it is that they're providing. It's true that once you utilize it and put it into your, whatever the context is that you're using it, it's now your responsibility. But where the pushback should be is like, well, okay, if you're not gonna make it accessible, I'm not gonna use it. I'm not gonna purchase your product. I'm not gonna purchase your services. That's where they have to, I guess their drive has to come from is, you know, if they're refusing to make it accessible, then don't use it and tell 'em that's the reason why I'm not using it. You may get locked into situations where you have no choice, then you just gotta try and work with them. But, unfortunately, at the end of the day, you know, it is the sort of the host party's responsibility for all the components that are built into it. Next question. Okay, so how do you create a VPAT document for a website with hundreds of pages and not all pages being tested for accessibility? Developers and vendors are unaware and are committed to implement accessibility features while developing the site. We were asked to help them document VPAT for the site. Can you please guide us on the approach to any suggestions? Yeah, so I mean, I'm assuming given, you know, today's tech stacks and whatnot for developing websites, when you have a hundred pages, it's not a hundred pages of hand coded HTML, right? It's like you have shared components that are then imported and brought in, you know, different methodologies. So you're not testing hundreds of pages. What you're testing is unique components of the website. And so that's what the representative sample comes from. And then if you're helping organizations try to fix things as they go. Excuse me. Again, it could be, okay, well is this a new component, right? We will test that component. We're not gonna test the entire page necessarily. There are page level things that need to be tested for accessibility, but when we're talking about, you know, adding a new component, okay, well that's what gets tested is that component and maybe some spot testing as it's been implemented on different pages to make sure it hasn't broken anything or, you know, whatever, but really you're focused in on that one component. And even if they're updating a component, the testing doesn't have to happen on everything that surrounds it. It's just it's that one component and then maybe some spot checking on how it's been, you know, where it's been implemented. I hope that answers that question. And how do you create a VPAT without an audit? Unfortunately, you can't. You have to do an audit in some format, right? You have to know where there are accessibility issues. Now, do you need a third party to do your audit for you? No, you can do your own internal audit. There's nothing preventing you from doing that. You can, as an individual, as an organization, whatever it is, you can write, you can do your own audit. You can write your own VPAT. There's nothing stopping you from doing anything like that. What the consequence of that is though is whether people are gonna think that it's trustworthy or not. Okay, so if you've got the in-house talent and knowledge to do the audit and to create the VPAT, go for it. If you don't, then you certainly should get a third party in to do the work for you because it will be good reputationally and for accuracy and whatnot, because you don't want to just, you know, fill it out based on gut instinct or, you know, I'm pretty sure all of our images have, you know, text alternatives. So I'll just say it's fine. You know, you don't wanna do that because, again, that's where that trust with buyers, you know, could disintegrate. You know, if you say that you've got, you know, no issues on your site or only these few minor ones, and then they buy your product and then they discover a whole bunch of other issues, well that's really gonna be, you know, poor for the relationship with that buyer. How does this apply if your software has both private user and public user aspects? Both public and private user using the software? So it would still apply. Now, again, so this is if we go back to thinking about this, you know, the one statement is that your product being accessible is, excuse me, part of legislation. And it is required in different aspects depending on your region and what the current legislation is, but your products are bound by that legislation. So they have to be accessible to whatever that is, whether it's public facing, internal facing. There is legislation that'll dictate that. And the VPAT is just gonna be a reflection of that, right? So now I would suggest that you do a VPAT that for your public facing part and maybe a VPAT for your private facing part, unless there's a lot of overlap, you know, then I'd make it one and just note when something is, you know, part of the private side. But, yeah, just like the one thing to remember is that the VPAT is just a reflection of how your product lives up to sort of like the legislation in your area. So yeah, again, you'd have to test against WCAG, you test your private side against it. Like there's certain, you know, legislation in the US government where like people who are using the internal systems, those things have to be accessible as well. It's not just publicly facing things that have to be accessible. If you have internal systems, the people that are within your organization need to be able to use them. And so those have fall under similar legislation as public facing. Okay.

- [Anthony] I did see-Brian.

- [Brian] The Q&A is empty.

- [Anthony] I did see a couple questions sneak into the chat.

- Okay.

- [Anthony] One of them says, given that WCAG 3.0 is still a draft, what are the current guidance for companies who need to create a VPAT now? Should we be including any information about WCAG 3.0 in our current VPATs or waiting for the final standard?

- Yeah, I wouldn't do anything about 3.0. It's still way too early in its development and yeah, And, yeah, I would do it to WCAG 2.2, that is the official WCAG guidance right now. There's nothing official about WCAG 3. It's still to come and even when it does get released, it has to have some uptick and, you know, by governments to update their legislation, you know, to follow along with it, right? And that's gonna take time even after it gets released. So, you know, we're not gonna see 3.0. My prediction is, all right, we're not gonna see it as part of any official government legislation in for another 10 years. That's my prediction. So I wouldn't, yeah, I wouldn't do anything to 3.0. The thing about a 3.0 that is good is that there may be some things that are being updated, new techniques, new ways of doing things that are just, you know, helping to benefit more people where WCAG 2.2 may have been missed. Implement those things like, you know, start working towards those things, you know, use those ideas and always working towards making your product better for your users. 100%. But you're not gonna be testing against 3.0, you know, for the VPAT or any sort of audit. Is there another one in the chat?

- [Anthony] There was one more, yes. Steve would like to know when will the US change its standards to match Europe's standards?

- That's a fantastic question that, and I don't have an answer for that. There has been some advancement in the fact that, so Title II of the Americans with Disabilities Act, which deals with digital products for state and local governments and other public institutions like schools. They had a statement update recently where there's now a requirement they all must meet WCAG 2.1 AA. Some by 2026 and some by 2027. They were given two or three years depending on the size of the organization from, I think, it was April, 2024. Somewhere around there. So there's been some advances there. As far as the federal government updating Section 508 to include either 2.1 or 2.2, I have no clue when that might happen, what the sort of drive is for it. I think, unfortunately, the current government, the current administration is sort of, they have moved accessibility and DEI initiatives sort of down their priority list. And so, yeah, I don't know when that may happen, but, you know, there are other advances, other places that things are happening. So like I said, the state and local government that's advancing, I think a lot of them have trouble with the idea of putting, you know, the latest as in like, you know, WCAG, whatever the latest version of WCAG is you must conform to because I think that's perceived as too much of a moving target. And, you know, if WCAG releases 2.3, all of a sudden everybody's scrambling to try and like catch up, right? So they have to put a version number, and so 2.1 is the one that the state and local governments are now bound to in the US. European Union, I think they're updating EN 301 549 to be WCAG 2.2. If that hasn't happened already it's very close. So yeah, I know Europe is a bit further advanced on keeping up with the guidelines anyways. Any more in the chat, Anthony?

- [Anthony] There's no more in the chat, but there's one more in the Q&A box.

- Yeah, okay, so how do you keep a third party VPAT up to date if you're constantly releasing new features, fixing bugs, et cetera? Yeah, so... the third party, just to sort of clarify the question, third party VPAT would be the responsibility of the actual company producing that content or service or whatever. But to your point though of like, you know, say you've got a VPAT for your entire website that includes maybe third party content, but, and then you're on a sprint release, and every two weeks or every three weeks you're releasing new code. How do you keep your VPAT up to date with that? That is, admittedly, one of the challenges is that, well, first of all, it's not necessarily a challenge depending on how your organization wants to go about it. Once you've got a VPAT created, however it was created, you can keep it up to date as an organization. Oh, thank you for the clarification. Just a minute. VPAT produced by a third party like TPGi, right? That's sort of where I was kind of going with all this. So TPGi, say, creates a VPAT for you based on your website as of today. And then three weeks from now, six weeks from now, 12 weeks from now, whatever, you release new code and maybe that fixed some of your accessibility issues. It's not practical to have TPGi come in and do a full audit of your site every, you know, every month. And so it does cause a bit of an issue. You as an organization can update your VPAT yourselves, right? You can adjust things as you fix things and whatnot. The only consequence of that is that then the third party, whether it be us or other agencies that do a similar thing, may not endorse that VPAT after you've made adjustments to it because we haven't had time to confirm or had a chance to confirm that those changes actually had been made. You know, that type of thing. So that's one consequence of updating it yourself, but you absolutely can do that. You can update it, take the VPAT that TPGi produced, you fix this to, you know, whatever accessibility issues you had or now this thing that was "Partially Supports", it's now "Supports". I can update all that. You can absolutely do that. You just may lose some of the support. Now one of the other options is, and listen, there's lots of ways we go about this, is that perhaps, you know, if you have a partnership with TPGi where, okay, you know, TPGi, we just released this new component where it fixes a bunch of accessibility issues. Can you go and test just that and tell me that now updates the VPAT and if it does, great. We'll go and update the VPAT and now it stays like, you know, we will still endorse the VPAT 'cause it's all stuff that we've done and tested ourselves. And that could be, you know, a longer term relationship you know, that has many parts to it. What are the costs of these audits? I'm not the sales guy. I'm afraid to tell you. I can't give you those costs, but please reach out. I think there'll be follow up emails to this, reach out to Anthony, reach out with the follow up. Happy to talk through all of those possibilities with you.

- [Anthony] Absolutely, yeah, and we are at time here. So thank you everyone for attending and for your wonderful questions and being an engaging audience. And thank you, Brian, for being a wonderful presenter and talking about VPATs with us. Appreciate everyone's time and yes, as Brian said, we'll be reaching out with the recordings and some resources and if you have any questions about any of these things we'll be happy to set you up with the right people, so thank you all. Have a great rest of your day. Bye now.

- Thank you.