Accessibility isn't new. It's been a good practice, and in many cases a requirement, for years. What's changed is that it's no longer optional or something to get to eventually. Updated ADA Title II rules now adopt WCAG 2.1 Level AA as the legal standard, and the scope covers employee-facing systems and third-party vendor software, not just public websites. That puts PeopleSoft, and every customization built on top of it, squarely in scope for most universities, agencies, and enterprises.
This shift is catching a lot of teams unprepared. Delivered PeopleSoft functionality can meet a baseline, but customizations and configurations often don't, and most organizations haven't had a reason to check until now. Common gaps include inconsistent screen reader support, keyboard navigation issues in grids and modal dialogs, and custom pages that were never evaluated against WCAG at all.
Knowing the standard exists doesn't tell a team where to start, though. If you're in that spot, here's a framework based on my own experience working through this at our university.
The Framework
Inventory your pages:
Map every page across all functional areas that end users touch, not just Self Service, but benefits enrollment, time & labor, recruiting, and any custom pages built over the years.
Build a real test group:
Recruit people with disabilities to test, not just internal QA. Lived experience surfaces problems automated tools miss, like confusing flows or controls that pass a scanner but are hard to actually use.
Test systematically:
Use that group or bring in an external vendor (firms like Allyant specialize in this), to evaluate your pages against WCAG.
Track findings:
A simple spreadsheet mapping each functionality to the standard it's failing turns "it's not accessible" into an actionable backlog. If it helps, I put together a simplified tracker template you're welcome to use as a starting point, linked at the end of this post.
Size the effort:
Have developers review the tracker and estimate effort per fix. This is what turns the backlog into a roadmap leadership can commit to.
Fix it:
Work through the prioritized, sized backlog.
Re-test:
Validate with your test group again, plus tools like PeopleSoft's built-in screen reader support, JAWS, and WAVE.
Here's the whole framework laid out visually, if that's easier to reference or share:
Make It Part of the Routine, Not a One-Time Project
The framework above works, but it's really meant to close an existing gap. The real fix is making sure that gap doesn't reopen.
That means accessibility can't sit only with a testing team. FBAs writing requirements, developers building pages, and anyone reviewing a design need to be asking accessibility questions from the start, not after something ships. A requirement that specifies expected behavior for screen readers, a developer who checks focus order before calling a page done, a reviewer who asks "how does this work with a keyboard" as a matter of habit. Once accessibility is just part of how people work, you stop needing a large recurring audit to catch what should have been caught the first time.
The seven-step process is a good way to get caught up. Building accessibility into everyone's normal workflow is what keeps you from needing to run it again.
Further Reading
Tools to Get Started
- Tracker template: a simplified spreadsheet for logging findings during Step 4 (Page/Functionality, WCAG Guideline, Description, Affected Users, Recommended Fix, Priority, Effort, Status), with two example rows to show the format. Attached below.
peoplesoft-accessibility-tracker-template.xlsx