Introduction

Disability:IN and its corporate partners are committed to a diverse workforce that includes people with disabilities. In the twenty-first century, diversity and inclusion is more than having a hiring process that encourages applicants with disabilities and more than employing and offering promotional opportunities for workers who are disabled. The private sector must also provide applicants and employees, including those with disabilities, the digital tools and support they need to thrive in the workforce.

A commitment to diversity and inclusion requires that digital tools, including software applications and other technologies, are accessible to and usable by employees and applicants with disabilities.

Back to Toolkit Sections

1 Why Accessible Digital Tools Matter

The ability to attract, retain, and develop talent in a diverse workforce is a corporate and financial imperative. Accessibility and inclusive design are integral aspects of all software applications and other technology that employees and applicants with disabilities need for success in the workforce.

Today’s business leaders know that accessibility matters throughout the employee lifecycle: from the recruitment, application and hiring process to on-boarding and training, to benefit portals, to tools needed to do the job and apply for advancement opportunities, and to all communications technologies.

And today’s business leaders know that while disability is a core component of a diversity commitment, diversity also exists within and among people with disabilities. Employee and applicant technology must serve the needs of all users, including people with physical, sensory, and cognitive disabilities.

The labor force participation rate for working-age people with disabilities was reported at 32.5 percent in June 2018, as compared to 77.6 percent for working-age people without disabilities. Accessible workforce technology is an essential element of improving this dismal statistic.

It is the goal of these Disability:IN resources to assist organizations committed to changing these numbers.

Back to Toolkit Sections

1.1 Who Are These Resources For

These resources are for technology purchasers who demand honest, detailed, and robust answers to accessibility inquiries. They are for purchasers who insist upon technology that works for all applicants and employees without unnecessary delay or unwarranted costs. And they are for purchasers who seek to avoid the legal and reputation risk inherent in purchasing technology that excludes a portion of the workforce.

These resources are also for suppliers who want to meet customer needs for a diverse workforce. They provide guidance for vendors to understand the type of detail expected from them by purchasers who are committed to diversity and inclusion.

For both suppliers and purchasers, this Accessible Technology Procurement Toolkit. recognizes that in the 21st century, accessibility is not merely a feature of software and other technology. It can no longer be something tacked on for an added cost on a slower delivery schedule.

Instead, suppliers must prioritize accessibility in line with requirements such as data security, privacy, and performance. Accessibility must be demonstrable and there must be a strategy in place for maintaining and improving accessibility post-purchase.

These resources are designed to give organizations needed tools that will lead to the purchase of digital products with baked-in accessibility that is maintained throughout the product lifecycle. They are for organizations that take accessibility seriously and consider accessibility an essential quality of technology purchases.

Back to Toolkit Sections

1.2 How to Use These Resources

This Accessible Technology Procurement Toolkit offers content – including best practices, checklists, suggested contract language, sample documents, and links to other resources – designed to assist organizations that want to do everything possible to purchase technology that all applicants and employees can use.

For some organizations, all of the ideas in this Accessible Technology Procurement Toolkit may be new. For others, concepts will be familiar, but details may be missing from current organizational processes. And for organizations further along the accessibility journey, this Accessible Technology Procurement Toolkit will reflect best practices already in place.

Wherever you are in your journey to a fully inclusive and accessible workplace, take what is helpful in the order that makes sense for your organization. Incorporate what you can now and prepare a roadmap to incorporate other elements later. Work with your employees with disabilities and tailor the ideas presented here to fit the unique character of your organization.

In other words, make this Accessible Technology Procurement Toolkit your own; shape it in the ways that best meets the needs of your organization.

Back to Toolkit Sections

1.3 A Note on Language

Every organization has its own vocabulary to describe processes, systems, management structure, and more. You may find language in this Accessible Technology Procurement Toolkit that does not match the customary terminology used in your workplace.

For example, some companies use the term “supplier,” while others prefer “vendor.” The words “training,” “education,” “development,” and “learning” may be used to refer to the identical process of imparting information to employees. We invite you to make this Accessible Technology Procurement Toolkit your own by using the words and phrases your organization is most comfortable with.

Here is an explanation of five terms you will find throughout these resources:

1. Accessibility: This Accessible Technology Procurement Toolkit uses the word “accessibility” to mean the quality of technology and digital content that allows a wide range of users, including employees and applicants with disabilities, to fully and independently perceive, operate, find, navigate, understand and interact with all its functions and features with relatively the same ease of use as is required from people without disabilities.

   These resources use the terms “accessible” and “accessibility” to include ideas and principles of usability and inclusive design. Accessibility is not achieved by passing a single test; if technology and content is not usable, it is not accessible.

2. Digital Accessibility: Accessibility is about more than websites. This Accessible Technology Procurement Toolkit uses the phrase “digital accessibility” to broadly cover the accessibility of digital tools and content including websites, software applications, kiosks, and a host of other technologies. Additional examples of digital workplace tools can be found in Section 2 of these resources.
3. People with Disabilities: Employees and applicants who need accessible technology have a wide range of disabilities, both visible and hidden. An accessible procurement program benefits people with vision, hearing, physical, cognitive and learning disabilities, and other disabilities. This Accessible Technology Procurement Toolkit includes ideas about ways in which people with disabilities can assist organizations committed to purchasing accessible technology.
   
   Reflecting the thinking of the disability community, this Accessible Technology Procurement Toolkit uses the terms “people with disabilities” and “disabled people” interchangeably. The term “disability talent” is also used to reflect the value people with disabilities bring to the 21st century workforce.
4. Purchaser: Except for very small organizations, no one person is the “purchaser” of third-party workplace technology. This Accessible Technology Procurement Toolkit uses the shorthand “purchaser” to include not only the person signing the contract, but also decision-makers, influencers, product owners, and others with a direct responsibility for bringing technology into an organization.
5. Technology: This Accessible Technology Procurement Toolkit uses the overarching word “technology” to refer to the vast collection of digital tools, products, software applications, websites, peripherals, digital documents, and more that are essential to the modern workforce. These terms are at times used interchangeably, as are ”Electronic and Information Technology (EIT)” and “Information and Communications Technology (ICT).” These phrases often appear in accessibility standards and regulations.

Back to Toolkit Sections

1.4 We Value Your Feedback

This is a living document. We invite you to share your experiences with these resources. And we encourage you to share additional resources and tips your organization has found useful to guaranteeing workforce technology that is accessible for everyone.

Please send comments to: Liz@DisabilityIN.org.

Back to Toolkit Sections

Get Started

This part of the Accessible Technology Procurement Toolkit offers the following steps to help your organization begin its journey to accessible third-party technology.

• Develop an accessible procurement policy for workplace tools.
• Develop and involve employee / business resource groups.
• Conduct an inventory of vendor products impacting employees and applicants.
• Understand accessibility needs from a user perspective.

These are just some 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.

Developing or expanding your culture of accessibility, or defining product accessibility requirements, for example, may be the point of entry best suited to your organization.

The most important thing is not where you start, it is that you start.

Back to Toolkit Sections

2 Develop an Accessible Procurement Policy for Workplace Tools

2.1 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.

Back to Toolkit Sections

2.2 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.

Back to Toolkit Sections

2.3 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 deliveringon 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.)
  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.

Back to Toolkit Sections

2.4 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.

Back to Toolkit Sections

3 Conduct an Inventory of Third-Party Digital Workforce Tools

Does your organization have a central resource listing all third-party technologies in use by employees and applicants? Compiling an accurate list is a crucial step for incorporating accessibility into your procurement process and making sure that employees and applicants can use the tools they need to thrive in your workforce.

