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:
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, a VPAT / ACR is required.
Please see the Purchasing Department's instructions on Technology Acquisitions for detailed instructions on how to initiate an Electronic or Information Technology (EIT) purchase, whether you are doing so with a purchase order (PO), a P-Card, or through the contracts process.
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.
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.
Request a VPAT / ACR review
If you'd rather an expert look at a VPAT / ACR for evaluation, you can submit a request for review:
Additional Resources