The Challenge
Accessibility was an afterthought in our organization's process for too long. Despite the fact that we were building customer-facing web products for large organizations, accessibility compliance wasn't systematically factored into estimates, development workflows, or QA processes.
The PLCB project provided the catalyst to change that. I initiated and led a comprehensive accessibility audit as part of that engagement, with the explicit goal of not just fixing the immediate issues, but building a process that could be ported to future projects.
Output from Oracle's internal accessibility evaluation tool – one of several tools used during Phase 1 of the audit
The Audit Process
I structured the audit in two phases:
- Phase 1 – Automated scanning: A member of the design team reviewed both the B2C and B2B PLCB sites using browser-based accessibility plugins. This surface-level scan caught the most obvious issues – missing alt text, poor color contrast, unlabeled form fields – and gave us a baseline count.
- Phase 2 – Manual screen reader review: Design and QA team members followed up with in-depth manual reviews using screen readers (VoiceOver on macOS and NVDA on Windows). This phase uncovered issues that automated tools miss entirely: unintended reading order, ambiguous link text, focus traps, interactive elements that weren't keyboard-accessible.
Every issue discovered was logged as a JIRA ticket – over 200 in total. We categorized them by severity and assigned them to the appropriate team for remediation across multiple release cycles.
Accessibility issues documented as JIRA tickets – over 200 logged, categorized by severity.
Errors captured during screen reader testing – the manual phase uncovered issues automated tools miss entirely.
Beyond the Audit: Building a Process
I led the development of two lasting process changes. First, we began org-wide accessibility training, including the "why" behind accessibility requirements as well as the how.
Second, I revised our project estimating process to include dedicated accessibility development and testing time on every new engagement. Previously, this work had been invisible in estimates – it either didn't happen or came out of development and QA's general time budget, which meant it got deprioritized. Now it has a line item.
What I Learned
The lesson from this project isn't really about accessibility specifically – it's about the need to continually push to build broader practice changes. Even after the success of this effort, subsequent accessibility estimates have been called into question by leadership. Having this success to remind everyone of the value properly addressing accessibility is a big step forward for our team.