Software, Systems, and Applications Standard

As a general rule, USU departments and employees are responsible for the accessibility of the software, systems, and applications they create, publish, maintain, manage, distribute, or procure, with help and guidance provided by support teams.

Quality Standard

Software, systems, and applications must meet WCAG 2.1 Level AA requirements.

Scope

This standard applies to software, systems, and applications (including cloud-based and locally installed software) that are developed, acquired, or used by USU to conduct its programs, services, or business operations. This includes free, paid, trial, and open-source tools.

Individually licensed software that is used exclusively by the purchaser does not need to meet these standards. While the software itself is not required to meet this standard, any digital content, files, communications, or materials created with that software and used for USU programs, services, instruction, or activities must comply with this policy.

Requests for Exceptions

Requests for exceptions to this standard will be reviewed individually by the Digital Accessibility Steering Committee through the Accessibility Exception Request process.

Lack of sufficient funding for any unit, department, or college of the university as the sole reason for an exception will not be considered.

Pre-Approved Exceptions

The following exceptions have been granted. An Accessibility Exception Request does not need to be submitted:

Industry‑standard software required for academic programs or job functions may qualify for an exception when no comparable accessible alternative exists. Highly specialized software used for research or required by grants or external collaborators may also qualify when modification is not feasible.

Compliance

Software used at Utah State University may be developed internally, purchased from third‑party vendors, or acquired through other institutional arrangements. In all cases, departments are responsible for leading accessibility reviews and maintaining compliance with this standard throughout the software lifecycle. Digital Accessibility Services supports these efforts by providing guidance, consultation, and technical expertise. The following pages describe required actions and best practices based on the method by which software is developed, purchased, or acquired.

Departments must follow required accessibility processes whenever software is purchased, developed, or used. At any stage of the software lifecycle, departments may be expected to help facilitate accessibility reviews conducted by Digital Accessibility Services to address concerns or support institutional compliance. This includes providing access to the software, sharing relevant documentation, and coordinating with the vendor or developer as needed to evaluate and remediate accessibility issues.

Failure to follow established software accessibility processes or to support required reviews may delay contract approvals, postpone implementation, or result in a required pause in software use until accessibility concerns are addressed. When required processes are followed but significant accessibility barriers remain, continued use may require an approved exception or be paused until issues are addressed.

In all cases, the preferred approach is to work collaboratively with vendors to address accessibility barriers whenever feasible.

Best Practices and Recommendations

The following practices are strongly recommended:

Accessibility requirements should be included early in the procurement process.
Request a current Voluntary Product Accessibility Template (VPAT) or Accessibility Conformance Report (ACR) during early third-party vendor conversations.
Include accessibility as an evaluation criterion in Request for Proposal (RFP) processes.
Require third-party vendors to provide remediation timelines for identified accessibility gaps that can be reasonably addressed.
Include accessibility language in contracts requiring ongoing conformance.
Avoid adopting tools that present significant, unresolved accessibility barriers when accessible alternatives are available.
Plan, design, and develop software to meet accessibility standards.
Review accessibility on a regular basis, particularly after software updates or when new versions are released.

Definitions

Accessibility Conformance Report (ACR): A document that describes how a product or service conforms to accessibility standards such as WCAG. Accessibility Conformance Reports are commonly created using the Voluntary Product Accessibility Template (VPAT).
Accessibility Documentation: Documentation provided by a vendor describing the accessibility of a product or service. This may include a Voluntary Product Accessibility Template (VPAT), Accessibility Conformance Report (ACR), accessibility roadmap, testing documentation, or other materials describing conformance with accessibility standards.
Software, Systems, and Applications: Software, systems, and applications include cloud-based and locally installed software developed, acquired, or used by USU to conduct its programs, services, or business operations. This includes free, paid, trial, and open-source tools.
Software Lifecycle: The stages through which software progresses, including procurement, implementation, operation, maintenance, renewal, and retirement.
Third-Party Vendor: A company or organization that provides software, systems, or applications used by USU but developed outside the institution.
Voluntary Product Accessibility Template (VPAT): A standardized document used by third-party vendors to report how their product or service conforms to accessibility standards such as WCAG.

Resources

For questions about software, systems, and application accessibility, please contact accessibility@usu.edu.