Suggestions for the types of information to collect are in the following section. Depending on the data you already have available and the size of your organization, you may want to begin by creating categories and priorities, and conducting detailed inventory based on those groupings. For others, a full inventory may be a more useful first step.

The early investment of time and resources in conducting an inventory will pay off. Not all of your organization’s existing technology with accessibility and usability barriers can be remediated at once. If the task seems too big, it may not be undertaken at all. Categorizing and prioritizing, and recognizing the scope of the project, helps manage expectations and serves as the foundation for a realistic roadmap. And of course, parallel to an inventory of existing technology and vendors, processes and procedures can begin to ensure that accessibility is baked in to new technologies and vendor relationships.

Back to Toolkit Sections

3.1 Collect Data

The following information should be collected during an inventory of tools used by employees and applicants:

• Name of product / technology / service.
• Product type: web, software, peripheral, etc.
• Name of vendor organization (or identify as developed in-house).
• Name of contact/s within vendor organization or in-house product owner.
• Location (or absence) of vendor’s accessibility statement.
• Location (or absence) of any Voluntary Product Accessibility Template (VPAT) associated with this product.
• Location (or absence) of product release notes featuring accessibility features and fixes.
  Note: Including accessibility information in product release notes is a best practice and should be encouraged. Here are two examples:
  Release notes for ServiceNow and Release notes for Ally for LMS.
• Does the product roadmap include dates for planned accessibility
  enhancements?
• Date the license / contract for the technology is set for renewal or expires.
• Commitment (if any) given by vendor at time of purchase about accessibility (include specifics, including any exceptions to an accessibility commitment).
• Person / group within your organization responsible for the contract with the vendor (who owns the technology / the contract; who has the relationship).
• Has the technology been reviewed for accessibility and if so, when and what were the results. If needed, schedule an accessibility audit and usability testing if one has never been done or if the previous audit was cursory or more than 12 months old.

Back to Toolkit Sections

3.2 Categorize and Prioritize Digital Tools for Accessibility Remediation / Attention

The tool inventory provides information your organization needs to categorize and prioritize technology for accessibility focus/remediation. Consider your organization’s priority factors and categorize / group products in ways relevant to your organization. (For example, categories could be based on use of the product by number of employees, roles, or divisions; by how essential the digital tool is for job duties; or by when the product is set to expire/divest.)

Factors to consider in the process of categorizing and prioritizing tools for accessibility focus might include the following:

