Accessibility ICT Policy Council
Tuesday, February 23rd, 2021
3:00 PM - 4:00 PM
Zoom (Please see Outlook Invite for Details)
Members Present: 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: Cindy Hoalcraft, Kathy Kinney, Cheri McEntee, Trudi Porter
Minutes: Christian Jones
- Welcome/Announcements (Jenny and William)
- Review Policy Changes from 2/9 Meeting (Christian)
Pam Thomas kindly drafted an AICTPC Standards Table, which we ask that you review by the 3/23 meeting.
- Recommendations - Public-facing table / Private table (Group)
- Recommendation 7: The University intends to continue to use WCAG 2.1 AA for new purchases; SU will fall back to WCAG 2.0 AA for existing products and services, until the next ICTAP policy review.
- Recommendation 8: Add a progressive standards intent table that includes historical citation dates.
- Legacy Software and Content (Recommendation 9)
- Software types
As we review these recommendations, we would like to take time to address the types of changes you’d like to make to PeopleSoft.
Today we have legacy software that is being modified. When we make a modification, we have a responsibility to make sure it is up to speed with accessibility standards, which we expect to apply to both new and legacy software.
As we move from PeopleSoft to HCM, the fluid environment is accessible for the most part.
The project that went live in 2018 used fluid technology, designed to create accessible pages (Payroll, for example). Cheri McEntee and others are in the midst of a People Tools update now and have been working with Pam Thomas to ensure that we’re adhering to accessibility requirements. A lot of the pages are still not fluid-based, and in many cases, still have accessibility issues.
Cindy Hoalcraft added that Oracle (PeopleSoft (MySlice)) is responsible for making it accessible, but if we make a tweak to a page/field, it could result in inaccessible content. For anything we build, we adhere to the standards of accessibility, and anything we customize, we seek to make as accessible as possible. We are continually treading a balance on what is within our means to change, but it is always with best effort that we seek to make accessible modifications to these pages.
Since the Campus Solutions 9.2 upgrade to PeopleSoft, we brought in an accessibility consultant to look at the pages we were changing, and made a series of adjustments in response with adherence to the WCAG checklist. We worked with alternative text, for example to ensure that analysts could use a screen reader to interpret content.
Any time someone creates something, they must refer to the accessibility checklist of items to ensure they are being as inclusive as possible.
However, there are times when we are limited in what we can do by the tools of the product.
William Myhill asked for examples of software that fall into the legacy category.
HR/Payroll is one example of legacy software through the Oracle/PeopleSoft HCM that was modified with accessibility in mind. All pages/areas in that section are fluid-based.
Conversely, if you use Campus Solutions (Registrar functions, Bursar, Financial Aid, Admissions, financials, e-Pro, etc.), this is legacy software that’s not yet (completely) accessible. Some of it includes customized delivered pages.
The bulk of Campus Solutions (namely, the student side) is still an older, classic view, as opposed to what staff see on the backend which is a more fluid look.
The Library’s Voyager: We’ve had this system for several versions since 1997. These systems are offered by vendors and are continually upgraded.
What is meant by “legacy?”
Legacy software has commonly been around for a while, is constantly updated, is quite large in scale and is often integrated with other systems.
Many times, there are so few products out there that function on as large a scale as what the current products offer. Additionally, some of the massive systems can’t just be moved away from, and would require multiple years to execute and develop reintegrations.
Is it fair to say that some legacy systems are accessible but then the customization renders them inaccessible?
No. In the case of Oracle/PeopleSoft, we report out to Oracle. We only customize to include as many accessible elements as possible.
When we created the Policy, the assumption was that legacy software was mammoth in scale and difficult to change (or had no plans to change). When new versions of the software were released, we gave folks the bandwidth to make the versions accessible. There are also many pieces that are forward-facing but that haven’t been touched for years.
Trudi Porter added that we’re updating the navigation in MySlice - move to tiles and making the navigation accessible. This is what Pam has been assisting us with.
If the page isn’t changing, we’re not necessarily making a change. If it is changing, then we need to make it accessible.
PeopleSoft has classic development tools and is fluid. Fluid content should be automatically accessible (according to PeopleSoft). If not, we report it to Oracle. The problem is that we have customized the classic one, so to get to the fluid, we either accept it as it is or further customize it.
Paula Possenti-Perez tied this back to the intent of the AICTPC, noting that the interpretation of legacy software is acquired prior to the creation of the Policy. Is the purpose here to identify the legacy software - enterprise systems where any original purposes would be before Jan 2018 - and have some sort of mapping of when they’re getting modified?
As Oracle is moving away from on-premise to on-cloud, we’re less likely to go back to on-premise to make adjustments, and more likely to encourage folks to move to on-cloud systems.
It’s also not likely that PeopleSoft/Oracle would provide a list of dates by which components would be accessible.
There’s no itemized assessment of which pages/components are deficient, and there will always be bits and pieces of this software that are not accessible.
Perhaps that’s too much into the technical weeds of what this Policy intends to do. For this group’s intent, it may be more focal to help develop a roadmap. If we don’t put a marker in for a deadline, it won’t be done. The policy was signed off by the Chancellor and if he chooses to do away with certain software, he will. We also don’t want to put something in that isn’t realistic. How do we safely add a realistic but flexible marker?
The Policy won’t include how we actually get it done. We just want a realistic timeline so we’re not setting unreasonable expectations - this would be a high level assessment. We’ve been given a mandate by the Chancellor.
Cheri asked about a timeline for assessments of possible products. We can at least put down a plan of assessment for potential completion within 4-5 years total.
William suggested that we may need to define legacy within the Policy with some gradations as to different types of legacy software.
Pam agreed. All of these things will present different ways of dealing with them.
What would the plan or path forward be for something we can’t change?
How do we know what legacy systems need to be on that list?
Pam noted that if needed, there is the option to seek an exception if it’s the only thing out there that does what it does, assuming an accommodation is available.
- Content types (deferred to a future discussion)
- Legacy ICT without Modifications
- Legacy ICT with Modifications
- Auto-renewing ICT
- Software types
- Homework/next steps
- Review next recommendations
- Draft Standards Table - Please review with your constituents by Tuesday, March 23rd.
- Next Meeting (March 9th)
It sounds like a roadmap is a reasonable strategy.
We need to define legacy.
There’s a path between customizations and whole-sale changes.
For the next meeting, we can continue this conversation and flush out some of the details.
Paula recommended a “path forward strategy.”
We’re still in the software types category. There’s a range of content types as well.
Next meeting, we’ll hold an internal debriefing and define the pieces we discussed, then once determined by our group, invite today’s guests back to share what we need.
Ohio State University - Interim University Policy for Digital Accessibility