Accessibility Feedback Is Product Strategy

I recently built a prototype filter for a collection of articles. On a large screen, it looked pleasantly simple: a row of coloured lens buttons, a second row of subject tags and an animated transition between results. I was ready to refine the spacing.

Then I tried to use it without a mouse.

The focus order followed the visual layout, but the selected state was announced inconsistently. Colour carried more meaning than I had realised. When the results changed, the update was obvious to a sighted reader and silent to someone using a screen reader. The feature was not a finished interface with a few accessibility defects. It was an incomplete idea of what interaction meant.

That distinction is worth sharing while a product is being made. Accessibility work is often presented as correction: run an audit, identify failures and bring the implementation towards a standard. Standards are essential, but the most useful feedback can alter the product itself. It asks who the imagined user is, which abilities the flow assumes and whether the chosen interaction communicates its purpose at all.

For the filter, the first improvement was not an ARIA attribute. It was a clearer model. Was the user navigating to a category page, changing the current set of results or building a multi-part query? The original design blurred all three. Once the behaviour was defined as filtering the current page, the interface could announce the number of matching articles, preserve a predictable focus position and provide an ordinary link to each permanent category.

Sharing this process in public does two things. First, it gives other builders a concrete lesson: accessibility problems may reveal conceptual ambiguity, not only missing code. Second, it makes the project’s assumptions available for challenge before they become expensive.

That challenge needs to be invited carefully. Disabled people are not a free testing service, and a public post should not ask strangers to perform unpaid quality assurance. Useful participation can include paid research, clearly scoped testing or an open request for observations that does not imply obligation. When feedback influences a decision, credit should be offered in the way the contributor prefers.

It is also important not to turn accessibility into a heroic makeover story. A builder discovers exclusion, fixes everything and receives applause. Real accessibility is ongoing because content, technology and people’s circumstances change. A component that works today can be broken by the next update. A technically conforming flow can remain exhausting or confusing. Public notes should make room for uncertainty and continued work.

In this prototype, reduced motion changed the design beyond adding a media query. The animated transition had been doing two jobs: providing delight and signalling that the results had changed. Removing it without replacement made the interaction less clear. A short textual status and a stable heading improved the experience for everyone, including readers on slow devices and people quickly scanning the page.

Language raised similar questions. Labels such as “Interdependence” carry editorial meaning but may be unfamiliar out of context. Adding a concise description helped readers understand what they would find. The accessibility improvement became information architecture.

This is why accessibility belongs in product strategy. It reveals dependencies between interface, content, performance, support and trust. If a verification process repeatedly excludes people, support teams inherit the consequences. If a publishing tool makes alternative text awkward to enter, editors will skip it under deadline pressure. The visible defect may sit in one screen while its causes run through the system.

The public changelog can reflect this broader role. Instead of listing “accessibility fixes” as a separate technical category, describe what readers can now do and which product assumption changed. That language makes the work easier to understand and harder to postpone. It also avoids presenting disabled users as edge cases who benefit only from specialist remediation.

The next version of the filter is less visually clever than the first. It is also more explicit, more stable and easier to extend. That is not a compromise in which accessibility defeated creativity. It is evidence that a wider understanding of use produced a better design.

Building in public is most valuable when the public record includes changes of mind. The polished screenshot can wait. The important artefact is the moment when another person’s way of encountering the product revealed what the product actually needed to become.