• Compliance status with applicable legal / policy standards (How broken is it?).
• Frequency of use by employees/applicants (traffic).
• Importance of use (e.g. once a month but can’t get paid without it; rare but critical usage (e.g. reporting emergencies; receiving emergency information).
• Number and severity of accessibility bugs.
• Place in the applicant / employee life cycle (e.g. is technology used to apply for the job? To file a claim for benefits?).
• Does the tool itself create content that other employees and applicants need? Such “authoring tools” may be seen as having an enhanced accessibility factor because employees/applicants with disabilities need to be able to use them to create content, and the created content must be available to everyone.
• ICT product type.
• Date the product will be phased out.

Information collected and organized by category and priority provides a necessary resource to determine how and when to best approach third-party vendors about the accessibility of existing tools.

Back to Toolkit Sections

4 Involve Disability Employee Resource Groups in Technology Procurement Efforts

Many organizations have employee resource groups (ERGs), also known as affinity groups or business resource groups. These are comprised of employees who selfidentify as disabled and others who have come forward to be in community with their co-workers with disabilities at every level.

As much as possible, all accessibility initiatives should include people with disabilities. ERGs and their members can potentially contribute to many aspects of the accessible procurement process. Here are some best practices for involving Disability ERGs in ensuring the accessibility of applicant and employee third-party digital tools:

• Make sure the group knows that your organization is working to ensure that applicant / employee tools are accessible. Ask for ideas about how best to involve the group and its members.
• Ask employees with disabilities to share their experiences with workplace and applicant software and other technology. Answers can help inform the categorization and prioritization aspect of the third-party digital tool inventory.
• Work with your ERG to create a survey to gather user experiences and stories. Stories can focus on the role of disabled employees in your organization and the ways that technology helps disability talent thrive or creates roadblocks.
• Involve ERG members in testing and giving feedback on technology under consideration.
• Involve ERG members in defining functional accessibility needs for particular disabilities.
• Involve ERG members in product evaluations during the procurement process and meetings with vendors.

ERG members can support an organization’s accessible procurement efforts in these ways and others. And an organizational focus on accessible procurement can both help grow and strengthen internal communities of employees with disabilities and attract new disability talent.

Don’t have a Disability ERG?
Check out Disability:IN’s Employee Resource Group/Business Resource Group Leadership Committee and its Resource Page for more resources, support and ideas about developing and enhancing organizational ERGs.

Back to Toolkit Sections

5 Understand Accessibility Needs from the User Perspective

An important component of communicating employee accessibility needs to vendors is sharing stories of employees and applicants needing accessibility. These stories are also crucial to building a culture of accessibility.

Having employees with disabilities participate in meetings with the vendor to point out biggest pain points with access barriers can be an effective way to drive home the accessibility message. This type of meeting also helps build and reinforce relationships that can strengthen the entire accessible procurement process.

Short vignettes about how applicants and employees with disabilities use tools– or cannot use tools without accessibility – can help both suppliers and your own teams better understand why accessibility matters.

Creating these vignettes internally has the added benefit of involving employees with disabilities and providing internal learning opportunities. Employee / Business Resource Groups can assist in this effort.

These resources can also help:

• The Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) offers a series of short videos that communicate the importance of accessibility from the user’s perspective. With the tagline “Essential for Some, Useful for All,” the videos can be found here: W3C Web Accessibility Perspective Videos. Many focus specifically on employees (see, e.g. the video on the need for keyboard compatibility here: W3C Web Accessibility Perspective Video on Keyboard Compatibility.
• How People with Disabilities Use the Web, another resource from WAI includes a list of “Stories of Web Users” that can be used as is, or as a model for building your own stories.
• People with Disabilities on the Web, a resource from WebAIM, a non-profit organization based at the Center for Persons with Disabilities at Utah State University, includes detailed articles about how people with visual, motor, hearing, and cognitive disabilities use the web.

Later in the procurement process, this understanding will help shape both conversations with suppliers during marketing research and accessibility requirements in procurement documents.

Back to Toolkit Sections

6 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.”

Back to Toolkit Sections

Build a Culture of Accessibility to Support Accessible Procurement

Embedding accessibility into the complexities of your organization’s procurement is made easier with a culture of accessibility.

A culture of accessibility helps ensure that the next software update does not break accessibility and that the next new purchase works for all employees. It sets the expectation for both purchasers and vendors that accessibility is a baked in (not bolted on) aspect of technology and not an optional feature.

A shift to a culture of accessibility can make sure that money already spent does not need to be spent again (or spent on lawyers) because accurate accessibility information was not asked for, received, or validated as part of the procurement process.

A long lasting, cost-effective accessible procurement program demands a cultural shift. A change in mindset so that everyone in the organization knows “this is how we do business around here. We do everything we can to have an inclusive workforce, and that means we do everything we can to ensure that our technology is accessible.” A change in mindset means accessibility is not a bargaining chip in conversations with vendors, but an inherent aspect of everything purchased to the greatest extent possible.

In the not so distant past, the technology world went through a similar systems change when businesses in every sector came to deeply understand the importance of cybersecurity. Security became a non-negotiable must-have quality of every piece of technology, every workflow, every process and policy.

Organizations baked security protocols into their systems in different ways, all with the same goal: that no technology be procured or deployed without ensuring in every way possible that data will be and remain secure.

A similar effort is needed to ensure that technology used in today’s workforce can be used by everyone in it. In fact, accessibility is closely tied to security. When a disabled employee cannot independently interact with technology and has to ask for help – particularly where financial, health, and personal information is involved – security is compromised. And as with security breaches, accessibility barriers potentially expose organizations to legal and reputational risk.

Just as every team member is expected to know not to disclose private data, so too must everyone in the organization understand that accessibility matters. To do this, there needs to be an awareness that not everyone in a diverse workplace or applicant pool can see a screen, hear audio, or hold a mouse. That not everyone reads the same way, processes information the same way, or can do things quite as quickly, in quite the same order, as others might expect.

Building a culture of accessibility is not an easy task. It may be among the biggest change management projects your organization undertakes. And it won’t happen overnight. There are many ways to build the roadmap that will lead your organization to an accessibility culture, many places to start, and many roles that can contribute.

This portion of the Accessible Technology Procurement Toolkit offers these suggested actions that can help build and grow a culture of accessibility to support your accessible procurement program:

• Educate and communicate across roles and teams.
• Give employees learnings they need.
• Support champions and become part of the local and global accessibility communities.

Back to Toolkit Sections

7 Educate and Communicate across Roles and Teams

• Bring the Right People together
  •  Aspects of accessibility typically live in many different parts of an organization. Does everyone know each other? Are your IT accessibility specialists aware of ERGs and the role they can play in accessible procurement? Are Accessibility SMEs part of the ERG? Does the ERG know how the Accessibility SMEs can assist with usability and accessibility barriers?
  • Consider how the following parts of your organization can interact to advance accessible workplace tool procurement goals: Diversity and inclusion HR, IT, Procurement/Supplier Diversity, Community Relations, Recruiting, Talent Acquisition, Benefits, Accessibility, Government Relations, Communications, Legal/compliance, Marketing, ERG chair, ERG executive sponsor.
  • Monthly or quarterly meetings of representatives of all parts of the organizations that touch disability inclusion and digital accessibility is a best practice that can both aid accessible procurement efforts and minimize risk and reputation damage caused by the lack of access.
  • Ask yourself: Who needs to be connected and what channels do we have to get these groups talking with each other?
• Use all available communication tools and channels.
  • What tools does your organization have to get the accessibility message generally, and the accessible procurement message specifically, out to everyone? Webinars, trainings, libraries, informal and formal meetings, conferences and summits may all be places to talk about your organization’s accessibility program and commitment to purchase accessible workplace tools.
  • How can your organization best communicate the basics of accessible technology? Some organizations create Digital Inclusion Empathy Labs to share the message of digital accessibility in an interactive way. An empathy lab might allow visitors to try assistive technologies such as a screen reader used by blind employees or voice input software used by people who cannot hold a mouse or type on a keyboard. The lab might offer opportunities to learn about built-in accessibility features of every day technologies like the iPhone, Android, Amazon Alexa, or Microsoft PowerPoint. While these environments can help share the message of accessibility, care must be taken to avoid simplifying both disability and accessibility. Align accessibility with other high priority initiatives within the organization. For example, if an employee experience panel is being convened to introduce new technology, include information about accessibility features into the existing conversation and include an employee with disabilities on the panel. An empathy lab should not attempt to simulate what it’s like to have a particular disability. Think of it more as a tool lending library providing people with an opportunity to interact with assistive technology they would not otherwise be familiar with. It is critical to include disability talent in the formulation of this type of project. Employees with disabilities will ideally staff the empathy lab and be able to share experiences with the tools presented.
    Read an article about the UK government’s accessibility empathy lab.

Back to Toolkit Sections

8 Give Employees Learnings They Need

• Determine who in your organization needs to be educated to ensure the success of your accessible procurement program. What do they know now about disability, diversity, and accessibility and what do they need to know as a contributor to your organization’s accessibility program?
• Don’t be afraid to start with basics: What is digital accessibility? Why does it matter to your organization? Why is accessible procurement key to a diverse workforce? Merck used it’s “Tech Talk” initiative to begin a conversation about the basics for those who needed it:
  

  “This session will introduce the term “Accessibility” and how Technology is helping us to enable Accessibility. Digital Accessibility refers to the ability of a website, mobile application or document to be easily navigated and understood by a wide range of users, including those users who have visual, auditory, motor or cognitive disabilities. We will also discuss various steps are being taken at Merck and MSD for Digital Accessibility enablement.”

• Establish teaching goals to support accessible procurement. Common goals may include
  • increasing awareness of ongoing accessibility projects and commitments
  • understanding the scope of third-party technology in accessible procurement efforts.
  • understanding policies impacting accessibility, diversity and inclusion.
  • sharing technical information.
  • identifying role-based involvement.
  • providing opportunities to ask questions and provide feedback about how employees with disabilities use and interact with technology.
• Build culture by providing opportunities for people with disabilities in your organization to share their stories. Your employee resource group can add richness to your program. Stories about disabled employees and the technology they use every day drive home the value of accessible procurement.
• In addition to stories from your own workforce, consider the resources offered by the Web Accessibility Initiative in Section 5 of this Accessible Technology Procurement Toolkit.
• Leverage accessibility efforts already underway. Whatever steps your organization has taken, turn those steps into teaching opportunities. Share your accessible procurement policy and explain the roles needed to make it successful. If you are undertaking an inventory of your technology, let employees know why.
• Find your “Microsoft Box”: When Microsoft built a fully accessible adaptive controller so people with disabilities could enjoy video games, the company was faced with the question: How will its new customers open the box that contains the new controller? This led to the development of an innovative box design that could be easily opened by people with limited mobility.
  You can read the full story in this Wired Magazine article. Your organization too might have its “Microsoft Box” – an accessibility initiative (large or small) that can be leveraged to grow your next initiative and your culture of accessibility.

Back to Toolkit Sections

9 Support Champions and Become Part of the Local and Global Accessibility Community

• Identify and recognize accessibility champions / subject matter experts.
• Develop accessibility allies across the organization and among senior leaders.
• Identify key leadership and get executive buy-in. Who in your organization makes change or manages change? Who can offer help with communications, reinforcement, executive buy- in around the culture shift you are seeking?
• Grow champions by becoming part of the accessibility community – both locally and globally. Many cities have accessibility and inclusive design MeetUps, and there are conferences throughout the year where people in various roles can deepen their accessibility expertise. Find ways to tap in through accessibility
  conferences and local MeetUp groups focusing on accessibility, inclusive design, user experience and other similar topics.
• Build relationships with the local disability community. Relationships with local disability organizations can be a valuable aspect of growing a culture that supports robust accessible procurement. Local organizations can help find people with disabilities for user experience testing, or simply offer opportunities for connection. We recommend leveraging local Disability:IN Affiliates.
• Celebrate Global Accessibility Awareness Day (GAAD). Since 2011, the third Thursday in May has been celebrated as Global Accessibility Awareness Day around the globe. Growing each year, the day offers an opportunity for your organization to focus on aspects of its accessibility program to motivate your teams (and your suppliers), advance your brand, and leverage efforts within your organization. Learn more about Global Accessibility Awareness Day.

Know that you are not doing this alone. Over the last several years, organizations have begun to step forward to share their journey in building a culture of accessibility.

• Here are links to articles about building and sustaining this culture by global corporate leaders and others.
• You can read about the scope of Accenture’s commitment to a culture of accessibility in:
  “Amplifying Accenture People, How Accenture is Enabling Technology Accessibility in the Workplace.”
• One of several articles written by Microsoft employees about the organization’s accessibility culture shift is “Accessibility Basics at Microsoft: Built In. Not a Bolt On.”

Sharing these resources and others with your teams can help make everyone feel they are part of a global momentum to create an accessible digital environment for all employees. And when you are ready, write your own story. Accessibility is a brand differentiator, an internal motivator, and a spark for innovation. Writing about your journey can itself be part of the roadmap of getting to the finish line.

Back to Toolkit Sections

10 Make Vendor Relations Part of Your Accessibility Culture

The culture shift you seek in your organization must embrace your suppliers. How can you plug suppliers into activities designed to create an accessible culture? How can you get vendors in the same room with your organization’s disability talent so accessibility is no longer just a legal mandate or an abstraction but something that impacts people and workplace opportunities?

Social events, lunch and learns, co-authoring a blog post, sharing a podium to talk about accessibility efforts are all possibilities for building vendor relationships based on a shared understanding that technology needs to work for everyone.

General communications with vendors can underscore your organization’s commitment. Charter Communications has created a Vendor Accessibility Letter to encourage partnership and collaboration and is shared externally with vendors to show the organization’s commitment to accessibility while contract language is being modified or added to contracts.

Including disability-owned businesses in your supplier diversity program can support your organization’s vendor accessibility efforts. Make sure teams involved in supplier diversity are part of building accessibility culture. Disability-owned suppliers may be able to offer expertise and resources throughout the procurement process. Learn more about Disability:IN’s Supplier Diversity program.

Back to Toolkit Sections

Get Ready to Buy

Accessibility requirements must be defined and supplier accessibility information gathered whenever an organization purchases, licenses, or renews contracts or licensing arrangements for workplace technology. As early as possible, potential vendors should be made aware that accessibility is a core component of the technology purchase. Standard procurement documents with updated accessibility language should be shared with suppliers and potential suppliers as soon as they are available.

This part of the Accessible Technology Procurement Toolkit includes language, processes, and best practices that can be incorporated into one or more preliminary stages of the procurement process:

• Define accessibility legal requirements and standards.
• Define requirements in terms of people.
• Ask questions…. and more questions about product accessibility and vendor commitment.
• Integrate VPAT information and processes.
• Help Suppliers Understand Accessibility.
• Evaluate Bids for Accessibility.

Back to Toolkit Sections

11 Define Accessibility Legal Requirements and Standards

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.

While accessibility is far more than legal requirements, it is important for everyone involved in the procurement process to

• understand the legal obligations that apply to the software or other technology being purchased; and
• communicate those obligations clearly to potential suppliers.

Legal requirements and standards should be included in requests for proposals and information. Later in the procurement process these legal requirements will become part of a contract, and consequences of not meeting legal obligations will be defined.

Back to Toolkit Sections

11.1 Laws and Regulations Impacting Accessibility

In the United States, federal laws that may be relevant to the accessibility of technology purchases for employees and applicants include:

• the Americans with Disabilities Act (ADA)
• Section 503 of the Rehabilitation Act of 1973
• Section 504 of the Rehabilitation Act of 1973
• 508 of the Rehabilition Act of 1973
• the 21st Century Communications and Video Accessibility Act (CVAA)
• Section 1557 of the Affordable Care Act

Many states have digital accessibility requirements, as do some local municipalities.

In the United States there is an increasing amount of litigation around the issue of website and mobile application accessibility, with a growing number of court orders and opinions addressing the application of disability rights laws to the purchase of technology.

In the past few years a growing number of these cases have sought to use the law to address the accessibility of workplace technology. Recent lawsuits have challenged an alleged lack of digital accessibility in a manufacturer’s applicant and recruitment software, a school district’s employee software, and the workplace technology of a medical records provider. Organizations should consult legal counsel to obtain the most up-to-date legal requirements relevant to the workplace technology being purchased or licensed.

Outside of the United States, global requirements also impact companies with international workforces or those doing business internationally. The Convention on the Rights of Persons with Disabilities has several Articles addressing accessibility, including Article 9 (Accessibility) and Article 27 (Work and Employment). The recently passed European Accessibility Act is expanding accessibility requirements across Europe.

The Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) publishes information on web accessibility law and policies around the globe. You can also find information about global requirements at the Disability:IN Global Directory.

