Skip to main content

Welcome to our new website! The content and organization have been heavily redone and we want to hear from you! 
Submit feedback

Vendor Accessibility FAQ

Questions to ask vendors about their accessibility practices.

❓ Procurement guidance

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

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.

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.

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

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.

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

Good answers:

  • Accessibility requirements in user stories
  • Accessibility testing in QA process
  • Accessibility review before release
  • Accessibility bugs prioritized appropriately

User experience questions

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.

Good answers:

  • NVDA (Windows, free)
  • JAWS (Windows, industry standard)
  • VoiceOver (macOS/iOS)
  • TalkBack (Android)

Better answer: "We test with multiple screen readers across browsers."

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

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

Reasonable expectations:

SeverityExpected 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

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

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

Good answers:

  • Commitment to fix within agreed timeline
  • Provide workarounds while fixing
  • Regular progress updates
  • Credit or remediation if issues not fixed

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

ScoreCriteria
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."

Resources