For over a decade, I've worked with people in the healthcare and education sectors.
I've seen inaccessible portals, forms that break under basic keyboard navigation, PDFs nobody could use and accessibility fixes put off until they became way too expensive to do anything about. I've seen and worked with teams trying to do the right thing but had almost no support.
I've also seen some great things.
I've seen people fight for users they would never meet. I've seen engineers become quiet brilliant at catching issues early. I've met product people who pushed back on shipping something they knew would make life harder for someone.
But I don't think I ever stopped long enough to question the shape of the problem.
I questioned the technical decisions.
Why is this button not a button? Why does the focus disappear here? Why does this form error not get announced? Why does this heading structure look off?
These are useful questions. Necessary questions.
But they're too small on their own.
I could have asked better ones.
Why did this issue reach QA in the first place? Who thought this work was done? Where did the decision get lost between product, design, engineering and QA? How could the team have known earlier that accessibility would become a problem? Why does that same problem come back in different parts of the product? Why does accessibility depend so much on which person happened to touch the ticket?
Those are the questions I want to spend more time with now.
Especially in digital health.
Because in healthcare software, accessibility failure is not some abstract compliance thing. It can mean someone cannot book an appointment, or read their test results, or fill in a form. It could very well mean they cannot manage their care without asking someone else for help.
I doubt many of these failures come from bad people or lazy teams.
It's more than likely they come from unclear ownership, late decisions, weak definitions of done, missing feedback loops and delivery pressure that rewards "finished" work even when the work is not really finished.
I'm 41 now and I like to think I have 15 more good years of useful work in me. Maybe more if I behave myself, but that seems unlikely.
But let's say 15.
I'd like to spend those years on the part of accessibility where I think I can make the most difference. Helping teams make better decisions earlier, while real work is happening.
I've had enough heroics at the end, enough of the break-fix cycle and enough work being reopened when everyone thought was finished. I'd like to see more teams that know what done means before release pressure makes everything harder.
I don't have all of this figured out yet. That's part of why I'm writing about it.
I want to understand how accessibility rework happens inside growing digital health companies. I want to understand what product leaders already measure, what they wish they could see earlier and where teams get stuck when everyone agrees accessibility matters.
So this newsletter is going to become more exploratory for a while.
There will still be technical accessibility when it helps. But I want to look more closely at the product habits around the technical failures, at all the decisions that led to the problems, at the unclear handoff before the broken flow and all the metrics that might have warned someone sooner.
If you work in digital health, product leadership, delivery, design, engineering or QA, I'd love to hear what you see.
Where does accessibility become rework in your team?
And who do you know that I should talk to to learn more?
DMs are open, as they say.