Back to Toolkit Sections

11.2 Standards Impacting Accessibility

Some of these laws and policies expressly incorporate the Web Content Accessibility Guidelines (WCAG) 2.0, which is also ISO Standard ISO/IEC 40500:2012. The current version of WCAG is 2.1, which has yet to be incorporated into most legal standards, represents current best practices. In the United States using WCAG, either 2.0 or 2.1 at the AA level is most common.

Section 508 of the Rehabilitation Act of 1973 includes detailed standards for accessible technology purchased by the federal government. Many states have adopted these standards for technology purchases of state agencies, and they have been incorporated into accessibility requirements applicable to airlines under the United States Air Carriers Access Act. While Section 508 does not apply to private sector purchases, Section 508 standards and the extensive resources available may provide useful information to private sector procurement processes. More information and resources about Section 508 in the VPAT Section of this Accessible Technology Procurement Toolkit.

Standards other than Section 508 and WCAG may apply to the purchase, and suppliers should be made aware of those standards. Other accessibility standards impacting applicant / employee technology include the following:

• The W3C’s Authoring Tools Accessibility Guidelines 2.0, for example, help design web content authoring tools that are both “more accessible to authors with disabilities” and “designed to enable, support, and promote the production of more accessible web content by all authors.” (Authoring tools should prompt
  authors to create WCAG 2.0 or 2.1 AA conformant content. And anything that produces/converts to a PDF must produce an accessible PDF.)
• ISO PDF/UA standard for accessible PDF documents.
• For countries in the European Union, Standard – EN 301 549 sets forth “accessibility requirements suitable for public procurement of ICT products and services in Europe.”

Back to Toolkit Sections

12 Define Accessibility Requirements in Terms of People

Defining accessibility requirements only in terms of laws and standards is not enough. Vendors need to understand that accessibility is about people; your organization’s employees and applicants who will not be able to use software and other technology unless the product you are purchasing is accessible.

In early procurement documents, including Requests for Proposals (RFPs) and Requests for Information (RFIs), as well as meetings with vendors, it is important to put this aspect of the purchase in human terms. Here are some best practices that may help:

• Give examples of particular types of disabilities that employees or potential employees may have for which accessibility is crucial. Be specific about the types
  of people with disabilities who need accessibility:
  • people who cannot hold a mouse because they have cerebral palsy.
  • people who use voice input (dictation) technology because of repetitive stress or other disabilities that impact use of their hands.
  • employees who cannot see a screen because they are blind.
  • applicants who cannot distinguish certain colors because they are color blind.
  • people who cannot hear audible instructions and tones because they are deaf or hard of hearing.
  • employees who may become physically sick when exposed to flashing or cluttered content because of cognitive disabilities or brain injuries.

Giving examples like these avoids inaccurate assumptions about either (or both) accessibility and disability.

• Give examples of why accessibility is needed based on particular functionality of the technology. Consider including statements like the following in early procurement documents.
  • “We need accurate captioning on all video content for our deaf employees.”
  • “We need our technology to work with speech recognition software for employees who cannot use their hands.”
  • “We need this software to be 100% keyboard accessible because we want to attract a wide range of applicants, including wounded veterans, some of whom may not be able to use a mouse.”
  • “We have blind employees who rely on screen reader software, which is one of the reasons we need accessibility.”
  • “Your software generates PDFs / other documents. We need documents that all our employees can read and interact with, including those who cannot use a mouse or see a screen.”
