University Councils and Committees
Page tree

Participants: Donna M Carelli , Joseph M. Giberman Jenny Gluck , Christian JonesVincent M Patriarco , Paula Possenti-Perez , William N Myhill  Pamela J Thomas 

Draft Purchasing Process for ICT

Proposed Recommendation Language Changes


Additional Proposed Changes

Recommendation 3: Embed vendor obligations and tertiary links in the ICT Policy, where the language is applicable to all purchases and is consistent with other procedures and policies across the campus. 

Policy5.A.1 ProceduresCVendor is obligated to provide an updated third party VPAT 2.X or WCAG AA 2.X, whichever is most current (please refer to the Information Technology Industry Council's (ITIC)  VPAT page for most up-to-date information). Include an up-to-date VPAT demonstrating conformance. 
Recommendation 10: Include examples of indirect, contracted ICT products and services that must adhere to the policy. Policy5.A.1 ProceduresC

"Indirect ICT services are support features for a contracted service that is not itself ICT. A few examples of purchased or contracted services that include indirect ICT are:

  • Research projects that include a report;
  • Employee wellness services that include self-help materials as electronic files;
  • A conference or other service that includes online registration;
  • Promotional materials and brochures that will be put online;
  • Forms that will be distributed as paper and made available online;
  • Employee training that includes handouts, computer-based training (CBT), or distributed slide decks;
  • Counseling services that include a web-based chatroom;
  • User manuals provided in electronic format; and
  • Any vendor service that includes a survey.

Contracts for services that include or may include the indirect use of ICT must include requirements for vendor compliance with the WCAG 2.0 AA guidelines. The vendor must include as a deliverable within the contract an accessibility compliance report using the HHS WCA."


Recommendation 15: Explicitly include a vendor section documenting expectations concerning the procurement process and product and services deliverables; importantly, we are anticipating increased staffing to provide ICT consulting to the Purchaser and Vendor. 

Policy5.A.1 ProceduresCTBA

Recommendation 23: To avoid the risk of procuring inaccessible products or services, the policy should include a purchasing process requirements table, similar to the draft version (in the report).

Policy5.A.1 ProceduresCTBA


Did the proposed language for the Purchasing policy, as discussed in the 9/7/21 AICTPC Meeting, get approved?


Flow Charts

  • First step in the process: What are we looking for? How are we making the selection? Vince Patriarco, Donna Carelli, and Nicole Schafer drafted two flow charts to identify the process for procuring information communication technology (ICT) and aid today’s discussion. 
  • Below $10K
    • Per the Purchasing Policy, Purchasing doesn’t need to be involved in the purchase but still wants to be sure the product is accessible and accounted for. 
    • Some products require contracts and some don’t. Where does this play in the workflow, and what happens with those software agreements? Does Joe Giberman oversee them or does this or part of this responsibility belong to Legal? We’ll need to expand upon that decision box. 
  • Between $10K and $25K
    • Campus community members can bid on their own, but are required to either have a bid or non-compete form. 
    • At this point, we have some better control points.
  • Above $25K
    • Requesters must have a bid on a product. 
    • Nothing goes through without a non-compete form and they require a dual sign-off. 

Continued Discussion

  • It’s so often that accessibility is considered after deciding on a piece of software one wants to use. It would be so much better for the broader campus if we could build accessibility into the process of choosing a product.
  • Building language into the Purchasing Policy will aid with this, as will updating the flow chart to reflect this goal from the start of the process. 
  • When a purchase is above $10K, there are some triggers that enable us to have greater oversight, but we do not have the same control over purchases under $10K.  
    • We do have some control over purchases below $10K that go through a purchase order (PO). 
  • Maybe pro-card holders need to be better informed and held accountable. Development of required training for card holders would be useful. It’s a cultural change that may take some time. 
  • We need reminders/triggers to ensure compliance - maybe this includes modifying the reconciliation process to include an accessibility check, or adding an accessibility field. 
  • When a cardholder is up for renewing their card, perhaps follow-up training should be required to renew your card. 
    • Making changes on JPMC’s end may be a challenge, but internal changes are certainly feasible. 
    • Vince will look into what is possible. 
    • Flag an MCC code, for example. 
  • There are also procard limits to consider, most of which fall between $1-3K, where there is some oversight by Purchasing. Additionally, between $3-$10K, if coming through requisition/PO, it goes through Purchasing for approval. 
  • For purchases below the spending limit (ie, under $1k), maybe we look more to the back-end/approver end to put checks in place since Purchasing doesn’t see the front end for up to $3K.
  • What if we expand on or create a new box for ICT purchases both below $10K and above $10K that denotes an accessibility check?
  • Pam Thomas recommended that a security review also be added to this preliminary/discovery phase in the process, alongside accessibility. Doing so will help make (both) seem more commonplace, and part of how we do business. 
  • We do maintain a space in the AAC Answers page for past requests, but this is only a snapshot of the status of a product; we are continuing to explore how to make that page more helpful to the campus. 
    • Vince mentioned that such a list might be better kept behind a login soas to emphasize that this is not public information. 
  • Considering what other institutions have done would also be helpful, but it seems Syracuse University is ahead of the curve in many ways compared to others who are not as far along in addressing procurement of accessible products.
  • We might also benefit from a fresh look at the HirePotential recommendations and the basis on which those examples were created. 
  • A challenge nationally in building some shared resource for accessible ICT is that many institutions don’t want to publicly vendor-shame those who are not compliant. There are cases of them sharing VPATs but not directly stating whether or not a vendor’s product is accessible. 
  • Again, getting the information in front of people so that accessibility is part of the decision-making process would be ideal. 


  • The other element we should discuss is whether or not a contract is needed. If it is, how do we address that? 
    • Joe noted that with regards to contracts with external parties policy, the policy doesn’t make a distinction between a contract that requires a signature and one that is legally binding. For just about any software, there is almost always at least a terms page that requires agreement to the policy to use the product. 
    • Anything that costs less than $250K (or other large price point) should generally come through ITS, at least as a start, to be reviewed. After this point, maybe it needs to go through Counsel and reviewed by ITS as needed. 
    • How does the University want to handle the risk associated with the battle of the form? 
    • More conversation will be needed. 

Next Steps

  • Where can we add some of his content and begin looking at procedures? 
  • Vince will look into the procard changes.
    • Since we have a list of procard owners, Paula Possenti-Perez recommended surveying them to find out what it would take to make it easier for folks to be more inclusive about the ways they make purchases.
    • Purchasing is actively reviewing the program and there is active intent to cut down on the number of cards. Accessible ICT procurement training could be mandated at the time of receiving a card and/or when you go to renew a card.
    • Not everyone who makes purchases does so through PeopleSoft. Purchasing is already working on adding to the trainings for new employees/cardholders. 
  • Do we want to share with the wider group? At some point, we’ll need to hash out or form a working group to develop the details. Do we share flow charts or start digging or share high-level with the group?
    • William Myhill would like to do more work with it and put the accessibility parts into the flowcharts before running by the AICTPC. 
    • We’ll need this subcommittee to help with the development of the changes desired. 
    • The group agreed to send Vince recommended modifications and he’ll work on an updated document. We can meet again to review once there is a modified version to work from. Vince will coordinate a follow-up meeting once we have this modified version.  
  • No labels