Using this guide
When evaluating technology vendors, asking the right questions helps you understand their commitment to accessibility. Use these questions during demos, RFP responses, and contract negotiations.
Key areas to evaluate
- Documentation and testing
- Organizational commitment
- User experience and support
- Roadmap and remediation
- Contractual commitments
Documentation & testing questions
Q: Do you have a current VPAT/ACR?
What to look for:
- VPAT based on WCAG 2.1 AA (not just WCAG 2.0)
- Dated within last 18 months
- Covers the specific product/version you're evaluating
- Detailed remarks, not just "Supports" without explanation
Red flag: "We're working on it" without timeline, or VPAT more than 2 years old.
Q: How do you test for accessibility?
Good answers include:
- Automated testing integrated into development
- Manual testing with screen readers (NVDA, JAWS, VoiceOver)
- Testing with keyboard-only navigation
- Third-party audits periodically
- Testing with users who have disabilities
Red flag: "We use [automated tool only]" — automated testing catches only 30-40% of issues.
Q: What accessibility standards do you follow?
Good answers:
- "WCAG 2.1 Level AA" — current standard
- "Section 508" — acceptable for US federal compliance
- "EN 301 549" — European standard, comprehensive
Red flag: "We follow ADA" — ADA doesn't specify technical standards for web.
Organizational commitment questions
Q: Do you have dedicated accessibility staff?
Good answers:
- Dedicated accessibility team or specialist
- Accessibility responsibilities embedded in development roles
- Executive sponsor for accessibility
- Accessibility training for all developers
Red flag: "It's everyone's responsibility" with no specific ownership.
Q: What is your company's accessibility policy?
What to look for:
- Published accessibility statement on website
- Clear commitment to WCAG compliance
- Process for receiving and addressing feedback
- Regular review and update cycle
Q: How do you handle accessibility in your development process?
Good answers:
- Accessibility requirements in user stories
- Accessibility testing in QA process
- Accessibility review before release
- Accessibility bugs prioritized appropriately
User experience questions
Q: Can users complete all tasks using only a keyboard?
What to verify:
- All interactive elements are focusable
- Focus order is logical
- Focus indicator is visible
- No keyboard traps
- Complex widgets have appropriate keyboard patterns
Request: Demo the product using only keyboard during evaluation.
Q: What screen readers do you test with?
Good answers:
- NVDA (Windows, free)
- JAWS (Windows, industry standard)
- VoiceOver (macOS/iOS)
- TalkBack (Android)
Better answer: "We test with multiple screen readers across browsers."
Q: Do you have users with disabilities test your product?
Good answers:
- Beta testing program includes users with disabilities
- Usability studies with assistive technology users
- Accessibility advisory board
- Employees with disabilities on product team
Support & remediation questions
Q: How do you handle accessibility bug reports?
Good answers:
- Dedicated channel or tag for accessibility issues
- Clear SLAs for accessibility bug resolution
- Accessibility bugs not deprioritized vs. other bugs
- Process for interim workarounds
Q: What is your timeline for fixing accessibility issues?
Reasonable expectations:
| Severity | Expected resolution |
|---|---|
| Blocker (can't use feature) | Days to 2 weeks + workaround |
| Major (difficult to use) | Next release or 30-60 days |
| Minor (inconvenience) | Within 2-3 releases |
Q: What's on your accessibility roadmap?
Good answers:
- Specific plans to address known issues
- Timeline for WCAG 2.1 or 2.2 compliance
- Plans for improving specific features
- Regular accessibility audit schedule
Red flag: No roadmap or "accessibility is complete."
Contract & commitment questions
Q: Will you include accessibility requirements in the contract?
Request inclusion of:
- WCAG 2.1 AA conformance requirement
- Requirement to provide current VPAT
- Timeline for addressing accessibility issues
- Right to audit or request third-party audit
- Indemnification for accessibility claims
Q: What happens if we find accessibility issues after purchase?
Good answers:
- Commitment to fix within agreed timeline
- Provide workarounds while fixing
- Regular progress updates
- Credit or remediation if issues not fixed
Q: Will you notify us of accessibility changes?
Request:
- Updated VPAT with major releases
- Notification of accessibility regressions
- Release notes include accessibility changes
During the demo
When vendors demo their product, ask them to:
- Navigate using only keyboard for 5 minutes
- Show focus indicators on all interactive elements
- Read a form using a screen reader
- Show how images are described
- Demonstrate how error messages are communicated
- Show accessibility settings or features
- Complete a core task (like creating content) with keyboard only
Scoring vendor responses
| Score | Criteria |
|---|---|
| Excellent (4) | Current VPAT, dedicated resources, proven commitment, contractual guarantees |
| Good (3) | Recent VPAT, accessibility in process, responsive to issues, roadmap exists |
| Fair (2) | VPAT available but dated, some accessibility awareness, willing to improve |
| Poor (1) | No VPAT, vague commitment, no dedicated resources, poor issue response |
| Unacceptable (0) | No documentation, dismissive of accessibility, unwilling to commit |
Sample RFP language
Include in RFP requirements:
"The vendor shall provide an Accessibility Conformance Report (VPAT) based on WCAG 2.1 Level AA for the proposed product. The product must conform to WCAG 2.1 Level AA standards. The vendor shall describe their accessibility testing methodology, accessibility support resources, and process for addressing accessibility issues reported by the University."