Assume that a vendor’s proposal is accepted for review and competition and they are asked to provide a demonstration. It is at this point when you can move into more particular, perhaps technical, questions about specific accessibility features of their product. It is often easy to get a sense of a vendor’s knowledge and commitment to accessibility by simply looking through their website.• Sample a few pages and run them through an automated accessibility checker and HTML validator. How well do they do? The results will be a good indication of the quality and accessibility of work the company does. • Does the vendor’s website have a prominent accessibility statement? Though not a requirement, if they do have one, it’s a good indication the company cares about accessibility.• Does that statement, if there is one, have a compliance claim and are accessibility features on the site listed? If the accessibility features are listed, it likely means they are thinking about people with disabilities who are visiting their site, which is one step above thinking about accessibility in general. • If there is a demo of the software you intend to procure, sample a few screens for checker and validator testing. How well do they do? You may be able to decide in this manner whether the software you are intending to procure from this company has the potential or not to meet the accessibility requirements of your organization. • If an RFP is being issued, you may want to mention to vendors that their website may be reviewed for accessibility. Or, you may want to review websites prior to an RFP, to aid with shortlisting vendors to approach. 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. See the document: 'Accessibility Questions for Product Demonstrations', in the Course Resources, for a collection of questions that can be asked while interviewing vendors. Here is a 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.