Case study / Design systems
Not just a bug
Identifying the common system issue behind a growing list of accessibility problems.
ACCESSIBILITY BUGS, FORMS & INPUTS· 4 MIN READ
Overview
As the design system moved to a new front-end framework, the components were rebuilt separately rather than migrated from a shared behavioral model.
Context
Brought in for my expertise in inputs and forms, I joined the effort to fix more than ten accessibility problems in Forms, Inputs, and help features at the field level. These issues came from engineering alerts, customer reports, and team feedback, and at first seemed unrelated. The design system uses two technologies for different versions, and since clients might still use older versions, we can't just stop supporting the old library and fix only the new one.
By reviewing the design in Figma, I connected each issue to its part and tested different sizes, label positions, content lengths, and help feature settings.
The problems had one thing in common: it was never clear how compact and density features work together.
Defining the problem
The quick fixes had to work with the old component library without changing settings already used by products, while the new version gave us a chance to create a simpler model.
One problem was label readability, especially with inside labels, where long text was cut off, and the tooltip only appeared when the user hovered over it. So, I couldn’t turn off inside labels when using compact help features without affecting clients and other products. Also, inputs and help features are used in table cells, tight layouts, and data grids, so one solution couldn’t work everywhere.
Through my analysis, I identified that Compact UI Density could work as the common way to save space for inputs and forms. As a team, we defined two paths:
- A quick fix for the current system, delivered in two to three weeks.
- A more intentional model for the next generation, developed over two months.
Mapping the decision space
I designed a matrix covering interaction states, density settings, long real-content scenarios, translation, and inputs, with drill-down features. This helped us consider every interaction design decision and better answer engineering and product teams about what we were facing: a system-wide problem, not just separate bugs.
From that framework, I led the work across two areas:
- Overflow — Redwood supported three different label positions: inside, top, and start. Inside labels truncate with a tooltip on hover or focus; outside labels wrap to remain readable.
- Screen readers — I set the order in which information is read across components and worked with the team to create shared rules, including reading full labels even if they are cut off visually.
- User Assistance — the hardest part to fix — required separate ownership. It had more types, ways users interact, and setting combinations than any other area. This led to the project's biggest structural decision:
From different behaviors to one system
| FOUND | ALIGNED |
|---|---|
| Different label behaviors | Label overflow guidelines |
| Multiple screen reader announcements | One announcement model |
| Required Indicator inconsistencies | The User Assistance designer on the project tackled the model |
| Compact layouts behaving inconsistently | Density became the shared reference |
| Focus order inconsistent with assistive technlogies | Focus order behavior |
Outcome
I resolved the accessibility issues in inputs, overflow, and screen readers. As a team, we delivered two integrated solutions and guidelines for the current and next-generation system library.
The most impactful part of the delivery was the clearer User Assistance model developed in parallel. Product analysis showed Compact User Assistance was used in less than 1% of codebases, giving the team confidence to remove it from forms without causing major problems. Compact Display stayed available for tables and data grids, where space and interaction needs were different.
The screen reader documentation I developed lasted beyond the project. It became part of a bigger effort to include accessibility interaction details in design documentation and led to an invitation to run an internal accessibility workshop.
Reflection
I spent the first weeks attempting to align Compact User Assistance with compact-density inputs in forms, only to realize later these patterns addressed different problems. Compact density had already fulfilled the need for space-saving in forms.
Looking at real product usage and involving the engineers who knew the system earlier would have surfaced that sooner. Still, the work was not wasted: the pattern that failed in forms became the right solution for table cells and data grids.
Key takeaway
Inaccessible experiences are not always visible and may not even be flagged. I learned that some users get used to it. In this project, a major design system failure was not even reported, which is why I pushed for a wider audit across devices, screen readers, and reflow scenarios.
It also made me question how I behave myself in the day-to-day, for example when I share design decisions, making sure the meaning is clear even without what is visible on screen.
Accessibility does not end when the design file is done. It continues in how we share and explain our work.