Digital Accessibility in the Project Lifecycle
The University is responsible for the accessibility of all digital assets we offer, including those we create and those we procure or acquire from vendors. For projects whose scope includes the creation, redesign or procurement of websites or applications, accessibility must be considered throughout the project lifecycle.
If procuring a website or application, follow the procurement accessibility process.
The following are recommendations for integrating accessibility into each project phase.
Discovery and planning
Assess accessibility impact
Accessibility impact should be determined throughout the planning phase.
- Classifying Accessibility Risk and Impact (requires CNet login)
For higher-impact projects, include the Center for Digital Accessibility (CDA) by emailing digitalaccessibility@uchicago.edu during the planning phase. Please include relevant timeframes for the project. The CDA will participate if resources are available. If the CDA is not available and/or the project team is not fully trained in accessibility, the team may want to request training from the CDA or consider hiring an accessibility consultant.
For lower-impact projects or when the CDA is unavailable, project teams should make best efforts to ensure the product meets the UChicago Digital Accessibility Policy and Standards.
Responsible Party: Project team and Stakeholders
Design
Review user experience documentation: wireframes, user flows, functional requirements, hex values for color choices, and notes about interaction animations. Evaluate for conformance with WCAG 2.1 AA. For more information, refer to the CDA’s Resources for Designers & Developers and Web Accessibility for Designers by WebAIM.
Responsible Party: Higher impact – CDA and project team; Lower impact – Project team
Development
Consider accessibility from the beginning of the development effort. This is much more efficient and provides a greater possibility for success than remediating products after they’ve been created. Review the CDA’s Resources for Designers & Developers for more information.
- Build accessibility testing into the development process.
- Test for conformance with WCAG 2.1 AA using a combination of automated testing tools, running accessibility linters, and performing manual testing (keyboard testing, content scaling and screen reader testing).
- Fix all issues as they are found.
- Consult the CDA as questions arise.
- Apply accessibility principles as content is created or modified. Review the CDA guidance on Accessibility for Content Creators for more information.
- All University websites must have an “Accessibility” link in the footer that directs users to the Access UChicago Now website (https://accessibility.uchicago.edu/) to comply with the University’s digital accessibility standards.
Responsible Party: Project team and content editors
Testing and QA
The QA team should verify WCAG 2.1 AA conformance with a similar combination of automated and manual testing as outlined in the Development phase. For higher impact projects, a manual assessment will be performed by the CDA as resources allow. If the CDA is engaged, they will provide an impact assessment for identified issues. Manual accessibility assessments take approximately two to three weeks to complete. Once a request is assigned, a member of the CDA will contact you to discuss the assessment scope and timeline.
Recommended prioritization for resolving accessibility issues found during this phase, based upon impact:
Highest Priority
- All blocker issues: These issues result in catastrophic roadblocks for people with disabilities and will prevent them from accessing fundamental features or content. Blocker issues put our organization at high risk.
Medium Priority
- Major issues: These issues result in serious barriers for people with disabilities and will partially prevent them from accessing fundamental features or content. People relying on assistive technologies will experience significant frustration as a result.
- Moderate issues: These issues result in some barriers for people with disabilities but will not prevent them from accessing fundamental features or content.
Lowest Priority
- All other issues or accessibility best practices.
All issues should be resolved prior to launch. The site will not be compliant until fixed. If issues are not resolved prior to launch, plan for continued work on accessibility post-launch until all issues are resolved. As issues are being fixed, please contact the CDA for assistance, including for validation of fixes related to highest priority issues. The CDA will engage based upon priorities and resources.
Note: The CDA is a resource for project teams. The CDA does not provide go/no-go decisions for projects.
Responsible Party: Higher impact – CDA and project team; Lower impact – project team
Delivery
- For non-authenticated web properties, contact the CDA post-launch to begin a conversation about potential onboarding to the University’s enterprise accessibility platform, Siteimprove.
- If the CDA participated in the project, include the relevant CDA team members in the Lessons Learned post-project meeting.
Responsible Party: Project team