• Include stories in your requirements documents and requests for proposals that drive home the value and importance of accessibility to individual employees. Interviewing current employees for video or print content is most compelling, but stories can also be built in other ways too. Visit the Understand Accessibility Needs from the User Perspective section of this Toolkit for more information.

Framing accessibility requirements in terms of the people who need accessible workplace tools lays the ground work to ask valuable questions – and get accurate responses – when evaluating proposals. Defining requirements in this way makes it less likely that accessibility will be used as a bargaining chip as the contract is being negotiated.

Back to Toolkit Sections

13 Ask Questions … And More Questions About Product Accessibility and Vendor Commitment

Gone are the days when a purchaser could simply ask “is your product accessible,” accept an unverified “yes,” and move on. True workplace accessibility demands detailed questions and confirmed answers not just about the particular product, but about the vendor’s overall commitment to accessibility.

This section of the Accessible Technology Procurement Toolkit offers some areas to explore with vendors about the technology you are purchasing. These questions can be written into early procurement documents including requests for information and proposals, and/or used to create an internal checklist for market research and vendor interviews. The vendor accessibility questionnaire used by Accenture can be found in the Sample Documents section of this Accessible Technology Procurement Toolkit. Vendor responses should be recorded and shared with the vendor for confirmation to ensure accuracy.

Back to Toolkit Sections

13.1 Find Out Exactly What Features and Functions are or are not Accessible

Most technology today is multi-functional. A video player plays videos and also allows users to adjust volume, search for content and move within content. Training modules convey information, collect responses, and evaluate knowledge gained. Applicants / employees with different types of disabilities may be able to use some but not all of a product’s features.

Potential suppliers of workplace technology should be asked at the outset whether they believe an entire product is accessible, or just certain aspects. Rely on your organization’s legal and user-focused requirements to flesh out this answer. Having a detailed list of what features and functionality are claimed to be accessible, with reference to particular types of disabilities, is a good starting point for meeting overall accessibility goals.

Back to Toolkit Sections

13.2 Gather Information about Accessibility Testing and Verification

A potential supplier claiming all or part of a product is accessible should be asked to share documentation about how that conclusion was reached. Accessibility testing, also known as accessibility evaluation, can take several forms and all should be explored with potential vendors.

• If tested by an automated tool, ask for the name of the testing tool, the tool vendors, testing rules and protocols, and when (and how often) in the development cycle testing occurs. If your organization is not familiar with the tool, ask for contact information for the tool vendor and meet to determine tool rules and other appropriate information to evaluate the tools. The W3C Web Accessibility Initiative (WAI) has a useful suite of information about web accessibility evaluation tools that includes guidance on choosing tools and common features and functions. Information in the WAI resource can also guide questions about evaluating technology other than websites. Remember, automated testing is never sufficient to fully evaluate technology for accessibility.
• If manually tested, ask about rules given those conducting the testing and other testing protocols including what features, functionality, and content was tested and when during the development cycle manual testing was done. Was manual testing done in-house or by a third-party vendor? If third party, ask about qualifications of the testers and the nature of the third-party contract, particularly around issues of indemnity for accessibility barriers that may become relevant to your organization’s contract. Were people with disabilities involved in the manual testing program?
• Was usability testing conducted? If so, were people with disabilities included? It is important to find out not only which types of disabilities were represented in usability testing, but the skill of the user, as well as other questions that will reveal a well-thought out (or slapped together) usability test. Find out when usability testing was conducted: having users review a product early in the development cycle and at several points along the way avoids costly fixes later. A review before delivery catches last-minute errors.
• What testing was done to ensure compatibility with assistive technology? Many vendors are familiar with the concept that accessibility helps blind users who rely on screen readers to enlarge text or read text and provide navigation cues out loud. An inclusive workforce may include employees who use other types of assistive technology (AT) including speech output (dictation), text-to-speech learning tools, or alternative input methods like onscreen keyboards or a mouthstick.
• For products that generate content, was produced content (i.e. documents, videos, etc.) tested for accessibility and if so how? For example, if a piece of software produces documents, the documents themselves need to be accessible, as do the tools for producing them. Has software been tested for its ability to support captioning and audio description or video content? Will PDF documents meet PDF accessibility standards? Explore both who is responsible for ensuring accessibility of these types of published content and how that output will be tested.

Ask suppliers and potential suppliers to share testing results to help your organization verify the accuracy of the information provided. If accessibility is verified through a third party, ask to meet with that vendor and ask detailed questions.

Back to Toolkit Sections

13.3 Follow-up When Technology is Not Fully Accessible

What if potential suppliers recognize that all or parts of the technology they offer are not accessible? This is an opportunity for follow-up questions about the lack of accessibility and plans for remediation. Questions should be as specific as possible, and supplier answers must be considered carefully. The following questions and others can help turn potentially inaccessible technology into tools that work for everyone.

• What are the known accessibility barriers (in terms of both legal standards and functional usability requirements)? Use your requirements list to focus the conversation.
• Is there a roadmap with the goal of a fully accessible product? If so, what are the benchmarks along the roadmap?
• What (if any) accessibility enhancements are in the pipeline and what is the expected timeline for completion?
• Does completion of your potential supplier’s roadmap depend on any third-party vendors of the product? If so, what are the consequences of a delivery delay?
• What are the estimated IT hours to ensure accessibility? (If the supplier has no estimate it is unlikely accessibility is a high priority for the organization.)
• What testing will be conducted along the way?
• If there is no roadmap for remediating the existing product, how is accessibility being built in from the beginning on the next full release? (Accessibility from the beginning is often referred to as a product being “born accessible.”)
• Does the vendor verify product accessibility? If a born accessible product will be available within a reasonable time frame, discuss any high priority remediations to the current inaccessible product.”
  • Is verification done in-house or through a third party contract? If accessibility is verified through a third party, ask to meet with that vendor and ask detailed questions.
• Does the product generate or interact with content and if so, how is accessibility of the content handled? For example, if a piece of software produces documents, the documents themselves need to be accessible, as do the tools for producing them. A video player must have accessible controls; who is responsible for captioning and providing audio description for the video content?

Back to Toolkit Sections

13.4 Explore Potential Suppliers’ Internal Accessibility Commitment

What is the vendor’s internal commitment to accessibility for its own workforce and applicant pool?

Understanding how potential suppliers handle accessibility internally can tell an organization a lot about that supplier’s approach to providing the accessible tools needed by a diverse workforce. JPMorgan Chase’s Supplier Code of Conduct encourages such an internal commitment:

“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.”

Here are some questions to help your organization dig deeper into potential vendor commitments:

• Who is responsible for accessibility within the supplier’s organization? In some ways this is a trick question. While one person, group, or team should have ultimate “buck stops here” responsibility, accessibility must be spread across many roles in the development cycle of any technology.

  Front and back end development, quality control, content strategy, architecture, usability are just some roles that are impacted by an accessibility commitment. The way in which the vendor distributes accessibility responsibilities is a worthy avenue of exploration in determining the true nature of commitment, and the likelihood that accessibility commitments will be met.

• How will accessibility bugs/barriers be documented and remediated post-purchase?
• How are accessibility bugs prioritized in the vendor’s Service Level Agreement (SLA)?
• What accessibility requests has the vendor received from others and how were those requests handled? (Note: There may confidentiality and non-disclosure agreements that prohibit the vendor from sharing all or part of this information.)

Back to Toolkit Sections

13.5 Schedule an Accessibility Demonstration

