Sample Procurement Documents from Disability:IN Partners Part Two: Training and Vendor Information

Summary

On this page: Find documents from Disability:IN’s global corporate partners about training and communication with vendors

Accessibility Resources to Share with Vendors Get link to section 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(External link).

Questions to Ask Vendors During Procurement Process Get link to section Questions to Ask Vendors During Procurement Process

Accenture Product Questionnaire Get link to section 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?(External link)
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?

Ideas for Internal Education about Accessibility Get link to section Ideas for Internal Education about Accessibility

Vendor Accessibility Letter Get link to section Vendor Accessibility Letter

Charter Communications Letter to Vendor Get link to section 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(External link).

Best Practices for Product Development Testing Get link to section Best Practices for Product Development Testing

From Charter Communications Get link to section 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 Get link to section 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 Get link to section 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 Get link to section Step 3:  Create a unified Test plan and a Reporting plan

Step 4:  Test Plan intake (Development) Get link to section 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) Get link to section Step 5:  Test Standards (Development)

Apply WCAG (Web Content Accessibility Guidelines) minimum standard AA

Step 6:  Quality Assurance (Staging) Get link to section 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) Get link to section 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(External link).

Back to top