Stephen Hoang / Case study 01
Turning Accessibility Audits into Measurable Improvements
How I helped a public transit agency tackle recurring accessibility problems through systematic testing, root-cause analysis, and developer collaboration.
- Accessibility strategy
- Technical analysis
- Remediation management
- WCAG
- Starting point
- 213 issues on 12 priority pages
- Biggest single fixes
- 371, 332 and ~430 findings
- Overall result
- ~75% fewer automated findings
213 issues on 12 pages—and more surfacing with every scan
Our public transit website had accumulated a substantial number of accessibility findings.
A manual audit of 12 priority webpages identified 213 issues, while recurring automated scans revealed additional problems across the wider site.
The challenge wasn't simply finding more issues. It was understanding which problems mattered most, what was causing them, and how to make meaningful progress without addressing every occurrence individually.
Many of the findings originated in shared components and site-wide settings. Fixing those underlying problems offered a much better return on development time than addressing the same symptoms repeatedly.
My approach: find patterns, not just problems
I established a recurring process for reviewing accessibility findings, investigating root causes, coordinating development work, and monitoring changes.
- Automated scans alongside manual keyboard and screen reader testing, to understand how technical failures affected real interactions.
- Reporting organized by WCAG success criterion, separating website issues from PDF-related findings, so progress could be tracked across different types of remediation work.
Project evidence
The recurring remediation cycle
Each cycle moved from evidence to diagnosis to verified fix. The key steps are the third and fourth: grouping findings and looking for a shared cause before anyone writes code. The re-scan at the end is what turned fixes into measurable results.
- Step 1
Automated scan
Site-wide findings
- Step 2
Manual testing
Keyboard and screen reader
- Step 3
Group by WCAG criterion
Web vs. PDF issues
- Step 4
Find the root cause
Shared component or setting?
- Step 5
Fix with developers
One change, many pages
- Step 6
Re-scan and report
Did the count drop?
The cycle repeats: each re-scan becomes the evidence for the next round of priorities.
Three examples illustrate the approach.
Three focused fixes resolved more than 1,100 recurring findings
Project evidence
From hundreds of findings to three underlying causes
Read each row left to right. The amber bars show the relative size of each group of scan findings. Each group traced back to a single cause, and one change to that cause produced the measured result on the right.
| What the scans showed | Underlying cause | One focused fix | Measured result |
|---|---|---|---|
Widespread color-contrast failures | Theme configuration mismatch | Corrected the colors the theme applied to text, with our development partner | 371 fewer instances |
Recurring directionality errors | Language-selection component | Changed the component's selectors with our developer | 332 findings removed |
Errors on FAQ pages | Shared accordion component | Identified alternatives and coordinated remediation | ~430 resolved |
One theme setting was behind hundreds of contrast failures
Automated scans were reporting widespread color-contrast problems.
Rather than approaching each occurrence separately, I investigated the website's theme configuration and identified a mismatch affecting the colors applied to text. Working with our development partner, we corrected the configuration.
The subsequent scan reported 371 fewer contrast-related instances. A relatively focused change had addressed a problem repeated across the website.
A translation component was generating 332 recurring errors
Another group of findings involved the website's language-selection functionality.
I worked with our developer to investigate the component and identify changes to its selectors.
The correction removed 332 directionality-related findings from a subsequent scan. This reinforced the value of treating automated reports as diagnostic evidence rather than simply lists of individual tasks.
Fixing one shared accordion resolved about 430 findings
Our frequently asked questions used accordion components that were generating recurring accessibility issues.
I investigated the pattern, helped identify alternatives, and coordinated their remediation with developers.
Approximately 430 accordion-related scan findings were resolved during the March remediation cycle. By focusing on reusable components, we addressed problems across multiple pages without treating every occurrence as a separate project.
Automated findings fell by about 75%—with manual testing to catch the rest
I maintained regular accessibility reporting so that we could see whether remediation was making a difference.
Project evidence
Automated findings on the main website, before and after
The executive progress report documented approximately 75% fewer automated findings since the initiative began. The bars are indexed so the starting point equals 100; actual counts are confidential.
Index: starting count = 100. Approximately 75% reduction.
Alongside that progress, I continued using manual testing to identify barriers that automated tools could miss, including keyboard access to route information and screen reader interaction problems.
What I learned: many findings can share a few causes
The biggest improvement in our approach came from changing how we interpreted accessibility reports.
A large number of findings doesn't always mean a large number of unrelated problems. Sometimes it points to a small number of underlying causes affecting many parts of a website.
My role was to make those patterns visible, translate them into development priorities, and verify the results.