This part of the Accessible Technology Procurement Toolkit will help your organization develop an accessible procurement policy for workplace tools. The suggestions here can be modified and expanded for policies impacting customer and public-facing technology purchases or for integrated policies embracing all purchased technology.

This is just one of the ways to begin or expand on the process of ensuring that your organization’s third-party digital tools are available to all employees and applicants. Review other sections of this Accessible Technology Procurement Toolkit to determine the best starting point for your organization.

Develop an Accessible Procurement Policy for Workplace Tools

Why Policy Matters and How it Fits in with a Broader Accessibility Program

An accessible procurement policy for employee/applicant technology tells suppliers that an organization expects the technology it purchases to be accessible to everyone in the workforce. It tells employees and applicants with disabilities that inclusion matters and that your organization recognizes that diversity is more than just getting in the door.

An employee / applicant technology procurement policy should not be the only aspect of an organization’s overall accessible technology policy. Best practice supports an organization-wide accessibility policy that also includes

(i) employee and applicant technology developed internally;
(ii) purchased and internally-developed customer-facing web, app, software, and other technologies.

Each organization is unique and knows best how to structure its own policy. If your organization chooses to have a single procurement policy for both employee/applicant and customer facing software, it is a best practice to specifically reference the policy’s application to workplace technologies.

While the recommendations in this Accessible Technology Procurement Toolkit are focused on the purchase of software and other technologies used by applicants and employees, many of its aspects can be shaped to support broader accessibility initiatives.

What Technology Should the Accessible Procurement Policy Apply To?

Digital accessibility is more than websites. Here is a list of the types of products and services that require accessibility and that your organization might purchase from thirdparty vendors. Create this type of list for your own organization. It can be an important exercise in educating around accessibility and building accessibility culture.

Personalizing this list for your own organization can also help create a common language for talking about these types of technologies. Specialized terms such as Information and Communications Technology (ICT) and Electronic and Information Technology (EIT) may be familiar to those working with this language every day but may be unknown to others who need to be part of the accessibility ecosystem in your organization.

Begin your list with a broad coverage statement such as:

“This policy covers vendors / suppliers who provide digital [or Information and Communications Technology (ICT)] [or Electronic and Information Technology (EIT)] content, functionality, systems, services or hardware that employees or applicants (and customers, if your organization has chosen to develop a single accessible procurement policy) may interface with.”

Then, identify specific items that are within the broad definition, with a phrase such as “This includes but is not limited to.” Here are some types of technology to consider as you create your organization’s list:

• Services involving design, development or testing of content, services or functionality for – or that render interfaces for – the Web, mobile, emails, voice response, and interactive kiosk systems.
• Software – whether web, mobile, cloud-based.
• Document services such as design, creation, and implementation of PDFs, presentations, other digital documents, spreadsheets (whether for dialog or analog distribution).
• Video, audio or multimedia – including video, audio, or multimedia content (live or pre-recorded) and media players or other mechanisms for playing and controlling media.
• Telecommunications products – including wired, analog and digital wireless, and Internet based products.
• Self-contained, closed products – Products that have embedded software and are commonly designed in such a fashion that users cannot easily attach or install assistive technology. This includes kiosks, copiers, printers, and other similar types of products.
• Hardware – including desktops, laptops, mobile devices or other handhelds, workstations, and servers.
• Communication channels.

Recommended Elements of an Employee/Applicant Accessible Procurement Policy

Elements of a robust procurement policy designed to ensure that disability talent can use all workplace tools include the following:

• Statement about why accessibility is important to your organization. As much as possible, explain how accessibility is consistent with and part of your organization’s mission. Connect the statement to the people you serve and the people who work for you. Microsoft does this in the following statement from Jenny Lay-Flurrie, the company’s Chief Accessibility Officer, which incorporates the organization’s overall mission of empowering people through technology:

“Technology can empower people to achieve more, help strengthen education opportunities, and make the workplace more inviting and inclusive for people with disabilities. And with more than one billion people with disabilities in the world, Microsoft believes accessibility and inclusion are essential to delivering on our mission to empower every person and every organization on the planet to achieve more.”

• Statement of your organization’s commitment to purchase accessible technology used by applicants/employees. Be as specific as possible, recognizing that 100% accessibility may not be available at the time of purchase. Language could state, for example:
  We will be selecting the most accessible solution that meets other product requirements. Solutions that demonstrate a commitment to accessibility will be preferred over those that don’t. When fully accessible technology is not available, solutions that are transparent in identifying known accessibility defects/limitations and the offeror’s strategy (including timeframe) for mitigating those defects will be given strong preference.
