Per Binghamton University and SUNY policies, all 3rd party electronic information technology (EIT) including hardware, software and related information technology used by members of the university community to access university programs, services, or activities must be accessible. This includes items obtained through the procurement process (Contracts and Purchase Orders), items purchased on PCards, and open source software and services.
It is essential that departments discuss accessibility with vendors in the beginning stages of the procurement process. Accessibility must be a top priority when researching vendors.
To start the conversation with vendors, use this helpful SUNY Letter to Vendors Providing Digital Resources.
What are VPATs and ACRs?
While often used interchangeably, there is a technical distinction between the two.
VPAT® (Voluntary Product Accessibility Template)
This is the blank template created by the Information Technology Industry Council (ITI). It provides the structure vendors must use to document how their product conforms to accessibility standards like WCAG 2.1 or 2.2.
ACR (Accessibility Conformance Report)
This is the completed document. Once a vendor fills out the VPAT for a specific product version, it becomes an ACR.
Note: When you ask a vendor for their "VPAT," you are actually asking for their completed ACR.
Procurement Methods: Accessibility Rules Always Apply
The requirement for accessibility documentation is not determined by the dollar amount or the "officialness" of the paperwork. Whether the purchase is $50 or $50,000, the product must be accessible.
Rule of Thumb: If a student, faculty member, or employee must interact with the technology to do their job or complete their studies, an ACR is required.
Contract Workflow
For large-scale software or services that go through the Binghamton Contract Workflow, a VPAT / ACR is a mandatory submission. The ITS and Accessibility teams will review these documents as part of the standard approval process before any contract is signed.
Purchase Orders (PO)
Even if a formal contract isn't required, any EIT product purchased via a Requisition/Purchase Order must have a valid ACR on file. Departments should request this from the vendor before submitting the requisition to Purchasing.
Responsibilities
- The vendor must run the required accessibility tests and document them in the VPAT/ ACR.
- The person requesting the purchase must obtain the VPAT/ACR from the vendor.
Risk:
If a purchase is found to be inaccessible and creates a barrier for a user, the department may be required to discontinue use of the tool immediately, regardless of the cost.
P-Card Purchases
This is a frequent point of confusion. Accessibility requirements apply to P-Card purchases. * Examples: A $20/month subscription to a specialized design tool, a $200 plugin for a website.
Responsibilities:
- The vendor must run the required accessibility tests and document them in the VPAT/ ACR.
- The person requesting the purchase must obtain the VPAT/ACR from the vendor and provide it to the P-Card holder for documentation.
- The individual cardholder must ensure that they have a VPAT / ACR showing the accessibility of the product before they make the purchase.
Risk:
If a P-Card purchase is found to be inaccessible and creates a barrier for a user, the department may be required to discontinue use of the tool immediately, regardless of the cost.
Help with Assessing a VPAT /ACR
A completed ACR is a self-representation by the vendor. It must be vetted for accuracy. You don't need to be an accessibility expert! VPATs are relatively easy to interpret, but we also have a team of expert reviewers that evaluates every EIT going through the contract workflow.
For Purchase Orders and P-Card purchases, you can request expert evaluation of a VPAT you've obtained from a potential vendor.
What to Look for in an ACR (The "Red Flag" Checklist)
Here are some tips if you'd llike to evaluate the quality of a VPAT / ACR yourself. Check these key sections:
Product Information (The Header)
Report Date: Must be within the last 12 months. If the product is cloud-based (SaaS) and the ACR is two years old, it is effectively useless because the software has likely changed significantly.
Version Number: Ensure the ACR matches the exact version of the software Binghamton is purchasing.
Evaluation Methods: Look for "Manual testing with assistive technology (e.g., NVDA, JAWS)" or "Third-party audit."
Red Flag: If it says "general product knowledge" or only used automated testing methods the report is likely less accurate or incomplete.
Conformance Levels
Vendors use four standard terms. Here is how to interpret them:
- Supports: The feature works for everyone.
- Partially Supports: Some parts of the feature are broken (e.g., a button works with a mouse but not a keyboard).
- Does Not Support: The feature is inaccessible to certain users.
- Not Applicable: The feature doesn't exist in the product.
The "Remarks and Explanations" Column
This is the most important part of the report.
Detailed Notes: A good ACR includes specific technical notes (e.g., "The 'Submit' button lacks an ARIA label").
Red Flag: If the remarks column is empty or says "N/A" for every row, the vendor likely did not perform a real test.
Red Flag: It is extremely rare for a complex software product to be 100% accessible. A report that claims "Supports" for every single item without notes is often a sign of filling it out without doing the actual testing.
Additional Resources