Download the document Accessibility Contract Language FAQs doc format of accessibility_contract_language_021009.doc

Frequently Asked Questions Regarding
Required IT Accessibility Contract Language
Information Technology Division

This release addresses questions that Massachusetts Executive Department agencies, agency counsel, procurement team leads, and their Chief Information Officers (CIOs) may have with regards to incorporating and implementing required contractual language regarding IT Accessibility.

1. What is the basic requirement?

As of December 1, 2006, all Requests for Quotes (RFQs) issued by Executive Department agencies under statewide contract ITS33 (and addressed to technical specialists, solution providers, and business process reengineering vendors), and all Request for Responses (RFR) for information technology solutions for which such agencies have received permission from OSD to post their own RFR, must include specific language that addresses IT accessibility. This language becomes a contractual term between the vendor and the procuring agency.

We suggest that each procurement management team member participating in developing an RFR or RFQ carefully review the required IT accessibility contractual language to insure that all team members understand its implications. In summary, the IT accessibility contract language requires that:

  • The system complies with ITD's Enterprise Information Technology Accessibility Standards ("ITD Accessibility Standards"), which includes standards for functional performance criteria, applications, video and multi media, training, testing, and documentation and incorporates most of the objective and measureable ITD Web Accessibility Standards.
  • If the vendor is required under the contract to provide any training, it coordinate with the agency in the identification of prospective attendees who may require accommodation and cooperate with the agency in the provision of such accommodation;
  • Any related training or user documentation provided by the solutions provider include alternative keyboard commands that can be substituted for mouse commands; and, if it is to be owned by the agency, be provided in editable format;
  • The system supports a specific Assistive Technology AT/Information Technology Environment List;
  • Prior to delivery, the vendor test the software developed against the ITD Accessibility Standards and the Supplemental Web Accessibility Testing Criteria Version 1.0 under the agreement to ensure that it meets the accessibility requirements itemized in (1);
  • A third party vendor (either a contractor under contract with the procuring agency or the ITD Assistive Technology Lab (ATL)) test the deliverables, (in the latter case at the vendor's expense), and (1) if lack of compliance with the standards is discovered that the vendor cures the defects and the system be retested, and (2) if incompatibility with the AT/IT Environment list is discovered that the vendor cooperate with the agency, the AT vendor and ITD to cure the problem;
  • If the solution proposed under the agreement includes commercial off the shelf software (COTS) or incorporates an application service provider (ASP) arrangement, and there is no apparent accessible COTS or ASP solution, the vendor
  • Does diligence to confirm that there are no reasonable alternatives (i.e. no other accessible COTS with the same features and functionality, and no economic way to develop such software)
  • Secures a roadmap for accessibility from the COTS or ASP provider of the proposed software, and if the COTS or ASP provider refuses to provide a roadmap, works with the agency to obtain a waiver from ITD to use the proposed COTS or ASP solution;
  • Submits the Voluntary Product Accessibility Template ("VPAT") for each piece of COTS that that will be used by end users; and
  • If the vendor and the agency enter a maintenance agreement, it include terms requiring that the vendor cooperate with the agency to resolve interoperability problems related to AT that arise over the life of the system.

2. Under what circumstances is an agency required to incorporate the IT accessibility contract language?

The IT accessibility contract language must be included in solicitations issued by Executive Department agencies on or after December 1, 2006 issued under ITS33 or issued in an RFR that they have received permission from OSD to issue. This language must be included in such solicitations for new systems or for major upgrades of existing systems.

Determining whether the system upgrade is a major upgrade versus a minor enhancement is a judgment call that should be made by the project manager, business sponsor, and CIO. The team should analyze such factors as the expected cost of the project; whether the upgrade will include a complete re-design or re-write of existing code; whether the upgrade will incorporate substantial new features and functionality; the expected person hours required to complete the upgrade; and the expected project duration (e.g. a two week project versus a nine month project). A major upgrade would tend to require a significant financial investment, include new code components or require a major re-write of existing code; require significant person hours for completion, and typically be completed over the course of many months rather than days or weeks. A minor upgrade would tend address bug fixes, minor enhancements to the functionality, and could include code optimizations. However such an upgrade would typically not include major code re-write or functionality revisions to the system.

3. There are two versions of the accessibility contract language, which one do I use?

The Commonwealth first required specific contract language regarding accessibility in IT contracts entered into on or after December 1, 2006. At that time, ITD had not yet promulgated ITD's Accessibility Standards. Thus, the contract language required that the system comply with a subset of § 508 Standards for Electronic and Information Technology Accessibility that had been determined by the Information Technology Division (ITD) and Massachusetts Office of Disability (MOD) to be objective and measurable. This subset of the § 508 Standards was documented in the "Interim Software Testing Criteria Version 1.0".

In 2008, ITD promulgated the Enterprise Information Technology Accessibility Standards which incorporate many of the provisions of § 508 Standards and of the ITD Web Accessibility Standards that are objective and measureable. Thus, as of February 17, 2009, the dates the updated Accessibility contract language was issued, procurements for IT solutions must include a reference to this most recent version of the accessibility contract which incorporates the Enterprise Information Technology Accessibility Standards, rather than citing to a subset of the § 508 Standards.

 



Date Range

Relevant Accessibility Contract Language

December 1, 2006 through February 17, 2009

November 2, 2006

Mandatory Contract Language for Executive Department Solicitations related to the Acquisition of Information Technology Systems

February 17, 2009 through present

February 17, 2009

Mandatory Contract Language for Executive Department Solicitations related to the Acquisition of Information Technology Systems

4. Where can I obtain a copy of the ITD Enterprise IT Accessibility Standards and a copy of the Supplemental Web Accessibility Testing Criteria ?

Both relevant standards are posted on ITD's web site at www.mass.gov/itd.

5. What is the Assistive Technology AT/IT Environment List?

The AT/IT Environment List is the itemized list of the assistive technology and the IT environment that needs to be supported by the application or system that is being developed by the vendor.

If the user base for the system being solicited consists solely of Commonwealth employees, agencies should survey the user base to determine what assistive technologies are being used by employees, and in what IT environment, and ensure that those assistive technologies and those IT environment features are cited on the AT/IT List. The IT Environment may include, for example, the desktop configuration, internet access speed, and operating system parameters for the system or application. For example, is the application expected to run on Windows 2003, NT and/or Linux? These specifications are part of the IT Environment List. If an agency conducts a survey of the potential users of the system or application and discovers that none of the potential users currently use assistive technology, then the agency should obtain a standard list of AT from ITD's Accessibility Technology Lab.

If the user base for the system being solicited includes external users (i.e. non Commonwealth employees), the agency should obtain a standard AT/IT Environment List from the ITD AT Lab.

The AT/IT Environment List must be created or obtained prior to the posting of the RFR or RFQ, and incorporated as part of the IT accessibility contract language.

6. Why is there a different standard for remedying a vendor's failure to comply with the accessibility standards versus a vendor's failure to provide interoperability with the AT?

A vendor that builds a software solution for the Commonwealth has control over the design and coding process and is thus well-positioned to ensure that the system meets the required accessibility standards. By comparison, the same vendor is in a poor position with respect to ensuring that assistive technology used by users will interact seamlessly with either the vendor's software or the operating system on which it runs. There is no industry standard for assistive technology-to-operating system or assistive technology-to-application interfaces. Because there are no standards for programming interfaces between operating systems, assistive technology and third party software, the contract language requires a vendor to use its best efforts and cooperate in the resolution of interoperability issues.

An ITS33 vendor who proposes a solution to a state agency that includes commercial off the shelf software has the option, under the required contract language, of either proposing COTS that meets the Commonwealth's standards or acknowledging the accessibility limitations of the COTS that they propose so that the agency can seek a waiver from ITD to use such software. Vendors who, despite having these options, fail to either propose accessible COTS or disclose the accessibility limitations of the COTS they propose are held fully responsible for the cost of their choices.

7. How do I incorporate the IT accessibility contract language into my RFR or RFQ?

The required language is posted on COMM-pass under ITS33. Go to www.comm-pass.com and select search for contracts. Then search for statewide contract ITS33. Click on the result set related to ITS33 and under the forms and terms tab, the required accessibility contract language is posted as a form. Open that form and copy and paste that language into the relevant RFQ or RFR before the solicitation is posted on COMM-pass or otherwise distributed to the vendor community. The form language can be tailored to match the specific defined terms of your solicitation (for instance, the name of your agency, or the way that you refer to the successful bidder or vendor in your RFQ). It can also be tailored to match the term that you use for discrete deliverables under the contract.

8. Do we need to include the IT accessibility contract language if our agency amends an existing statement of work (SOW)?

Generally an agency will not need to incorporate the IT accessibility contract language when amending an SOW given that if the SOW stemmed from a solicitation posted before December 1, 2006 there is no requirement to include the language. If the SOW relates to a solicitation posted after December 1, 2006, the RFQ or RFR for that solicitation should have already incorporated the required IT accessibility contract language.

9. Can an agency require more accessibility functionality or features in a system or does the IT accessibility contract language reflect the strictest accessibility requirements that may be imposed on a vendor?

The required IT accessibility contract language is a floor not a ceiling for accessibility requirements of a given system. An agency is free to require more in terms of accessibility functionality, testing or related deliverables. Agencies that propose to use alternative language should have it reviewed by ITD's General Counsel prior to posting.

10. When should my agency go out to bid for an accessibility testing firm?

At the time the statement of work with the vendor is executed, or earlier if the statement of work has a short term. Agencies will need to coordinate third party accessibility testing with the acceptance/rejection cycles contained in their statement of work. Agencies that seek to use the ITD AT Lab for such testing must obtain a written (can be by email) commitment from Joe Lazzaro, the Lab's director, for the performance of accessibility testing and the delivery of results within a specific timeframe.

In the future, ITD and MOD will work with OSD to create a statewide contract for third party accessibility testing firms. In the meantime, agencies can contract for such services with and through ITS33 firms.

11. At what level should the vendor perform the accessibility testing?

These standards only apply to end-user applications, thus the end-user application is piece of the software module that needs to be tested under this requirements. When practical, ITD suggests that the vendor perform accessibility testing at the unit level, rather than system or user acceptance testing level. This will enable bugs to be identified and fixed early in the system development cycle.

12. Can an agency accept a deliverable even if the deliverable fails accessibility testing conducted by the vendor or by the third party tester?

Whether to accept a deliverable is always a business decision to be made at the appropriate time in the project lifecycle and with an understanding of the business and legal implications. The SOW should outline the acceptance and rejection process (including the timeframe and consequences of rejection). The agency is free to invoke the contractual language to support rejecting a deliverable or it may decide to accept the software. If agency makes the business decision to accept a deliverable despite that has failed such testing, the agency could be waiving the rights under the contract. We suggest that before making such a decision, the project manager or contract manager consult with agency counsel and the agency's ADA/Civil Rights coordinator to insure that the impact comports with the legal and business requirements of the agency. Remember that the vendor is only obligated to cure its failure to comply with ITD Standards including the ITD Web Accessibility Standards, that are or objectively measureable; its obligation with respect to interoperability issues with specific AT is only to continue to work with the agency and the IT vendor to cure.

13. How does the IT accessibility contract language impact the price of the contract?

The vendor will likely build into the price of the bid the cost of producing a system that complies with the IT accessibility requirements of the contract. Under the terms of the accessibility contract language, the vendor must pay for the third party accessibility testing by giving the procuring agency a reduction in the fixed price or time and materials price of the contract for the cost of such testing. Agency counsel and financial personnel should be involved in structuring the payment terms of the contract to ensure that credits for third party accessibility testing are included among the contract's financial terms.

14. Should an agency require third-party accessibility testing for software delivered under existing contracts (i.e. those contracts that do not include the IT accessibility contract language)?

Whether an agency wants to subject software currently being developed by a vendor to third-party accessibility testing is a business decision for the agency. Note that vendors providing goods and services under ITS33 contracts where the bid was solicited prior to December 1, 2006 are not subject to the new accessibility contract language; they are only subject to the boilerplate language requiring that they comply with the current version of ITD's web accessibility standards. For such vendors agencies can consider conducting accessibility testing prior to deployment of the application or system, and negotiating with the vendor for the resolution of accessibility issues that appear during such testing.

15. The language requires that if a vendor bids a solution that includes inaccessible commercial off the shelf software (COTS) for implementation at the agency or agency use through an application service provider (ASP) arrangement, the vendor is required to provide a cost estimate for developing accessible software that will perform the same functions as the inaccessible COTS in its proposal. How should an agency determine whether the cost of creating new, accessible software to replace the proposed inaccessible COTS is prohibitive?

A vendor who proposes to implement inaccessible COTS or ASP software as part of a solution must provide, in its bid, a cost estimate of the cost of developing an alternative to the inaccessible COTS in the form of a new, accessible application. If the vendor's estimate shows that the cost of creating an alternative to the accessible COTS is reasonable in light of the agency's budget and the scope of the project, the procuring agency should consider negotiating with the vendor for the creation of the accessible alternative to the inaccessible COTS.

In making its determination of the reasonableness of the cost of hiring the developer to create the alternative to the inaccessible COTS, the agency should take into account its budget for the project, including the manner in which investment in developing new software would impact the agency's ability to achieve its overall project goals; the time delay and uncertainty inherent in developing new code rather than relying on existing, tried and true COTS; maintenance costs; and the likelihood that the new accessible software will interact as well with other COTS components of the system as the inaccessible COTS would have.

In most cases, ITD does not anticipate that agencies will find it cost effective to hire vendors to develop new software to replace the inaccessible COTS proposed in the vendor's solution. Most agencies are poorly positioned in terms of time, project management skills, and budget, to manage a software development project. Moreover, in most cases COTS sold to the Commonwealth has been tested by thousands or even millions of users, and been extensively debugged. It is difficult for agencies to replicate the time, effort and funding invested by software publishers in COTS.

16. What are the factors that ITD will examine when determining whether to grant a waiver for the use of inaccessible COTS or ASP software?

The factors ITD will use to determine whether to grant a wavier for the use of inaccessible COTS or ASP software include the following:

  • Whether the vendor performed the due diligence as required under the contract language (see answer to Question 1 above);
  • The degree to which the proposed COTS software complies with the accessibility standards (for example, ITD is more likely to grant a waiver for COTS that meets all but one of its accessibility requirements than it is to grant a waiver for COTS that fails multiple requirements);
  • The estimated cost of creating alternative accessible software to replace the inaccessible COTS;
  • Whether there are known viable alternatives that provide greater accessibility than and reasonably similar features and functionality as the proposed inaccessible COTS; and
  • Whether the potential users of the system are internal Executive Department employees versus external users.

17. How do these requirements affect software that is developed by a Commonwealth agency that does not use a vendor to build the system, rather the agency relies on in-house staff to build and maintain the software?

The required IT accessibility contract language only applies to projects that are built or supported by an outside vendor. ITD encourages agencies to consider accessibility requirements when it is building a software system in-house and to consider employing third party accessibility testers for such projects. Eventually, ITD's ATL plans to train the Commonwealth IT staff in accessible software design, in order to ensure that internally-produced systems are also accessible.

18. What is a VPAT™?

A Voluntary Product Accessibility Template ("VPAT") is a form document that is typically completed by the software publisher for a given product. The information conveyed on the completed VPAT assists Federal and other buyers in assessing the accessibility features of a given product. To learn more about VPAT, you can go the Information Technology Industry Council's website at: www.itic.org.

19. Where can I obtain more information?

The Legal Group at the Information Technology Division

Michelle Burwell (617) 626-4527
Linda Hamel (617) 626-4404
Stephanie Zierten (617) 626-4698

ITD's web-site: www.mass.gov/itd