A Voluntary Product Accessibility Template, or VPAT as it is commonly known, is a checklist that companies who supply the U.S. government can fill out to document the accessibility of their products. Because a VPAT is completed by the vendor, they have a tendency to present products in a better light than what may actually be the case. As a result, any time you are presented with a VPAT, it is important that a person knowledgeable in web accessibility critically reviews the document. The VPAT 2.1 Web and software accessibility requirements are based on WCAG 2.0. VPAT 2.1 also encompasses the European Union’s EN 301 549 accessibility requirements, and the Revised Section 508 requirements of January 2017. You can download a sample VPAT 2.1 form, from the Course Resources. Even expertly created audits or assessments can benefit from a second opinion. Not all auditors approach accessibility requirements the same way. Some may have a more strict approach, following guidelines and techniques more stringently. Others may have a more practical approach, taking into consideration a range of variables such as budget, human resources, and adaptive technology support for particular techniques, etc. Those with a practical approach come up with solutions that best fit the circumstance, perhaps foregoing some of the strict compliance rules in favour of feasibility. There are a growing number of companies that provide professional web accessibility auditing services. Not all of these companies are reputable and may not have an expert understanding of web accessibility. Some of the same strategies one might use to evaluate the accessibility knowledge of a vendor, can also be used to evaluate the knowledge of a potential auditor. If you would like a third-party accessibility auditing service to evaluate a product your organization is intending to procure, here are a few things you should look for: 1. Are the auditors web developers? Many issues that present barriers are the result of using HTML, WAI-ARIA, or JavaScript incorrectly. A web developer (or a person with a strong understanding of these technologies) can accurately identify the origins of more complex issues and offer effective solutions. 2. Does the service provide tools? The more reputable services develop their own tools such as automated checkers, contrast evaluators, and browser plugins, etc. that the average user can use to test accessibility for themselves. A good collection of tools is a good indicator that the service knows what it is doing. Tools may also indicate that developers are on staff. 3. How long has the service been in business? If you can’t find any indication of how long the service has been in business, be wary. If a service has been around for a while (over five years), it’s a good indication. 4. Is there a sample audit you can examine? You can tell a lot about the skills of auditors by the reports they produce. Ask for one if you can’t find one on the Web. If you are unable to get a sample, be wary. 5. Is the audit methodology posted publicly? Auditing services that know what they are doing will post their methods for everyone to see. 6. Are there a variety of services to choose from? The more reputable services will include a variety of audit options, training for different audiences, website accessibility monitoring, and other services that approach web accessibility from many angles. 7. Is the service’s website accessible? Reputable services will lead by example. Their websites will be spotless from an accessibility perspective and the HTML of the site should validate. It may be beneficial for both the vendor and the procuring organization to have a third-party accessibility auditing service brought in to provide an unbiased review of the software being acquired. This requirement may be part of a contractual agreement that requires confirmation of compliance with a given standard from an expert working at arm’s length from the two parties. It provides a level of protection for both parties, providing an objective account of a software’s state of accessibility that both parties can refer to if disagreement should arise. Here are a few web accessibility auditing services known to be reputable:• Deque Systems [https://www.deque.com/] • The Paciello Group [https://www.paciellogroup.com/] • WebSavvy (Inclusive Design Research Centre) [https://websavvy.idrc.ocadu.ca/] • Level Access [https://www.levelaccess.com/]. Assuming you have received proposals from vendors, tested their understanding of web accessibility, and are ready to move into a contractual arrangement to license or purchase the software or web application from one of them, it is important to lay out web accessibility requirements in the issued contract. The following are two approaches to defining accessibility requirements: the first is a more general approach, relying on a specific standard to which vendors can refer, and the second is a more detailed approach, which relies on a standard but also supplies specific requirements that must be met. The National Center on Disability and Access to Education (NCDAE) provides some standard text for contracts that makes accessibility a requirement of the agreement. This text will be relevant for those procuring under the Section 508 regulations: Sample 1: Purchasing contracts for specific products - Vendors must ensure that the course management system contained in the proposal, fully conforms with Section 508 of the Rehabilitation Act of 1973, as amended in 2017. For information on Section 508, see www.section508.gov. This includes both the student and instructor views and also includes all interaction tools, e.g., chats, discussion forums and add-ons (e.g., grade functions). Vendors must declare if any portion of the version under consideration does not fully conform to Section 508, and the ways in which the proposed product is out of compliance. [Source: The National Center on Disability and Access to Education - http://www.ncdae.org/resources/articles/procurement.php#samples]. While this approach may be sufficient in some cases, where it has been confirmed that the vendor understands the requirements of Section 508, there will be cases when vendors don’t know if their product conforms or not. To reduce that likelihood, details of the Section 508 requirements could be specified, something like the requirements outlined in the “WCAG 2.0 Wording” section below. Like the wording for RFPs introduced earlier, it is important for contracts to provide specific details in order to avoid potential confusion for vendors who may not be fully aware of WCAG 2.0 requirements. The following is an adapted version of the Section 508 wording just shown, with suggested wording that specifies an agreed-upon course of action, should accessibility issues be discovered after the contract is implemented, along with the procuring organization’s specific accessibility requirements. Though WCAG 2.0 is specified, this language would be appropriate for those drafting AODA-related web accessibility requirements. Sample 2: Purchasing contracts of specific products. Vendors must ensure that the course management system contained in the proposal, fully conforms with the Web Content Accessibility Guidelines (WCAG 2.0), Level AA, as published by the Web Accessibility Initiative (WAI) of the W3C, summarized in the list that follows (see WCAG 2.0 for more information). This includes both the student and instructor views and also includes all interaction tools, e.g., chats, discussion forums and add-ons (grade functions). Vendors must declare if any portion of the version under consideration does not fully conform to WCAG 2.0 Level AA, and describe the ways in which the proposed product is out of compliance. Vendors agree that their product will continue to conform with these requirements, and in the event potential violations are discovered, will arrange to have such issues resolved, unless otherwise agreed-upon exceptions are stated in writing.