University Councils and Committees
Page tree

Accessibility ICT Policy Council 
Tuesday, April 6th, 2021
3:00 PM - 4:00 PM
Zoom (Please see Outlook Invite for Details)

Members: Lisa Andreotta, Bethany Heaton Crawford, Angela King Taylor, Vince Patriarco, Lana Pettit, Miguel Pica, Paula Possenti-Perez, Pamela Thomas, Brian Tibbens, Scott Warren

Co-chairs: Jenny Gluck and William Myhill

Guests: Trudi Porter

Minutes: Christian Jones


  1. Welcome/Announcements (Jenny and William)
    • Paula addressed the announcement around diversity and strategic planning sessions taking place this month, and encouraged the group to attend where possible. She will be hosting three that focus around accessibility. Christian will forward the announcement to the group.
  2. Discussion of "Legacy" Software (Group) 
    1. Matrix (Draft Legacy Software Reference Guide)
      1. Is this enough detail and is it actionable? Can software owners respond accordingly?

      2. One thought was that there would be a document to serve as the baseline evaluation, and possibly another document that articulated the milestones.

      3. This could be a landing spot for additional materials. 

      4. What portion of this will actually be in the policy?

        • The policy defines that this will exist for legacy software, not the specifics. 

      5. It was recommended to add . Summon is tied to Voyager, for instance. Can’t change one without having to mess with downstream or upstream systems. Pulling one out could have other implications on the “stack.” 

      6. Once we figure out that this matrix will work, we’ll charge the group with populating it. 

      7. Brian: adding a dependency field would be critical. Should always be a living document that will grow as we see changes. ICT Policy should reference this document, with the document itself existing separately to undergo continual change. 

      8. Timeline - split into three sections: review date, next steps, and target date

      9. Process for collecting this information

        • Purchasing has a record of most software purchased on this campus. Once the policy is formed, we would form letters to the various purchasers noting that we are starting this process and what to expect with regards to compliance. 

        • There are, however, other products that do not go through Purchasing.

        • We can broaden the perspective of the timing to make sure we catch as many products in existence as possible. 

        • It could have gaps but it will be helpful to have a starting point. 

        • We will need partnership from across campus to do this, not only those of us in this Council.

      10. Add a column to indicate a product’s version. 

      11. Lana noted that we also need to consider software donated or otherwise free. Trudi added the consideration of software created entirely in-house, where nothing is purchased, and the people using that software are the only ones who will have information about it.

      12. Whether free or not, we should also consider if it’s open-source versus vended. There may not be a way to hold an open source community to a timeline. IF using open-source software that is never updated, you may need to fix it or find an alternative. The expectation is that people will have to update it and tell us - repair or replacement date would have to be part of the timeline; alternatively, you’d have to get an exception. 

      13. For an exception you have three options: 

        • 1: Undue burden, which is highly difficult to prove and based on the University as a whole;

        • 2: Commercial nonavailability; and

        • 3: “Not technically possible” to bring into compliance, which is also very difficult to prove. 

      14. Is it useful to include the version of WCAG being used at the time of the evaluation?

        • It may have to do with the time the standard was adopted. Purchases from that point forward have to meet that standard. 

        • We have to think careful about the expectation; legacy software is different - if it’s something that was purchased pre-WCAG, it would be legally required to conform to Section 508. However, the University says WCAG compliance is the standard so it would need to be replaced. This is where it gets tricky. 

        • If the audience is students and its a barrier to success at Syracuse University, you have to find an alternative. That’s where it would be part of the negotiated timeline - repair or replace it. 

      15. People may also be incentivized to get on the accessibility list as a means to replace something; this could be an opportunity to demonstrate a need for replacement. 

        • If in fact your software is on the list and is not accessible and is a barrier for students/faculty/significant population, that could be assistance for justification to get funding for what you need. There will be a priority measurement. 

      16. In terms of managing a table like this and knowing there could be dozens/hundreds of software products, managing this could be at least a part-time job. Communicating with numerous parties and ensuring information is up to date could be a large undertaking. Is there an opportunity to include a means to provide resources for actionalizing this in the policy? 

        • Part of our role is not only to define the policy but to define what needs to happen and the resources for actionalizing these steps. 

      17. During our last meeting, Paula was interested in articulating specifics in the policy. Would these be the kinds of specifics to include while referencing the charge but not including the charge? 

        • It would give the campus enough detail on what their reporting obligations would be, and us enough detail to be able to evaluate and give feedback to those who provide software. 

        • The roadmap could have specific dates and present a master timeline and milestones. A WCAG manual evaluation or VPAT could support this.

      18. With the variation of documentation being discussed, could there be useful and/or not useful duplication of efforts?

        • In talking about legacy software, when we have a piece of legacy software to make compliant, where does it go? 

        • If it goes off of legacy and onto a new list, the new list will also a living document of products that will eventually need to be reevaluated. How do we keep track of those forms as they transition? We will have legacy problems with the evolution of WCAG as well. 

        • We’re already up to a full FTE just on the management and tracking perspective. 

      19. The idea of using this table as more of a status table is welcomed. The roadmap could be the official document/expectation and promise of what will happen. If we used this as a status table, the timeline column could display the next steps and upcoming date(s) for action. This could continue to be useful as a status table for future evaluations. 

      20. Regarding the timelines, do we know of a contractual hold or similar trigger that could serve as a stop-gap?

        • Version number would be a good trigger/stop-gap.

        • Adding another column that indicates that there is a contractual date, which would help due to the renewal basis (annual, multi-year, etc.). There will be capacity constraints on all of this.

      21. We’re going to need a database for this, and a project manager.

  3. Homework/next steps
    1. Get feedback on the Matrix
      1. We need to think about how to implement this and there is a resource ask for building and running it. Please think about if the table has the right fields that would be most useful to both the Council and also to those of you who are owners of software. 

    2. Language
      • At the next meeting, we’ll talk about language and terminology as it relates to people with disabilities - both in the Policy and with others across campus.
  4. Next/Future Meeting
    1. Terminology/Use of Language (Paula) 
      1. Disability language
    2. Legacy Content
      1. Inventory
      2. Strategy 
        1. Legacy ICT without Modifications
        2. Legacy ICT with Modifications 
        3. Auto-renewing ICT 

Supplemental Materials:

Accessibility ICT Policy 

Accessibility ICT Policy - Working Document

 Standards Table for AICTPC (Draft)

Draft Legacy Software Reference Guide

Ongoing Issues to Address

  1. Glossary of Terms
  2. End of Exception Cycle
    1. The exception is only good for the term of the version. How long is the life of the exception? What triggers a review of the product?
  3. Auto-renewals
  4. Vendor-deliverables 

Next Meeting: Tuesday, April 6, 2021

  • No labels