• General reference to local, state, national, and global law and policy accessibility obligations. The compliance aspect of accessible procurement is an important ingredient in an accessibility program. 173 nations have signed the United Nations Convention on the Rights of Persons with Disabilities (UNCRPD) that includes strong accessibility language. In the United States, the European Union, and across the globe, legislative and judicial attention is increasingly focused on the rights of disabled people to participate in every aspect of the digital world.
  Note: Detailed references to applicable law should be included in contract and pre-contract documents for each particular purchase.
• General expectations for product accessibility testing during production and at the time of delivery. Language could state, for example:
  

  “We expect that all technology will be tested for accessibility during the development process and at time of delivery, and that testing protocols and results will be documented and provided to us in a timely fashion. Our organization will verify testing results at time of delivery.“

  Note: Detailed testing requirements (including rules, timing, etc.) should be included in contract and pre-contract documents.

• Person / group(s) in your organization responsible for accessibility generally, including contact information. Organizational policy should list a central location where people can learn of accessibility subject matter experts and teams. In contract and pre-contract documents, additional individuals / teams responsible for accessibility of the particular product should be listed.
• General statement of supplier responsibility for remediating accessibility barriers. Policy language could state, for example:
  

  “It is the responsibility of our suppliers to correct accessibility defects revealed during the development and testing processes and after product delivery.”

  Note: Detailed statements of responsibility, including timing, reporting, and consequences should be specified in the contract and pre-contract documents.

• General consequences of lack of accessibility. Policy language could state, for example:
  

  “At our company, we take accessibility seriously. Contract documents between our organization and our suppliers spell out consequences of delivering technology (including technology updates and new releases) that do not meet contractual requirements for accessibility and usability.

  Note: Detailed consequences should be spelled out in contracts and pre-contract documents.

• Expectation that each supplier has its own accessibility policy and a public Accessibility Statement that includes contact information. (Find examples of Accessibility Statements and Accessibility Statement resources here.(External link))
  Policy language could state, for example:

  “We expect our vendors to show their commitment to digital accessibility by maintaining a public accessibility statement that includes contact information for the person/s responsible for accessibility.”

• Statement of technology covered by the policy.

Policy Exceptions

Strict limitations should be placed on any situation for which an exception to accessibility requirements is allowed. Best practice dictates that an exception policy should include the following:

• Development of a process for identifying and justifying exceptions.
• Identifying the person/s responsible for approving any exception to accessibility requirements.
• Requirement that the identified person/s sign off on any exception.
• An obligation to establish a roadmap with timeframes for explicit deliverables with a reasonable end date by which the technology will be accessible.
• Consequences of not following Exception Policy and not meeting roadmap targets.

Update Standard Procurement Documents to Reflect Accessibility Commitment

Supplier Codes of Conduct (SCoC), Master Services Agreements, and related documents should be updated to clearly state your organization’s commitment to accessibility. While specific accessibility details will go in product requirements, all documents that address procurement can be used to confirm your organization’s accessibility commitment and create obligations for accessible deliverables.

Incorporate legal-approved accessibility language into template Master Service Agreements and supplemental standard templates that are particularly focused on technology products and services. Add this language at time of renewal of Master Service Agreements – as compared to amending contracts – to increase efficiency and fit into existing processes.

Examples of baking accessibility into general procurement documents from Disability:IN partners and industry leaders, and links to documents referenced in this section, can be found in the Sample Document Section of this Accessible Technology Procurement Toolkit.

Standard procurement documents should state your organization’s basic expectation that technology will meet accessibility standards, as Accenture does in its Supplier Standards of Conduct:

“Accenture suppliers who sell or license hardware, software, web, learning and information technology or offer technology solutions as part of their products and services must also ensure that all products, software and/or services that are provided to Accenture meet all relevant accessibility standards, including (but not limited to) Web Content Accessibility Guidelines 2.0AA (WCAG 2.0 AA) or any update or revision to these Guidelines.”

Adding the “why” of accessibility strengthens language and shapes it to your organizational goals. Microsoft does this in its Supplier Code of Conduct language:

“Creating products and services that are accessible to people with disabilities is a core tenet of Microsoft culture to fulfill not only our legal obligations but also our mission of empowering every person on the planet to do more.”

Flexible language emphasizes that accessibility is relevant to all technologies, not just websites, and must be measured against current standards. Microsoft’s recent refresh to its Supplier Code of Conduct, for example, requires that suppliers comply with:

• The current version of the international accessibility standard Web Content Accessibility Guidelines (WCAG) Level AA when creating any deliverable.

Encouraging suppliers to create their own culture of accessibility demonstrates that your organization’s expectation extends beyond compliance. JPMorgan Chase includes this type of language in its Supplier Code of Conduct:

“The firm actively encourages Suppliers to embrace diversity in their own business practices by documenting a diversity and inclusion approach that includes ways to identify, measure and improve inclusion and embedding accessibility standards that go beyond minimum compliance.”