• Ask for an accessibility demonstration. This is something that can happen during the market research and request for information stage, or at the time proposals are being reviewed. Key to the success of an accessibility demonstration is having participation of people with disabilities, from your own workforce or outside organizations. Involve your employee resource group or connect with local disability rights organizations. Some national and international organizations that can assist with locating people with disabilities to help with usability and accessibility testing and demonstrations are listed here.
• Go over the Accessible Procurement Policy for Workplace Tools in detail.
• Develop a checklist for finalists’ meetings and bidder conferences that will capture responses to the accessibility information collected.

Back to Toolkit Sections

14 Integrate VPAT information and Processes

14.1 What is a VPAT?

A Voluntary Product Accessibility Template (VPAT) is a data collection tool for gathering ICT accessibility information for technology subject to Section 508 of the Rehabilitation Act of 1973. The information produced from the VPAT is known as the Accessibility Conformance Report (ACR).

Section 508 is the United States federal government procurement statute, and applies to federal agencies when they develop, procure, maintain, or use electronic and information technology. Many states in the United States incorporate Section 508 standards into state agency purchasing requirements. The most current version of the VPAT is VPAT 2.3, which was released in December 2018.

Most large technology suppliers are familiar with the Section 508 purchasing system and typically have information about the accessibility of their product in a format thatcan be incorporated into a VPAT or ACR.

If your organization sells technology products to the U.S. federal government, or to state agencies, you may also have systems in place to provide or evaluate accessibility information as part of the Section 508 process. Those efforts should be coordinated with all efforts to ensure accessibility of digital tools to support and grow a diverse workforce.

Back to Toolkit Sections

14.2 Evaluating VPATs

Voluntary Product Accessibility Templates (VPATs) should be evaluated with care. Detailed review and questioning avoid situations where a vendor gives an answer that may create legal, reputational, or security risk for your organization.

For example, Section 508 requires that, for covered technologies, “At least one mode of operation . . . that does not require user vision shall be provided. . . .” If the VPAT response states, “Support Line is available,” the product is not accessible.

And a VPAT that says a product is “partially compliant” requires focused inquiry as described elsewhere in this Toolkit.

Back to Toolkit Sections

14.3 VPAT Resources

There are many resources available to assist both vendors and purchasers with VPATs and the Section 508 procurement process in general. Even if your organization is not involved in government purchases subject to Section 508 or related state law requirements, these resources may offer practical ideas for developing and implementing an accessible procurement program focused on supporting and growing disability talent.

• Resources from the Partnership on Employment and Accessible Technology (PEAT), an organization funded by Office of Disability Employment Policy of the U.S. Department of Labor.
  • How and Why to Make VPATs a Priority (blog post).
  • Evaluating proposals and VPATs, part of Buy IT! Your Guide for Purchasing Accessible Technology.
• Resources from the United States federal government.
  • Section508.gov portal, the “GSA Government-wide Accessibility Program,” is a rich resource for all things Section 508, including information about how to buy accessible products and test for accessibility, how to manage an accessibility program, and how to evaluate accessibility claims. It also offers an accessibility training program geared to implementation of Section 508. Section508.gov portal.
  • Accessibility Requirements Tool from the General Services Administration of the United States government is designed to help implement Section 508 and includes sample contract language for Section 508 compliance. This tool is tightly geared to technical requirements of Section 508 implementation: The Accessibility Requirements Tool (ART).
  • Text of the Section 508 Standards and guidelines may offer helpful language as your organization develops its accessible procurement program for workplace tools. The full guidelines are available here.

Back to Toolkit Sections

15 Help Suppliers Understand Accessibility

Suppliers must understand accessibility as more than a checklist. Here are some ideas to help your organization help its vendors.

• Share accessibility learnings. Microsoft does this in the Microsoft Supplier Toolkit Resources on Accessibility.
• Plan events so suppliers can meet members of your Employee Resource Group who have disabilities. One of the most powerful ways to educate vendors about the value of accessibility to your organization is for vendor teams to meet the people in your organization who will most benefit from accessible procurement.
• Include suppliers in programs designed to build accessibility culture. Think about inviting supplier representatives to attend accessibility events or include vendors in Global Accessibility Awareness Day activities.

Back to Toolkit Sections

16 Evaluate Bids for Accessibility

After defining requirements and gathering detailed information about accessibility it is time to evaluate proposals. Here are some best practices for incorporating accessibility into the product selection process once the bids are in:

• Establish a team responsible for the accessibility portion of product evaluation. This might involve bringing in an in-house Subject Matter Expert (SME) who can both assist and identify any outside needed resources. If the product owner or in-house procurement specialists do not have the expertise to evaluate whether proposals will deliver an accessible product, identify internal or external resources that the procurement team can reach out to. Determine when it is appropriate to hire outside accessibility expertise.
• Conduct an accessibility demonstration. This may have been done while gathering information, but an additional demonstration may be needed if enhancements were promised at the time of market research. Key to the success of an accessibility demonstration at any stage is having participation of people with disabilities, from your own workforce or outside organizations. Involve your employee resource group, hire a consultant or non-profit organization that offers accessibility evaluation with disabled people, or connect with local disability rights organizations.
• Arrange for an in-house evaluation of accessibility claims in the final bids, which may require access to a secure test environment.
• If your organization does not yet have the employee resources to conduct an evaluation in-house, determine whether an independent audit of accessibility claims is appropriate, who will conduct it, from whose budged will the cost be taken.
• Determine how your organization will handle technologies that are not fully accessible.
  • Will you disqualify vendors who don’t respond with detailed information requested?
  • Does your organization have evaluation factors? If so, determine where accessibility is ranked among your evaluation factors. Can it be given a higher ranking in light of the legal and reputational risk factors and the importance of accessibility to your organization’s diversity and inclusion initiatives? The Tools for Internal Advocacy section of this Accessible Technology Procurement Toolkit can help demonstrate the need for ranking accessibility high in evaluation factors.
  • Establish a risk matrix that ranks accessibility seriously. (The categorization and prioritization factors used in the tool inventory may be useful.)
  • Is there someone in the organization empowered to stop the procurement if it’s particularly high-risk and accessibility has not been adequately considered?
  • If there is only one vendor in a space for a needed product and accessibility has not been adequately addressed, work with the vendor to develop a roadmap to accessibility that has timeframes and deliverables along the way. This roadmap should later be built into the product contract. See also the Accessible Technology Procurement Toolkit section titled, “Follow-up When Tech is Not Fully Accessible.”

Back to Toolkit Sections

Build Accessibility Obligations into Purchase Documents

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.

Back to Toolkit Sections

17 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 per below, 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.

Back to Toolkit Sections

Focus on Accessibility Post-Purchase

Once the contract is signed, the work of ensuring the accessibility of workplace tools is not over. Attention to accessibility must remain strong. This part of the Accessible Technology Procurement Toolkit offers best practices for accessibility focus at the time of delivery and during the term of the contract.

Back to Toolkit Sections

18 Time of Delivery: Testing and Documenting Accessibility and Gaps

If the contract specified vendor accessibility testing at time of delivery, those details should be verified with someone carefully evaluating test results. The technology should also be evaluated for accessibility by your organization. Consider in advance and build into policies and systems:

• Who in your organization will do the initial sign-off of the product for accessibility.
• What types of accessibility testing will be conducted: automated, manual, code inspection, AT compatibility, usability testing, and what tools will be used to conduct the testing.

Consider preparing a checklist and developing procedures with time frames to be sure that all needed information is captured.

As a result of the testing, you will be able to document both accessibility and known barriers. When documentation is complete, it is time to consider:

