5. Procurement and Accessibility Policy
Accessibility Questions During Product Demonstrations
During a product demonstration, specific and technical questions should be asked. It is a good idea to have the responses from the RFP accessibility requirements in hand so they can be clarified.
In addition to clarifications in the proposal’s accessibility responses, here are some additional questions that can be asked to assess a vendor’s level of accessibility understanding and their willingness to address accessibility issues in their software to meet your organization’s requirements.
Here is the list of 10 possible questions and expected answers:
1. Which accessibility standards does your product comply with? At which Level (if WCAG)?
Depending on the jurisdiction of the vendor, a local accessibility standard should be mentioned (e.g., Section 508 in the U.S.; AODA in Ontario), or mention WCAG. Added points if the vendor is from a different jurisdiction, and mentions the requirements of your jurisdiction, if different from their own.
At a minimum, where WCAG is the vendor’s guideline of choice, Level A should be mentioned, or talk about what remains to be addressed to meet Level A. If Level AA is mentioned, added points could be given. If Level AAA is mentioned, that is a warning sign, since very few if any complex systems will meet Level AAA requirements. Ask what AAA features have been implemented in the system.
2. Is your product accessible without a mouse? Please demonstrate.
The answer should always be “Yes.” The vendor should be able to demonstrate by using the Tab key to navigate through the user interface (UI). All functional elements, like menus, links, buttons, and forms, etc., should all be able to receive focus, and users should be able to navigate through menus and open elements using only the keyboard. Watch out for elements that can receive focus, but do not operate with a keypress.
3. Has your product been tested with assistive technologies? If so, with which ones?
Should answer “Yes.”
Should mention a screen reader at a minimum. Should be able to identify which screen readers, such as ChromeVox, JAWS, NDVA, etc. Added points if they also mention Voiceover and/or Talkback for mobile devices.
4. Who did the testing?
The developers of the software should be mentioned. Screen reader testing should be part of the development process. Or, a particular accessibility person within the organization may be the tester. Added points if people with disabilities were used in testing, or a third party accessibility expert. Is the third party tester reputable, if one was used?
5. What was the testing methodology? What were the results?
Should mention a combination of automated and manual testing strategies, and screen reader testing. Added points if testing with people with disabilities is also part of their testing process.
Ideally mention the level of conformance reached, as well as acknowledging any issues that may remain, and what they plan to do to address those issues. Answering “fully accessible” is a warning sign. Very few systems will be fully accessible to everyone.
6. How is accessibility built into your company’s quality assurance (QA) process?
Should talk about the development process at a minimum, and where accessibility design and testing tasks fit into the process. Added points if the vendor goes into detail about the Web accessibility policy implemented at the company.
7. If you roll out upgrades after we purchase the product, how can you assure us the upgrades will not break accessibility?
Should refer back to the QA process, local upgrade testing before pushing updates to production environments. Added points if third-party accessibility expert is involved.
8. Does your product make use of WAI-ARIA? If it does, how so?
Where a product has a fairly complex, interactive UI, the answer should be “Yes.” This indicates the vendor understands the complex accessibility issues associated with custom-built web interactivity.
May mention using ARIA landmarks. Added points if the specific ARIA attributes are mentioned for particular types of interactions, for example, using menu-related ARIA for complex menu, tab panel–related ARIA for tab panel presentations, and so on. Perhaps mention libraries used to implement ARIA, like jQuery or MooTools, or perhaps a custom-made ARIA library created by the vendor.
9. Does your product adapt responsively to different screen sizes? Please demonstrate.
Should answer “Yes.” Should be able to grab the corner of a browser window and drag it inward to reduce the window size, and the content should adapt cleanly as the window size increases and decreases. Should also be able to demonstrate the product on a mobile device like a smartphone or tablet, and have the UI adapt to the device’s screen size.
10. Does your product magnify cleanly using just a browser’s zoom feature? Please demonstrate.
Should answer “Yes.” Should be able to use the browser’s zoom function to increase the size of the content to at least 200% without the content flowing off the side of the screen or overlapping with adjacent content. Added points for zoom sizes greater than 200%. Good zoom adaptation indicates relative measures (em, %) have been used to size elements rather than absolute measures (px, pt), which is also a requirement for good responsive designs.
