Vendor Accessibility FAQ

The University of Arizona requires all ICT products and services to conform toWCAG 2.2 Level AA. This aligns with:

• ADA Title II requirements for state/local government
• Section 508 of the Rehabilitation Act
• Arizona state IT accessibility policy

Yes, accessibility requirements apply to all ICT procurements, including:

• Web applications and SaaS platforms
• Desktop and mobile applications
• Learning management systems and courseware
• Document management systems
• Communication and collaboration tools
• Hardware with embedded software
• Custom development projects

Few products are 100% accessible. We evaluate products based on:

• Current state:How many WCAG criteria are supported?
• Impact:Do issues block essential functionality?
• Workarounds:Are there accessible alternatives?
• Roadmap:What's your plan to remediate issues?
• Commitment:Is accessibility part of your development process?

We work with vendors on remediation plans when products don't fully meet requirements but show commitment to accessibility.

Limited exceptions may be granted when:

• No accessible alternative exists in the market
• The product serves a very limited audience
• Accessibility modifications would fundamentally alter the product
• A compliant version is in active development with timeline

All exceptions require documentation and an Equally Effective Alternate Access Plan (EEAAP).

AVPAT(Voluntary Product Accessibility Template) is a standardized document that reports how your product conforms to accessibility standards. When completed, it becomes anACR(Accessibility Conformance Report).

We require VPATs to:

• Evaluate accessibility before purchase
• Compare products objectively
• Identify needed accommodations
• Track vendor commitment to accessibility

Please useVPAT 2.5(or 2.4 minimum), which covers:

• WCAG 2.2 (or 2.1) success criteria
• Revised Section 508 standards
• EN 301 549 (European standard)

Older VPAT versions (2.0–2.3) reference outdated standards and should be updated.

Download VPAT templates from ITI

A quality VPAT includes:

• Specific explanationsfor all "Partially Supports" and "Does Not Support" ratings
• Workaroundsfor known issues
• Remediation timelinesfor planned fixes
• Testing methodologydescription
• Product version and dateclearly stated

Avoid vague statements like "some issues may exist." Be specific about what works and what doesn't.

VPATs can be completed by:

• Internal accessibility teams- If you have trained accessibility specialists
• Third-party auditors- Provides independent validation (preferred for high-stakes purchases)
• Combined approach- Internal testing validated by external review

We give more weight to third-party validated VPATs and those with detailed testing methodology.

Update your VPAT:

• With eachmajor product release
• Whenaccessibility improvementsare released
• At leastannually, even without major changes
• WhenWCAG or Section 508 standardsare updated

VPATs older than 18 months are considered outdated.

Comprehensive accessibility testing includes:

1. Automated testing:Tools like axe, WAVE, or Lighthouse
2. Manual testing:Keyboard navigation, screen reader testing
3. User testing:Testing with people with disabilities

Automated tools catch 30-40% of issues. Manual testing is essential for complete coverage.

At minimum, test with:

• NVDA + Chrome/Firefox(Windows) - Free
• VoiceOver + Safari(macOS/iOS) - Built-in
• JAWS + Chrome(Windows) - If enterprise users are a primary audience

For mobile apps, also test with TalkBack (Android).

WCAG 2.2 Level AA includes 57 success criteria organized under four principles:

• Perceivable:Alt text, captions, color contrast, text resize
• Operable:Keyboard access, timing, navigation, input modalities
• Understandable:Readable text, predictable behavior, error handling
• Robust:Compatible with assistive technologies

WCAG Quick Reference

Yes. UA contracts typically include accessibility language requiring:

• Conformance to WCAG 2.2 Level AA
• Remediation of reported issues within specified timeframes
• Updated VPATs with major releases
• Notification of accessibility regressions
• Right to audit or request third-party testing

Accessibility typically accounts for10-20%of RFP scoring, depending on the product. Evaluation considers:

• VPAT quality and completeness
• Current conformance level
• Remediation roadmap
• Vendor accessibility commitment and resources
• Third-party validation

We understand resource constraints. We recommend:

• Use free tools like WAVE and axe to start testing
• Follow accessibility basics (semantic HTML, keyboard access, color contrast)
• Be honest about current limitations in your VPAT
• Provide a realistic remediation timeline
• Consider partnering with an accessibility consultant for initial audit

Commitment to improvement matters as much as current state.

Our contracts specify remediation requirements:

• Critical issues(blocking access): 30-day remediation
• Major issues(significant barriers): 90-day remediation
• Minor issues(limited impact): Next major release

We work collaboratively with vendors on reasonable timelines when issues are complex.

Best practices for accessibility support:

• Train support staff on accessibility basics
• Provide a dedicated accessibility contact or channel
• Respond to accessibility issues within 48 hours
• Track accessibility issues separately in your bug system
• Communicate fixes and workarounds to reporting parties

Contact the Digital Accessibility Office:

• Email:accessibility@arizona.edu
• VPAT reviews:Submit with procurement requests
• Technical questions:Available during procurement process

For procurement-specific questions, contact your UA procurement representative.