I create operating models
Making a complex product ecosystem testable and fixable
Meta’s in-app browser needed to understand its accessibility health and prepare for changing regulatory expectations. But reliably testing a large browser ecosystem required much more than sending a few screens to an auditor. I helped build the structure, test environment, ownership model, and remediation process needed to turn accessibility from a broad concern into actionable product work.
Problem
The browser needed a reliable way to understand accessibility health, reproduce priority flows for testing, assign ownership, and turn findings into remediation.
Outcome
The work created a repeatable accessibility operating model: map the product, establish a baseline, prioritize findings, assign owners, remediate, and re-audit when possible.
The challenge
Accessibility had not been formally assessed as part of the browser team’s normal product process in this project context.
A minimum-viable accessibility audit established a 3.45/5 baseline — above the company average of 2.7, but below the team’s north-star target of 5.
The challenge was not just identifying issues. It was creating the operational conditions needed for outside testers and internal teams to reproduce complex flows, understand findings, assign ownership, and make remediation possible.
What I did
I helped turn a broad accessibility mandate into an operating system.
I mapped priority flows, account conditions, browser states, and navigation paths and helped create the vendor-ready accounts and guidance required for reliable third-party testing.
Then I co-led the cross-functional process for triaging findings, assigning ownership, coordinating fixes, and turning individual accessibility lessons into reusable product standards.
Accessibility health snapshot
Vendor testing path
Entry point→Account condition→Browser state→Target experience→Interaction→Expected accessible behavior
The test path turned conditional product behavior into reproducible steps an outside vendor could audit consistently.
Resolution
Accessibility became something the team could measure, assign, and act on.
The work established a baseline for product health and a repeatable process for moving from audit findings to remediation, rather than treating accessibility as a one-time review.
Map the product→Establish a baseline→Prioritize→Assign owners→Remediate→Re-audit when possible
Impact
Accessibility program impact
The program helped establish a durable accessibility process and contributed to leadership support for continued accessibility work.
Reflection
Accessibility problems are often systems problems.
Finding an inaccessible screen matters. Building the conditions that let teams consistently find, own, fix, and prevent those problems is what makes the work scale.