In 2001, the Information Technology Industry Council partnered with the General Services Administration to create a tool that would assist Federal contracting and procurement officials in fulfilling the market research requirements specified in Section 508 of the Federal Rehabilitation Act of 1973. The result of their collaboration was the Section 508 Evaluation Template, a simple checklist that allows vendors to document how their product does or does not meet the various Section 508 requirements. The Section 508 Evaluation Template is known as a Voluntary Product Accessibility Template (VPAT). Once a VPAT is complete for a specific product, we refer to this as an Accessibility Conformance Report (ACR).
Vendors who wish to supply electronic and information technology products and services to the CSU must provide a completed VPAT/ACR to attest to their product's conformance to applicable accessibility standards. As of July of 2018, CSU campuses are NOT accepting the deprecated 1.X VPAT form; You must submit a new Section 508 Refresh version 2.X VPAT form. Proposals or bids without a completed VPAT/ACR may be disqualified from the competition process.
Provide a Completed VPAT
VPATs are not subject to copyright laws and are not legally binding documents. A VPAT should not contain or disclose proprietary information; rather, a quality VPAT will faithfully represent a product's current accessibility conformance; whether accessible or inaccessible. The vendor should update their VPAT at least annually and always to coincide with product updates.
The California State University System, and subsequently, Cal State LA, adhere to WCAG 2.0 AA standards (NOTE: Section 508 standards aligned with the WCAG standards at the last refresh, with an effective date of January 18, 2018). Vendors may obtain the latest 508 specific VPAT template from the Information Technology Industry Council.
We require at a minimum that vendors complete the following sections of the VPAT for each product. Also, delineate answers for Criterion, Conformance Level, and Remarks and Explanations for each of your product's unique interface/platforms; web, mobile, and dedicated operating system applications:
- Table 1: Success Criteria, Level A
- Table 2: Success Criteria, Level AA
- Chapter 3: Functional Performance Criteria (FPC)
- Chapter 5: Software
- Chapter 6: Support Documentation and Services
Provide an Accessibility Statement
The purpose of an accessibility statement is to reveal to the end-user accessibility barriers that exist in your product's interface. When vendors are transparent about unresolved accessibility barriers, affected end-users may be able to work around those issues, or at a minimum, they can determine the cause of errors. Accessibility statements may significantly reduce frustration for individuals that require facilitated access. Dedicated accessibility features may also be included in an accessibility statement. Accessibility statements should not include aspirational declarations about generic accessibility standards. A link to a product's accessibility statement should be posted in a conspicuous place within your product, preferably a persistent link accessible anywhere within a product's interface. Include means for the end-user to inquire about specific issues they have experienced within the body of the accessibility statement.
Provide an Accessibility Roadmap
An accessibility roadmap provides the expected vendor timelines to correct accessibility barriers present in a product. Essential components of an accessibility roadmap should include:
- A description of the accessibility barrier
- The current development status to correct the barrier; planned, deferred, etc.
- Timeline to complete
- Existing workarounds
The CSU Accessible Technology Initiative (ATI) provides an accessibility roadmap template for vendors.
Conduct a Product Demonstration
Once we have had a chance to review your documentation, we may ask you to demonstrate your product's functionality. We recommend the person(s) conducting the demonstration are familiar with accessibility features, including a working knowledge of either NVDA or JAWS screen reading software.
- How is accessibility integrated into your development process?
- Does your company have an accessibility training program for product developers?
- What specific tools are used for accessibility testing during product development?
Demonstrate the following actions
- Operate the entire interface with the keyboard only
- Demonstrate a well-defined keyboard visual focus throughout
- Raise the text size to 200% without loss of content or functionality
- Color contrast: The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for large text, incidental text or images, and logos
- Screen reader: demonstrate how the application works with a screen reader (e.g., JAWs or NVDA).
- Remove style sheets (CSS): The application should be fully functional when the style sheets are disabled.
- Navigate to <Help> or the product Accessibility Statement link from within the application. Demonstrate where a user finds accessibility-related information and features, including how a user contacts product support.
For more information about the California State University Accessible Technology Initiative, please visit the CSU Accessible Technology Initiative home page.