What is an Accessibility Assessment?
An Accessibility Assessment is a process that evaluates and documents information about an application, vendor, and the stakeholders to comply with OSU's Digital Accessibility Policy (PDF). When an Assessment is requested, College of Engineering Digital Accessibility Staff will work with the requester to make sure all requirements are met to proceed with purchase and/or use of the desired software. All software and applications used and produced by the College requires assessment.
Accessibility Assessment Process Overview
An assessment is a comprehensive process that covers every part of the required policy compliance. While the process can take some time, it is a necessary one to make sure that software either meets requirements or considerations are in place for remediation and accommodation.
1. Getting Started
When: Prior to purchase or start of development, but as soon in the process as you are able to.
How: Via the ETS Service Catalog or contact the ETS Helpdesk.
Applies to: All software, licensed/purchased/used or developed in-house.
2. Provide Information
- Product name and version
- Vendor/developer name and contact
- How many potential users?
- Course related?
- Open to public?
- Is this in use elsewhere at the University?
- (For licensed) Can the vendor provide a VPAT (Voluntary Product Accessibility Template)?
- (For licensed) Has the vendor done accessibility testing?
- (For in-house developed) Is the Developer meeting Minimum Design Accessibility Standards?
3. Determine Risk Level
Digital Accessibility Staff will evaluate your information and determine the Accessibility Risk Level:
A4 - Critical: >40,000 Users, or Course-Related, or Open to General Public
A3 - High: 10,001 – 40,000 Users
A2 - Medium: 501 – 10,000 Users
A1 - Low: <= 500 Users
4. Plan Next Steps
Digital Accessibility Staff will work with you to determine next steps based on where you are in your process, the Accessibility Risk Level, and University Policy requirements.
If this is a new product, part of this step will include a discussion whether another more accessible or already tested product can meet your needs.
Digital Accessibility Staff will perform testing, based on the Accessibility Risk Level and materials provided.
This will always involve a Quick Test and a review of the VPAT from the vendor, or a review of the results with developers for in-house applications.
Higher Risk Levels (A3-A4) will require a Full Manual Test, which is a longer and more comprehensive test done by a certified tester. This test may be waived if the vendor provides proof of testing.
6. EEAAP Planning
Using the results of the testing, Digital Accessibility Staff will work with you to build an Equally Effective Alternate Access Plan (EEAAP). This is an agreement on what resources will be provided if there is a request for accomodation and how this will be communicated to the target audience.
7. Contract Language/ Remediation Plan
Some Risk Levels (A3-A4)require language to be inserted into the contract of a licensed or purchased product to address current and future accessibility related concerns. Your Digital Accessibility Coordinator will provide this language.
At all levels, if any unaddressed accessibility barriers exist, a Remediation plan is created and agreed upon with the vendor or developers to address these on an established timeline.
8. File Exception
If there are accessibility barriers in a product, then an Exception has to be filed with and approved by the OSU ADA Coordinator's office. An Exception is a comprehensive document that includes all of the materials that you and Digital Accessibility staff have created through this process.
The Exception stays on file, and is good for 1-3 years, depending on the Risk Level.
9. Finishing Up
Once all the steps are done, your purchase or deployment is ready to move forward!
When your product comes up for renewal, or when an Exception comes up for review, the product will be re-examined and if any remediation was required, a review will check to see if they have been addressed and if documentation is still accurate and applicable. The EEAAP will also be reviewed to make sure it is still applicable and communications information is up-to-date and accurate.
All software purchased, used, deployed, or created by faculty, staff, and students of the College of Engineering for work, research, or academic purposes. This includes websites/web applications (public or internal), software used for classes, including software that is free or open source, or developed by or for faculty, staff, or students of the College.
Yes. Software already in use, known as legacy software, will need to be assessed. This is currently planned to be done as this software comes up for contract renewal when applicable. For internally developed software, or software that is not used under a vendor contract, the stakeholders will be contacted as staffing availability allows.
The process of an assessment can take some time, depending on the vendor, staffing availability, Risk Level, and state of the application being assessed. We recommend allowing at least a few months in your purchasing planning if your software is potentially A3 or A4 Risk Level
In the Accessibility Assessment process, an Exception comes about as a result of testing and so does not replace it or negate it as a step in the process.
There is a case where testing may not be required: if the vendor has had full testing performed and provides that report to College Digital Accessibility Staff, then a Waiver can be requested from the ADA Coordinator's office.