STEP 2: Review Information

In the second step of the process, the ATI Designee receives Accessibility documentation from the Purchase Requester.

Upon receipt of the Accessibility documentation, the ATI Designee is responsible to:

  1. Review Accessibility documentation for completeness and Section 508 applicability;
  2. Initiate the ICT Review Form;
    1. Determine the impact of the proposed purchase; and
    2. Determine the type of review
Table 2 - Step 2 at a glance
Responsible Person Consultation Input(s) Output(s)
ATI Designee Purchase Requester Completed Pre-Purchase Information Form and vendor VPAT Accessibility documentation has been reviewed. Forms are incomplete - return to Purchase Requester; Forms are complete continue
ATI Designee Purchase Requester, IT Staff ICT Review Form Template Initiated ICT Review Form including impact level and review type
ATI Designee Purchase Requester, IT Staff, Vendor VPAT Review What should be completed on a VPAT. How to review a VPAT.

Step 2 - Details

Review Accessibility Documentation (2a)

In this sub-step, the ATI Designee reviews the Accessibility Documentation provided by the Purchase Requester.

First, the ATI Designee reviews the Pre-Purchase Information Form for completeness and verifies if the requested product / service meets the definition of Information and Communication Technology (ICT). All purchases of ICT are required to conform to Section 508 Accessibility Standards and require an Accessibility review.

Second, the ATI Designee checks to see if the Purchase Requester has provided up-to-date Voluntary Product Accessibility Templates (VPATs) for all requested products and interfaces (e.g. public-facing interface, administrative interface.)

The ATI Designee works with the Purchase Requester to obtain any missing information or incomplete Accessibility Documentation.

Initiate ICT Review Form (2b)

In this sub-step, the ATI Designee initiates the ICT Review Form. The ICT Review Form is used to record detailed information about the requested product/service, process checklists, and other details about the accessibility review.

Determine Impact (2b.1)

In this sub-step, the ATI Designee determines the potential impact of the proposed purchase, especially for persons with disabilities.
The ATI Designee evaluates the potential impact of the proposed purchase by considering what the product/service does, where in the university the product/service will be used and by whom, and how widely used the product/service will be.
Factors that may lead to a high impact determination include:

  • The product/service would be used by a large number of persons;
  • Access to a program/service may be denied;
  • A critical program/service may be impacted;
  • The cost to provide accommodations would be high;
  • The product/service's use would create significant legal exposure; and/or
  • There are no known workarounds to the accessibility barriers

The CSU ATI Prioritization Framework (authentication required, must log into CSYou before going to the link) is a resource that provides detailed guidance about the recommended process campuses can use to determine impact.

Determine Review Type (2b.2)

CSU campuses are still building capacity to fully review all ICT purchases. Per Coded Memorandum AA-2013-3, campuses should take into consideration both impact and campus capacity levels when prioritizing ATI activities such as accessibility reviews.

There are several review tasks that can be combined to complete the accessibility review. It is important to remember that a campus' determination of which review tasks to perform for an accessibility review will depend on many situational factors including impact, campus capacity and capabilities, and any other constraints at the time the review is conducted.

The following is a list of review tasks that can be recommended for the review:

VPAT Review

The ATI Designee reviews the VPAT and evaluates the vendor's stated level of support for each Accessibility Standard.

The CSU is conducting a series of accessibility trainings for compliance standards based on section 508 in alignment with WCAG 2.0. For additional information please refer to Voluntary Product Accessibly Template (VPAT) Review.

After completing the VPAT review, the ATI Designee annotates the original VPAT and sends it to the vendor along with a request for any necessary clarifications or revisions.

Vendor Demo (Accessibility Features)

It is common for purchase requesters to request a live demonstration (either in-person or via web conference) for a product or service that is being considered for purchase. In the context of an Accessibility review, the ATI Designee would be invited to attend the demonstration, and he/she would ask the vendor to complete certain tasks while using the product in way that a user with a disability might (e.g. with a screen-reader, without mouse, without audio.)

Automated Testing (Targeted or Comprehensive)

Automated conformance testing can be performed using automated testing tools. Automated testing tools range from free, browser-based add-ons/tool bars up to Enterprise-grade tools for auditing, testing and monitoring (e.g. HiSoftware Compliance Sheriff.)
It is important to note the proper role of Automated Testing. It is estimated that automated conformance testing can definitively determine compliance for only about twenty-five percent (25%) of web content. Determining compliance for the remaining seventy-five percent (75%) requires either manual testing or functional testing for sensory and mobility impairments.
Still, automated testing can and should play a vital role in many accessibility reviews. The benefits of using automated testing include:

  • Open Source Evaluation Tools: No cost, quick, end-users can perform quick checks for common accessibility problems with only minimal training
  • Enterprise-grade tools: regularly scanning university websites using standardized checkpoints provides a mechanism to produce baseline compliance reports and document improvement over time.

Manual Testing (Targeted or Comprehensive)

Manual, hands-on accessibility testing is performed by users of assistive technology or testers who attempt to use the product while simulating the experiences of users with various disabilities. Testers use assistive technology such as screen readers, screen magnifiers, test with sound turned off, use only the keyboard for navigation and interaction, and use voice recognition software to interact with the product.
Items identified as needing a visual check during the automated testing process are checked during the manual testing process. For example, the automated tool might identify the presence of an image tag <img> in the HTML source code and indicate there is an associated alt attribute <alt>, but only a manual inspection can conclusively determine if the alt attribute that is present is a meaningful equivalent for the visual data.
Given limited campus resources and the time-intensive nature of manual testing, campuses should take into consideration impact and campus capacity levels when determining the scope for manual testing.

Code Review

Code review is most often performed during a Level III accessibility review. The review involves examining accessibility gaps at the code level (e.g. HTML source code, JavaScript). The tester does research to determine how to potentially address/remediate specific accessibility gap(s) and finds/develops new/revised coding and does reiterative testing to validate the new/revised coding.