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.”
Questions to Ask Vendors During Procurement Process
In July 2022 Disability:IN’s Procure Access initiative published the Accessible Procurement Questions, a question set designed for purchasers and sellers in the private sector to obtain and share critical information about technology product and service accessibility. Visit the Accessible Procurement Questions web page, with a downloadable version of the resource.
Accenture Product Questionnaire
|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|
|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?|
Supplier RFP Accessibility Questionnaire (as provided by a Disability:IN Corporate Partner)
- Will your Product or Service include a user interface that is accessible by people with disabilities?
- Do your products or will your products substantially meet the WCAG 2.1 AA Accessibility Requirements?
- Are you willing to enter into a contractual agreement that holds your company responsible for delivering products that comply with Accessibility Requirements?
- Has your product been tested, or will it be tested by a third-party accessibility expert or by people with disabilities?
- Do you test with assistive technologies such as JAWS, NVDA, VoiceOver, Talkback, ZoomText, Dragon Naturally Speaking?
- If you provide product support, will you provide it in multiple formats such as large print, Braille, audio or customer support options such as chat, real time text (“RTT”) for people with disabilities upon request?
- Does your product rely on an alternative interface or plug-in for people with disabilities?
- Do you have an accessibility program (funding, staffing, resources) specifically allocated to building accessible products?
- Do you have an established process for including accessibility in the development lifecycle and during future releases of the product?
- Do you have a Voluntary Product Accessibility Template (“VPAT”) or comparable Third Party Accessibility Review? If so, please provide.
Ideas for Internal Education about Accessibility
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.
COMPANY NAME Officer
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
- Staging (Strictly QA)
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
- Low Vision
- Color Blindness/Sensitivity
- 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