Accessibility ICT Policy Council
Tuesday, March 23th, 2021
3:00 PM - 4:00 PM
Zoom (Please see Outlook Invite for Details)
Members: Melanie Domanico, Bethany Heaton Crawford, Angela King Taylor, Vince Patriarco, Lana Pettit, Miguel Pica, Paula Possenti-Perez, Pamela Thomas, Brian Tibbens, Robin Wade, Scott Warren
Co-chairs: Jenny Gluck and William Myhill
Guests: Trudi Porter
Minutes: Christian Jones
- Welcome/Announcements (Jenny and William)
- Standards Table for ICT (Group)
- Feedback from constituents
In recents conversation we’ve spoken about plug-in applications and to what extent they would be required to go through our process. Should they be included in this chart?
Zoom, for example, is a platform with a whole series of plug-ins that can be added. Today, we have protocol for how we decide what plug-ins we can add. The Zoom Public Marketplace Apps page provides information about the criteria we use.
It would be good to have this documented.
The Wordpress environment is the same type of model. If you were to add something to the CMS for use, should fall under the same criteria.
When it gets interesting is, what if Zoom wasn’t accessible and you still wanted an add-on?
In one sense, it can be argued that one should go ahead with the process for the add-on and put pressure on the platform to catch up.
- Feedback from constituents
We put in place measures to ensure equal access. If a platform isn’t fully accessible, plug-ins should also be evaluated so we know their state.
Pam Thomas clarified that this would go under the web-based products, platforms, and dashboards - add “including plug-ins and add-ons.”
Brian Tibbens mentioned that there are plug-ins for applications, too. This might warrant it to have it’s own category so it covers both groupings.
It is development/customization of ICT software, so maybe add the language, “including add-ons and plug-ins” to both web-based and non-web based areas in the chart.
Future Action item: Define the terms - a glossary of terms - and provide examples of what they mean. Add to existing definitions in the policy? Yes, and elaborate on examples. Pam will provide examples and help with definitions.
Policy has an area of definitions; we will add this to the glossary in the Policy.
The group approved to go ahead with the aforementioned addition of definitions.
- Defining "legacy" (Draft Legacy Software Reference Guide)
The group reviewed the Draft Legacy Reference Guide.
For definition of non-enterprise software. For special class used only by one person, we already have a process to get an exclusion.
Clarify in the definitions that this refers to software used by many individuals - desktop productivity software. We need to break this down a little more.
Robin will work with FDA’s and business analysts to come up with the most used pages.
We need a way to navigate these waters. How else to determine the priority order?
Start with ones the students most use, then faculty, then staff/employees. But how to measure most used?
Pages most used as determined by Trudi Porter’s team is what we’re depending on with priority order of most used by students, then faculty, then staff.
Paula Possenti-Perez recommended creating a matrix.
Pages we can change vs ones we need to work with Oracle on.
If the most commonly used page is one that Oracle provides, we should press them on that. The ROI matters.
Yes, it makes sense to create a matrix. Perhaps Joe Giberman or Counsel or the ITS CIO can help us send a pressing note to Oracle.
A matrix would also help provide a sense of a timeline.
As we do new pages, those would be ensured to be made accessible. Whatever we are touching from here on out needs to be accessible. If we touch one field on a page and move it but the rest of the page is delivered from Oracle, we should technically send the rest of the page off to Oracle to make it accessible.
We are very heavily customized in some of the systems, so to look at each customization to make it accessible would take years. As we create new ones or refine existing ones, we can make sure those are accessible.
2-pronged approach to remediating pages:
(1) Someone demands it and an update is required (federal regulation change, etc.) and you take into account what it takes to make it accessible.
(2) Looking at the environment holistically, see what is most used and schedule remediations.
The intent is to create a plan to hold ourselves accountable to getting it done by a designated end date.
The institution needs to help designate the timeline and resources available to help get it done. It doesn’t fall entirely on Trudi’s team/EAS to get it done. If the University wants it to be done in 5-10 years, the cost/resources required are different from those needed to complete the project in 20+ years.
We need to have a logical way to approach it that is measurable and will achieve the objective. There’s going to have to be a process associated with this. Usage information matters. If our recruits are dealing with MySlice pages, some areas are going to be Mission-critical. Usage information has to be included.
Pages that are business process required to use to be part of the institution.
Mission-critical, required functionality - registering for classes, getting a degree, applying for employment, etc.
“Most used,” alone, isn’t necessarily the identifier of value. Mission critical (essential functionality) and/or frequently used should be the key components.
We’re providing an example map that could be a very different map for a very different product.
With Voyager, for example, different modules matter. The public generally only interacts with a couple different modules, but as a whole it is integral to library services. The language for PeopleSoft is not equal to that used for Voyager.
Mandatory interfaces have to be accessible, and functional service priority of the interface has to be reasonable.
Looking at how we frame the “negative” side is also important - low-use, non-Mission critical ranking. We could be looking at four boxes - mission critical, non mission critical, high-use, and low-use. You’d want to avoid non-mission critical/low-use.
There are a couple different strategies that may differ depending on the software but there are qualities that will work most of the time.
We need a shared understanding:
(1) Acknowledging the reality of the space,
(2) That we never want to have a barrier to academic success by something not working, and
(3) That functionality, if used frequently, also has to be accessible.
We need to refine this.
WCAG uses “key functionality” instead of “essential functionality.”
Be careful in use of “key” interchangeably with “mission-critical.”
- Having a current plan for replacement/remediation for all non-compliant legacy software
Continue to work on the language around “legacy.”
We will update definitions in the appropriate spaces accordingly.
Create a matrix.
Timeline - how long can we wait for plans and what do plans look like?
If people want to send in suggestions prior to the next meeting, that is welcomed and we will incorporate them into this planning.