Treating accessibility and performance as product quality

Context

The product had grown quickly, and quality issues were showing up as friction in both usability and implementation consistency.

Problem

Accessibility and performance were treated as separate cleanup tracks rather than core product behavior.

Constraints

• Limited time for broad rewrites
• Team needed visible progress quickly
• Improvements had to work within active roadmap delivery

My role

Frontend engineer

Collaboration

I worked with design and product partners to prioritize the fixes users would feel most immediately while keeping engineering changes maintainable.

Frontend decisions

• Addressed semantics, focus behavior, and rendering cost together
• Preferred small structural changes with compounding benefits
• Added implementation guidance that future contributors could actually follow

Artifacts

• Performance snapshots
• Accessibility audit notes
• Component state inventory
• Before and after interaction passes

Outcome

I helped make quality easier to discuss in concrete terms, and moved the frontend baseline closer to the standard users should expect by default.

Notes

One of the most useful outcomes was internal clarity. Once the team could see quality work in product terms, accessibility and performance stopped sounding like special-interest engineering topics and started sounding like obvious priorities.