Response times and resolution targets for accessibility issues.
⏱️ SLA definitions
Overview
These Service Level Agreements (SLAs) define expected response and resolution times for accessibility issues reported to UA. They ensure consistent handling of accessibility barriers across the university.
Scope
These SLAs apply to:
- University-owned websites and applications
- University-managed content
- Third-party services procured by UA
- Course materials in the LMS
Severity levels
| Severity | Definition | Examples |
|---|---|---|
| Critical (P1) | Complete barrier preventing task completion with no workaround |
|
| High (P2) | Significant barrier to core functionality; workaround possible but difficult |
|
| Medium (P3) | Barrier to functionality with reasonable workaround available |
|
| Low (P4) | Minor issue that doesn't significantly impact functionality |
|
Response time targets
Response time = Time from issue report to first meaningful response to reporter.
| Severity | Response time | Business hours |
|---|---|---|
| Critical (P1) | 4 hours | 8 AM - 5 PM weekdays |
| High (P2) | 1 business day | 8 AM - 5 PM weekdays |
| Medium (P3) | 3 business days | 8 AM - 5 PM weekdays |
| Low (P4) | 5 business days | 8 AM - 5 PM weekdays |
Resolution time targets
Resolution time = Time from issue report to barrier removed or workaround provided.
| Severity | Target resolution | Maximum |
|---|---|---|
| Critical (P1) | 24 hours (workaround) 5 business days (fix) | 10 business days |
| High (P2) | 5 business days | 15 business days |
| Medium (P3) | 15 business days | 30 business days |
| Low (P4) | 30 business days | 90 business days |
Notes on resolution
- Workaround: An equally effective alternative that allows task completion
- Fix: The accessibility barrier is removed from the original content/application
- Resolution times start when issue is triaged and assigned
- Clock pauses when waiting for information from reporter
SLAs by content type
Course content
| Issue type | Target |
|---|---|
| Missing captions (student request) | 5 business days or next use, whichever is sooner |
| Inaccessible document (student request) | 3 business days |
| LMS content accessibility | Per severity above |
University websites
| Issue type | Target |
|---|---|
| Primary university website (arizona.edu) | Per severity, expedited |
| Department/college websites | Per severity above |
| Event/campaign microsites | Per severity above |
Applications and systems
| Issue type | Target |
|---|---|
| Enterprise systems (UAccess, D2L) | Per severity; escalate to vendor if needed |
| Department applications | Per severity above |
| Third-party SaaS | Workaround within severity target; vendor fix per contract |
Escalation process
When to escalate
- Issue not acknowledged within response time
- Resolution exceeds maximum timeframe
- Workaround is inadequate
- Pattern of repeated issues from same source
- Reporter requests escalation
Escalation path
- Level 1: Digital Accessibility Coordinator
- Level 2: Unit head/supervisor of responsible party
- Level 3: Digital Accessibility Steering Committee
- Level 4: ADA/504 Coordinator
Escalation triggers
| Severity | Auto-escalate if not resolved |
|---|---|
| Critical (P1) | 24 hours → Level 2; 48 hours → Level 3 |
| High (P2) | 7 days → Level 2; 15 days → Level 3 |
| Medium (P3) | 21 days → Level 2 |
| Low (P4) | 60 days → Level 2 |
Accommodation-related requests
When accessibility issues are reported as part of a disability accommodation:
- Treated as minimum P2 severity
- Coordinate with DRC if student-related
- Document accommodation provision
- Follow up to ensure alternative is equally effective
Reporting and metrics
Tracked metrics
- Number of issues by severity
- Average response time by severity
- Average resolution time by severity
- Percentage of SLA targets met
- Issues by content type/unit
- Recurring issues and patterns
Reporting schedule
- Weekly: P1/P2 issue status to Operations Team
- Monthly: SLA compliance to unit liaisons
- Quarterly: Full metrics to Steering Committee
- Annually: Year-over-year trend analysis
SLA exceptions
SLA targets may be adjusted when:
- Issue requires vendor resolution (third-party software)
- Fix requires significant development work (document in plan)
- Issue is in legacy system scheduled for replacement
- Resource constraints during peak periods (must document)
All exceptions must be documented and approved by Digital Accessibility Coordinator.