• What approvals are needed to sign off on the product with known accessibility barriers?
• What commitment is there to remedy barriers in future? This is a time to look carefully at the contract. If time-of-delivery testing has revealed barriers not addressed, the contract ideally will have a process for establishing a timeline for remediation. If not, a timeline and roadmap must be established.
• Who will be responsible to follow-up to remediate barriers revealed at time of delivery?

Back to Toolkit Sections

19 During the Contract: Bug Reports, Documenting Barriers, and Staying on the Roadmap

Don’t let all your accessible procurement efforts dissipate by ignoring accessibility once the product is yours. Here are best practices to keep accessibility on track after delivery:

• Solicit and respond to employee feedback about accessibility and bug reports. Share all feedback with vendor, get commitment (supported by contact) to remedy within a specific time frame.
• Involve ERG members to provide and document user experience.
• Establish regular testing protocols and meeting to review accessibility status.
• Confirm that accessibility is maintained after each update / new version by establishing testing protocols. Review accessibility information in updates and releases and verify for accuracy.
• Establish metrics for evaluating accessibility, measuring and reporting progress.
• Monitor and enforce any commitments made by suppliers during contract negotiation to follow a roadmap toward greater accessibility.
• Plan for needed accessibility language at contract and license renewal.

Back to Toolkit Sections

Train and Educate for Accessible Procurement

Training is as important to accessible workplace tool procurement as having strong language in the contract and well thought out testing protocols involving disability talent. Here are best practices to ensure that the accessible procurement practices your organization develops are communicated to all your teams who need to know.

• Everything done to build and strengthen a culture of accessibility should be considered part of training and educating for accessible procurement. See the “Give Employees Learnings They Need” section.
• Understand business process/flow to determine when and where training needed.
• Remember that training involves not just knowing what is supposed to happen but understanding how to handle situations that are not supposed to happen.
• Procurement/purchaser teams need training in both accessibility and in the policies and systems put into place to ensure accessible procurement.
• Involve Disability ERGs in planning and conducting training about the importance of accessibility and how disabled people interact with technology.
• Train all staff about how to activate accessibility features and functionality. For authoring tools and other software that produces content, train all staff in ensuring accessible output of existing technology.
• Inject accessibility into ongoing training programs. Merck, for example, offered a session on accessibility features in Microsoft Solutions in its “TechWalk” initiative, letting teams know that:
  

  “This session will provide a demonstration of accessibility features for Microsoft Solutions. We will discuss accessibility features for both content creators and end users who have a need for accessible technology “

• Take steps to ensure that all training is accessible. This does more than create an inclusive training environment for employees with disabilities. It serves as a tool to educate both in-house and external trainers that accessible software and content matters. And it bakes accessibility into procurement processes used to purchase training platforms and courses.

  Here are some best practices for a training program that supports disability talent:

  • Use the guidance in this Accessible Technology Procurement Toolkit to ensure as part of the procurement process that any platforms (e.g. Learning Management System, Learning Content Management System, Knowledge Management System) are accessible.
  • Ensure that any online courses being designed are done so in a way that is accessible, and have them tested before launch.
  • Have systems in place so that any print materials used for Instructor-Led Training (participant guides, job aids, etc.) have accessible versions.
  • Establish “train the trainer” sessions so that everyone providing education to your employees or applicants, either online or in person, are aware of disability etiquette and accessible presentation best practices. (For example, captioning all video content, describing visual images, establishing flexible and accessible hands-on exercises,) techniques (e.g. not referring to visual cues, showing Closed Captioning for any video clips, etc.) Require that all trainers use and verify built-in accessibility features of presentation software.

When evaluating your organization’s accessibility training needs, determine whether outside resources are needed. If they are, “vet before you get” and interview two or three potential training vendors. This will ensure that you find the best fit for your organizational culture and your budget. If outside trainers are needed, be sure to build-in contract requirements that the training itself be accessible, as per the suggestions above. Hiring people with disabilities to conduct training and education will enhance your overall accessible workplace tools procurement efforts.

Back to Toolkit Sections

Tools for Internal Advocacy

Corporate accessibility champions often have to convince their colleagues, team members, or executive leadership of the importance of digital accessibility to a diverse workforce. Other champions may have to advocate for including people with disabilities in an organization’s diversity commitment.

Here are some resources to assist in the advocacy that is necessary for a robust accessible technology procurement program.

• Business Case for Disability Inclusion: Getting To Equal: The Disability Inclusion Advantage a joint report from Accenture, Disability:IN and the American Association of People with Disabilities – Business Case for Disability Inclusion [PDF].
• Business Case for Disability Inclusion: Hiring People with Disabilities is Good Business (New York Times Op Ed) – New York Times: “Hiring People With Disabilities Is Good Business”.
• Business Case for Accessible Design: The Benefit of Designing for Everyone (Report from the Centre for Inclusive Design Australia) – “The Benefit of Designing for Everyone” [PDF].
  Article about the report, launched in partnership with Adobe and Microsoft, titled World-first report: Research reveals inclusive design can expand customer reach fourfold.
