Web Applications
Accessibility remediation on an employee onboarding portal
Built by Camille Anne Villaruz
Worked through an accessibility audit on a portal used by every new hire, and fixed the causes rather than the findings.
Builder email verified
Verification
- Type
- Professional
- Category
- Web Applications
- Published
- Jul 25, 2026
- Updated
- Jul 25, 2026
About this project
- The problem
An external audit returned about a hundred and forty accessibility findings on a portal that every new employee has to complete in their first week, including a document upload step that was unusable with a screen reader and a progress indicator that announced nothing. Beyond the compliance obligation, the practical failure was that new hires who needed assistive technology had to ask HR to complete the forms on their behalf, which several had. The client wanted the findings closed; I wanted the underlying components fixed so they would not come back.
- My role
Contract frontend engineer, four months, working inside the client's product team. I owned the remediation plan and did most of the implementation, with their engineers picking up patterns as we went.
- What I owned
I triaged all hundred and forty findings into root causes — they collapsed to about twenty distinct component problems — and fixed those components rather than the individual pages. I rebuilt the upload step, the multi-step progress indicator, and the form error summary, which were the three that mattered most. I wrote the automated checks that run in the pipeline and the manual test script for the things automation cannot catch. I also ran two sessions teaching their team keyboard and screen reader testing.
- Technical & product decisions
I insisted on grouping the findings by cause before fixing anything, which took two weeks and looked like no progress. The alternative — working the list top to bottom, which is what the client expected — would have produced identical fixes in eleven places and let the next audit find them again. I chose to make the automated checks blocking in the pipeline from week three, accepting that it would break builds, because a non-blocking check is a check people learn to skip. On the upload step I rebuilt it on the native file input rather than the custom drag-and-drop widget, which lost a small amount of visual polish and made it work everywhere.
- Constraints
The portal integrates with an HR system whose embedded widgets I could not modify, so three findings could only be mitigated rather than fixed and I documented them as such. Testing with actual assistive technology users was limited to two sessions the client could arrange, which is fewer than the work deserved. The remediation also had to fit around a fixed compliance deadline, so the last three weeks were verification rather than new fixes.
- Result & impact
A hundred and thirty-one of a hundred and forty findings closed, with the remaining nine documented as third-party with mitigations. The upload step went from unusable with a screen reader to completing in a single pass in our verification session. The automated checks now catch regressions before merge — they have blocked eleven since I left, according to their lead. The clearest outcome is that HR no longer completes forms on anyone's behalf.
- Who else worked on it
Two of the client's engineers paired with me on the last six weeks and now own the checks. An accessibility specialist ran the verification testing and wrote the final report. Their HR operations lead arranged the two user sessions and gave me the honest account of how people had been working around the portal.