Accessibility Statements, OpenACR (OPATs) & WCAG-EM Best Practices.

[mgifford]

There are many stages for accessibility to be considered in a good procurement process. We have to understand how OpenACR (previously OPAT) fits into this.

Accessibility Statements

All vendors (and clients) should have an accessibility statement that clearly outlines their public statements about why accessibility matters to their organization, how they test that their work is accessible and what someone should do if they find barriers when using their product/service. It should be informative and not just a legal boilerplate. Those don't serve anyone's needs. Nobody needs to waste their time reading, "This site meets WCAG 2.1 AA.....", when what is useful is knowing what testing methods are done to ensure and maintain accessibility. Vendors should clearly link to their ACRs from the accessibility statement. Accessibility statements should appear in a link in the footer of every page of a website.

Procurement officers should be looking for these when evaluating vendors. It should be made clear in the RFP that vendors are expected to have one and provide a link to their publicly posted accessibility statement.

Accessibility Conformance Reports (Previously VPAT & soon OpenACR)

VPATs have been used for decades now to help establish vendor claims about the accessibility of a product or service. For vendors that do this properly, and for clients who read them properly, this can be a differentiator to help procurement officers pick the more accessible ICT. OpenACR is working to make this easier and to generate standardized documents and compare them effectively. Having a standardized process will help make it easier for procurement officers to pick software that will meet their needs.

It is easier to build accessible ICT if the components you are using already have accessibility built-in. It takes time to implement a digital solution for an agency and customize it to meet the required needs. If agencies do not need to overcome limitations in the ICT that they are buying, then both overall costs will go down and inclusion will increase. It is also useful to have a standardized means to communicate barriers between clients and vendors. Feedback loops are important for identifying and fixing problems with specific versions of ICT (and future releases too).

The evaluation methodology described to generate the ACRs will be similar to WCAG-EM and indeed the ATAG reporting tool. but the target audience and scope of the review will be different. The focus for the Accessibility Conformance Reports is for the state of the tools prior to any contracting is done.

Accessibility Evaluation Reports (WCAG-EM)

These reports are really useful. Most contracts should include an evaluation phase at the end. WCAG-EM is a great model to do this for the web and possibly for other ICT in the future. After the launch of a site, it is useful for everyone to know that there will be an evaluation to see how accessible the end product is. It may be that there are barriers introduced by content people, or by demands of the client-side project manager.

Efforts should be put in here to understand where barriers have been introduced and to learn from the process. An evaluation report may also include feedback from the accessibility statement of the delivered product/service. A good user experience for everyone is key for accessibility. This will change over time, so it may be useful to do Accessibility Evaluation Reports on an ongoing basis to see that new barriers aren't added and that the ICT keeps up with the best practices of the internet.