• Business Case for Digital Accessibility: 2018 content from the Web Accessibility Initiative of the W3C.
• Business Case for Digital Accessibility: Accessibility: Making the Business Case for Employers (Resource from PEAT / Partnership on Employment and Accessible Technology
• Strategies for Encouraging Teams: Gaining Buy-In for Accessibility in Your Company, 2017 article by member of Amazon UX team.
• Value of Involving Employees with Disabilities Early in the Process: Involving Users in Web Projects for Better, Easier Accessibility (Resource from the Web Accessibility
  Initiative of the W3C).

Back to Toolkit Sections

Sample Procurement Documents from Disability:IN Partners

20 Accessibility Language in Supplier Codes of Conduct

• Accenture Supplier Standards of Conduct:
  “Client Value Creation: Ensure accessibility to Persons with Disabilities: Accenture suppliers must ensure that accessibility needs are included as part of their own procurement processes. 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.”
  Full Accenture Supplier Standards of Conduct available here.
• IBM Accessibility Guidelines for Suppliers
  “Suppliers and vendors that sell or license software, hardware, Web, Learning, and information technology (IT) products and services (i.e., deliverables) to IBM must provide documentation that the deliverables are accessible. Accessible means that the information technology and any accompanying information conforms to required accessibility laws, regulations, standards and technical guidelines so that deliverables can be used successfully by people who have disabilities.”
  Full IBM Accessibility guidelines for suppliers available here.
• JP Morgan Chase & Co. Supplier Standards 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.”
  Full JP Morgan Chase & Co. Suppliers Standard of Conduct available here.
• Microsoft Supplier Code of Conduct Accessibility: Creating products, apps, 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. Each Microsoft Supplier must comply with:
  • The current version of the international accessibility standard Web Content Accessibility Guidelines (WCAG) Level AA when creating any deliverable;
    and
  • All applicable Microsoft requirements and standards for creating accessible products, apps, and services.

Full Microsoft Supplier Code of Conduct available here.

Back to Toolkit Sections

21 Accessibility Language in Master Services Agreements

(g) Supplier to comply with Microsoft Policies. Supplier will comply with the following as applicable to the Services provided.

(5) Any device, product, website, web-based application, cloud service, software, or content developed for or provided by or on behalf of Supplier or Supplier’s Affiliate under this Agreement must comply with all legal and Microsoft-provided accessibility requirements, including Level A and AA Success Criteria of the latest published version of the Web Content Accessibility Guidelines (“WCAG”) . An overview of WCAG is available here and WCAG Version 2.0 is codified as ISO/IEC 40500:2012.

Download the Microsoft Master Services Agreement here.

Back to Toolkit Sections

22 Other Documents Incorporating WCAG into the Procurement Process

The JPMorgan Chase Third Party Provider (TPP) WCAG Standard impacts vendor relations when a third-party provider “interacts via digital and/or electronic content offered via applicable JPMC online and mobile properties, or as otherwise indicated by the TPP Agreement and/or JPMC Relationship Manager (or Delivery Manager as the case may be) as being applicable.”

The document includes items such as “types of criteria and associated evidence that JPMC uses to assess WCAG compliance,” and the vendors obligation when it “experiences a defect with WCAG testing.

Full JPMC TPP WCAG Standard [PDF].

Back to Toolkit Sections

23 Accessibility Resources to Share with Vendors

Microsoft offers a Supplier Toolkit Accessibility Resources to share what the company has learned about accessibility with its suppliers. The introduction states “Whether you are just starting out and need basic disability etiquette or want to test code to the latest standards, check out these helpful resources.”

Full Microsoft Supplier Toolkit Accessibility Resources.

Back to Toolkit Sections

24 Questions to Ask Vendors During Procurement Process

Accenture Product Questionnaire

	Question	Answer	Comment
	ICT accessibility policy and governance
1.1	Does your organization have an ICT accessibility policy? If yes, please provide document and/or link to published policy
1.1	Does your organization have an accessibility officer / someone within your organization with responsibilities around ICT accessibility? If yes, please provide name and contact details
1.3	Has your organization implemented a reporting/decision mechanism to track and solve accessibility issues? If yes, please provide details
	Compliancy
2.1	Is your product WCAG 2.1AA compliant?
2.2	If your product is not WCAG 2.1AA compliant, are there plans to make it compliant? If yes, please provide timeline for compliancy.
	Documentation and Reporting
3.1	Has your organization created documentation to verify accessibility for your products/services, Voluntary Product Accessibility Templates (VPAT)? If yes, please provide link to website where documentation is published.
3.2	If no, is your organization planning to create and publish documentation for your products/services? If yes, please provide timeline.
3.3	Do you have testing protocols to assess accessibility of products and services delivered to Accenture?
3.4	Do your protocols include testing by Persons with Disabilities?
3.5	How frequently do you perform upgrades on products/services?
3.6	Do you integrate findings from previous accessibility tests?

Back to Toolkit Sections

25 Ideas for Internal Education about Accessibility

• Merck flyer announcing Tech Talk on Digital Accessibility [PDF].

Back to Toolkit Sections

26 Vendor Accessibility Letter

Charter Communications Letter to Vendor

Dear Valued Partner,

Nearly 13 percent of Americans reported living with a disability in 2017, which means it’s likely that a substantial number of [COMPANY NAME’s] [# OF CUSTOMERS] business and residential customers likely have a physical, sensory or cognitive disability. Furthermore, while accessibility solutions may be critical for those with disabilities, they can be useful for those without disabilities as well.
Universal Design recognizes that, where possible, the removal of dependencies limited to any given sensory input or physical ability results in a better product. It produces an outcome that not only opens access to a wider audience, but also offers the typical audience a more diverse way to engage with products and environments. Achieving such outcome of greater access for customers experiencing a circumstantial disability, such as being in a dim room or having their hands full, leads to a more appealing design overall.

To better serve the needs of customers and employees with disabilities, COMPANY NAME formed an accessibility team responsible for the planning, strategy for, consultation on, and execution of their accessibility efforts, including Universal Design for its products and services as well as ensuring compliance with legal and governmental policies related to telecommunications and web accessibility for consumers.

There are multiple compliance obligations applicable to COMPANY NAME’s products and services under the Communications Act (CA), including the Twenty-First Century Communications Act and Video Accessibility Act (CVAA) and Federal Communications Commission (FCC) accessibility regulations, as well as state and local accessibility laws. COMPANY NAME’s expectation is that the web applications and software of COMPANY NAME and its partners meet or exceed the applicable guidelines and requirements set forth in the Web Content Accessibility Guidelines (WCAG) 2.0.

By creating accessible products, we transform the experience of our customers with our products and services, making available greater interactivity for all. While we have a team of Accessibility architects to work with developers and user experience designers and our products undergo extensive testing designed to create universal and accessible experiences, we also rely on the collaboration of our valued partners like you to achieve our accessibility goals.

Sincerely,
COMPANY NAME Officer

Download this letter from Charter Communications highlighting importance of accessibility as a DOCX.

Back to Toolkit Sections

27 Best Practices for Product Development Testing

From Charter Communications

To create a born accessible product, it is recommended that accessibility requirements be integrated at the beginning of product development.

A product is created in 4 stages

1. Design
2. Development
3. Staging (Strictly QA)
4. Production

Testing occurs in Development and influences Staging.  In Production, testing takes the form of a health check to insure nothing has been missed or things have not been broken over time.

Step 1:  Build a Tester team that represents each Disability and is preferably embedded in Design Team

1. Motor
2. Blind
3. Low Vision
4. Color Blindness/Sensitivity
5. Deaf
6. Neurodiverse
7. Comorbid Disabilities/Multiple Disabilities

A Tester should…

• Be a native user
• Have credentials into the product and tools necessary to test, as well as dummy/test data if necessary (e.g, billing address and credit card numbers)

Step 2:  Create a Lab (optional) and set up stations per user type

Each station should identify the differing Assistive Technology that users interact with for that Product.  (Note:  Several disability types overlap on the same Assistive Technology)

Step 3:  Create a unified Test plan and a Reporting plan

Step 4:  Test Plan intake (Development)

• Fill out a Testing Brief that defines scope of what the product/application should do
  • Summary of what to solve for
  • Requirements established
  • Should the testing be (a) per screen or (b) per user journey
    • Identify which screens or user journeys
• Standardize how a product is tested
  • Create a check list of standards to qualify a product or service
  • Define methodology
  • What machines where used for testing (i.e. iPhone / Andriod / Mac / PC)
    • Which platforms to test: desktop/laptop, RWD (web on mobile), native, 10-foot TV app
    • Which screen readers or browsers
    • Any “special” test cases like Dragon, switch
  • Identify obstacles
  • Propose solutions

Step 5:  Test Standards (Development)

Apply WCAG (Web Content Accessibility Guidelines) minimum standard AA

Step 6:  Quality Assurance (Staging)

Findings sent to QA Test Lead for review and quality check

Step 7:  Release Findings (If findings conflict with current Product state and key requirements, send Product back to Development then Staging then Production)

Approval of testing standard complete and released for application

Download this resource on product design testing best practices as a DOCX.

Back to Toolkit Sections

Other Accessible Procurement Resources

Disability:IN is grateful for the resources provided by other organizations on the issue of accessible procurement. The following may be useful to your organization:

• “Buy IT!—Your Guide for Purchasing Accessible Technology,” an online portal from PEAT, the Partnership on Employment and Accessible Technology.
• “Buy ICT 4 All,” a resource for accessible procurement in the public sector globally from G3ICT, the Global Initiative for Inclusive ICT.
• “Technology Vendor Contracts and Accessibility: What Every Business Lawyer Should Know,” article in Business Law Today, a publication of the American Bar Association.
• Accessible Technology Today, It Starts with Procurement, article on the PEAT website.
• United States federal government procurement resources: Visit Section 14.3 (VPAT Resources) of this Accessible Technology Procurement Toolkit.
• Education Sector Accessible Procurement Resources
  • Ohio State Digital Accessiblity Center: Purchasing Questions and Contract Language.
  • University of California Office of the President, Standards and Best Practices for Procurement of Accessible Electronic Products.
  • National Center on Disability and Access to Education, Let the Buyer be Aware: The Importance of Procurement in Accessibility Policy.
  • Texas Department of Information Resources, Accessibility Procurement and Resources.