While the focus of this module is on procuring accessible information technology (IT), accessible procurement in general should be part of a larger policy that addresses accessibility at the organizational level. A digital accessibility policy, can also fall within a larger accessibility policy which addresses other aspects, such as access to physical spaces and access to customer service. Digital accessibility as a policy on its own, will be introduced here to set the context for our discussion of procurement in this module and the discussion of hiring practices in the next. Procuring accessible IT will affect numerous elements of an accessibility policy. In the early stages of developing an accessibility policy, assessing the baseline accessibility level will include taking stock of third-party software used by the organization. These might include a content management system (CMS), a learning management system (LMS), point-of-sale systems, human resource management systems, and a variety of other types of systems for administering day-to-day operations. Each of these at some point would have gone through a procurement process. Here are some examples of how procurement fits into an organization’s overall digital accessibility policy: • In order to implement accessible procurement requirements, agreement is needed from the organization’s top level. • When providing training and support, staff need to be taught how to use accessibility features within the systems procured. • Ongoing monitoring is needed to ensure that upgrades to systems don’t compromise accessibility. Often, when software as a service (SaaS) is being used, system updates behind the scenes go unnoticed by typical users of the system. For more about procurement and accessibility policy, see the resources listed on the next slide. Many organizations will have in-house developers who create and maintain web content and who can be trained to implement web accessibility in their development practices. Most organizations however, will purchase or license third party software or Web applications for particular purposes, rather than having their in-house developers create them. It is generally more economical to license than it is to create complex systems like a content management system (CMS) or a customer relationship management system (CRMS). The accessibility of these third party tools should always be assessed before committing to a particular system. This often starts by asking vendors to describe the accessibility features of their product in a request for proposals (RFP). This request might include: • A checklist of desirable accessibility features that the vendor completes • A request for a Voluntary Product Accessibility Template (VPAT) if the company is in the U.S. • A request for a third party evaluation of the product being procured. Here are some tips to follow once you receive accessibility information from vendors: 1. Do some research and take the time to carefully assess the vendor’s claims for accuracy: Because vendors are often in competition to win your business, it is possible that they may exaggerate claims, word claims to work around known issues in their products, and, in the worst cases, make false claims about the accessibility of their products. It can be helpful to look at the vendor’s own website, test it with an automated checker, and look for accessibility information there. This can tell you a lot about the vendor’s accessibility knowledge. Failing to assess a vendor’s claims may have significant legal consequences, if accessibility claims are made against your organization and it can be shown that due diligence was not employed when acquiring a product. 2. Think beyond “yes or no”: It is not uncommon to shortlist a product for purchase or licensing that is not fully accessibility compliant, but that does have a good variety of accessibility features. It can be counterproductive to make absolute compliance a requirement. You may find for some complex systems that there are no fully compliant offerings. A system may not be compliant, but it may be the most accessible of a class of systems. Aim to procure the system that provides the best mix of required features and accessibility. Once your organization has decided on procuring a system, it is important to build accessibility requirements into the contract, so that if issues are later found that present significant barriers, vendors must take responsibility and provide solutions. Some vendors will be receptive to accessibility requests, particularly those in regions where accessibility laws affect their ability to sell their products. It is not uncommon for vendors to have little knowledge of accessibility, having never had such a request (but who, when educated, may be very happy to accommodate those requests). To set yourself up for success, simply plan to work with vendors that understand the importance of accessibility. For more about strategies for procuring accessible IT, see the following resources.