Writing accessibility requirements in contract language, including Master Services Agreements, Statements of Work, and other product documentation, is where the rubber meets the road in the accessible procurement process. It is where all the work creating policy, growing culture, building relationships, defining requirements, collecting information, and evaluating bids translates into concrete obligations to deliver products that can be used by a diverse workforce.

The more specific an organization is about what it needs in terms of accessibility for employees and applicants, the more likely it is to get accessible products that remain accessible products. The more detailed the consequences of not meeting accessibility requirements, the more likely they are to be met.

Draft Accessibility into Contracts

Best practices for drafting accessibility into contracts and statements of work include incorporating the issues listed here.

Note: When reading this Accessible Technology Procurement Toolkit, please remember that Disability:IN does not provide legal advice. Accordingly, any information provided herein does not represent legal advice and may not be acted or relied upon as such.

• Reference specific standards and legal requirements. Contracts cannot simply say “product will be accessible,” “product will meet federal standards,” or “product will meet WCAG 2.1,” although this type of general language may also be included in contract language. The contract should identify specific standards and legal requirements. Contracts should state that legal requirements and standards will be met at time of delivery and throughout the term of the contract, and apply to product revisions, updates, patches, and new releases.
• Address potential changes in standards. The contract needs to anticipate a change in accessibility standards or legal requirements during the term. For a standard such as WCAG, language can require compliance with WCAG 2.0 AA, “or the most current version.” For a change in law, consider a provision to re-open the contract if either party believes the change materially impacts legal obligations.
• Specify testing protocols, including usability. The contract should include requirements identifying automated tools to be used, manual testing protocols, and usability testing. Specify frequency of testing and place(s) along the development process where testing will occur. Require and spell out details of how disabled people will participate in the process. Usability testing provisions should identify types of assistive technology to be tested with as well as operating system and browser combinations. See Accessible Technology Procurement Toolkit section, “Information about Product Testing and Verification.” Details of a final accessibility test at the time of delivery by the vendor should be specified, identifying the type of testing, verification, etc. All testing results should be provided to the purchaser within a stated timeframe.
• Establish a maintenance plan. The plan should include specific obligations that updates, new releases, etc. will meet the referenced standards and testing/evaluation requirements. Language should specify how updates will be tested prior to release. All testing results should be provided to the purchaser within a stated timeframe. As explained in the next item of this list, the maintenance plan must specifically address how both known and unpredicted accessibility barriers will be remediated, including timeframes for responses if/when accessibility issues reported and timeframe within which to make fixes. As part of the maintenance plan, consider including an obligation to identify accessibility enhancements in release notes. Language could be as simple as “[Vendor Name] will include information about accessibility improvements, as applicable, in the release notes for each new product release.”
• Address known accessibility gaps and bugs and specify a remediation plan. Gathering honest information early in the procurement process means you will have accurate information about any features and functions that are not accessible. The contract should identify those gaps in accessibility and state how and when they will be remediated. Ideally, remediation will occur ideally prior to product delivery, but if not at a stated time along a roadmap to full accessibility. Any costs associated with meeting accessibility should be clearly spelled out. As for known accessibility gaps that will not be remediated at the time of delivery, explore needed interim fixes or work-arounds, including costs, with the vendor.
• When technology incorporates software that a supplier purchases from a third party the contract must address what will happen if that third-party’s technology is the cause of accessibility barriers. To avoid finger-pointing down the road, the same issues of testing, indemnity and standards must be baked into your supplier’s contracts with its vendors. Ask to review those contracts; they are an aspect of ensuring accessibility of your workplace tools.
• Address unpredicted accessibility gaps and bugs. The most effective contract is a sustainable document that enhances relationships with clarity of content. Postdelivery accessibility bugs must be addressed. Despite the best of intentions, they are like to occur. Contracts must be clear about:
  • A reporting and response process for accessibility barriers.
  • When barriers/bugs will be remediated.
  • Who is responsible for remediation and it’s cost.
  • Who is responsible for interim work-arounds and their cost.

Discussing questions like the following can lead the parties to contract language on these issues that is direct and workable:

• • Let’s talk about what will happen if a deaf employee cannot receive online training because the captioning on the product we are purchasing is not accurate?
  • Let’s think through how we’ll handle call to our help desk that an applicant who cannot hold a mouse could not submit an application because the submit button cannot be reached through the keyboard.

Thoughtful conversation during negotiations about these types of questions can lead to language that covers the many unknowns that occur after the ink is dried.

• Indemnity: The contract should specify who will bear the cost of remediation for accessibility (including usability) barriers discovered after product delivery. Consider contractually shifting liability for noncompliance to the third-party supplier. In the United States especially, with a growing amount of litigation around inaccessible technology, the contract should specifically address who will bear the cost should a legal action be brought over lack of access.
  Potential costs from litigation could include remediation expenses, monetary payment to plaintiffs with disabilities, and attorneys’ fees. Attorneys’ fees could include those incurred by both the organization purchasing the technology, as well as the fees of the plaintiffs’ lawyer under federal or state non-discrimination laws Accessibility issues may also lead to other costs, including paying for an on-site workaround or modification, or paying for additional help for an employee with a disability because the technology is not independently usable. All of these potential expenses arising from accessibility barriers should be discussed during contract negotiation about indemnification provisions.
• Breach of accessibility terms of the contract: What if one or more of the carefully negotiated accessibility provisions in the purchasing contract are breached? The agreement needs to anticipate breaches and spell out both consequences and processes for resolving disputes. Solutions to a breach can range from giving the vendor an opportunity to remedy the accessibility barrier(s) within a specified period of time, to a mandate to pay a certain amount of money for each day / week / month that the problem is not remediated, to conditioning a portion of purchase or licensing fees on fixing certain accessibility bugs, to some combination of these possibilities and others. The most important thing is to have clear consequences, a clear understanding of who will pay for any costs resulting from the access barrier/s, and how disputes will be handled.
• Collaboration or conflict? In determining how to draft language in the event of a breach, it is important to remember that the relationship between your organization and its workplace tool vendors is often a long and complex one. Resolving issues without conflict can help preserve that relationship for the future. Consider whether early stages of dispute resolution over accessibility-based breaches are best resolved through cost-effective processes such as structured conversations or mediation. These methods and other collaborative strategies allow parties to focus their efforts towards creative, side-by-side problem solving. Consequences can of course be escalated if disputes are not resolved in a timely manner.
• Identify supplier internal accessibility efforts. Product documents should identify the supplier accessibility team for both technology and service. The vendor’s accessibility policy and supplier training protocols for its workforce should be specified. The vendor should be required to maintain these internal accessibility commitments during the term of the contract.
• Contract language should provide as much transparency as possible about accessibility enhancements planned or available during the contract term. This can be done with language requiring disclosure of accessibility enhancements delivered to/requested from other purchasers, but privacy and confidentiality concerns are implicated by this type of contract language, and even redacted information may not be appropriate or acceptable. At a minimum, the vendor’s accessibility roadmap should be updated and shared on an agreed upon schedule, such as quarterly or bi-annually. Written confirmation that each benchmark deadline along the roadmap has been met, or problems encountered in meeting deadlines, also promote transparency and help ensure obligations are met.