The newsletter for product leaders who want to kill rework before it slows delivery.
This is for you if you keep noticing that:
- work everyone thought was already finished resurfaces,
- quality problems are found too late in delivery,
- teams are constantly debating what done means,
- ownership is split across Product, Design, Engineering and QA.
Every day, I write one short email about the product habits behind accessibility rework, so you can:
- spot accessibility debt before it becomes a project,
- use better metrics as early warning signals,
- make ownership clearer across Product, Design, Engineering and QA,
- connect accessibility to product quality and delivery confidence,
- make better decisions when the answer is not obvious,
- reduce care friction in patient portals, booking flows and clinical workflows.
Read by product leaders who want accessibility to improve how their teams ship better software. Free, in under 5 minutes a day.
What I write about every day
Accessibility debt
The backlog nobody wants to look at. The audit findings that keep coming back. The small decisions that become expensive because the team keeps shipping around them. I write about how accessibility debt forms, why it sticks and how product leaders can spot it before it slows everything down.
Metrics and early warnings
Good metrics should tell you where rework is being created, not just how many issues someone found.
Ownership and accountability
Accessibility fails when everyone supports it and nobody owns the next decision. I write about what Product, Design, Engineering and QA each need to own so teams stop relying on heroic experts or last-minute QA saves.
Product quality and delivery confidence
Accessibility is one of the places where product quality becomes visible, especially in patient portals, booking flows, intake forms and clinical workflows. I write about why issues appear late, why "done" keeps reopening and how teams can catch weak decisions before they become release surprises.
Decision-making under ambiguity
Rules help, but real product work still gets messy. I write about tradeoffs, judgement calls, escalation and what to do when WCAG does not answer the actual product question.
Meetings and rituals
Meetings are not the point of the newsletter, but they are often where accessibility risk hides. I write about reviews, workshops and planning habits that replace circular debate with useful decisions.
Digital health delivery risk
I write for teams building healthcare software, where confusing forms, brittle flows and unclear errors can block someone from booking care, sharing information or completing a clinical task. Accessibility is part of that product risk.
Sunday comic
Every Sunday, I publish a comic about the strange rituals that keep accessibility broken: maturity models, audit theatre, heroic experts, "we'll fix it later" and meetings about meetings.
Want to get the next email?
This might not be for you if you want:
- generic accessibility awareness,
- beginner WCAG lessons or technical implementation tutorials,
- tool recommendations and accessibility news commentary,
- inclusive design philosophy without product consequences,
- community conversation as the main value.
Having doubts?
I write this list to make the messy parts of accessibility easier to see: the debt, the handoffs, the quality risks and the decisions nobody owns yet. Reply any time. I read every response.
What if the content is rubbish?
Then you can unsubscribe with one click and carry on with your day. I write short, practical notes about accessibility debt, metrics, ownership, meetings and the weird product habits that create rework. Some will land. Some may annoy you. That is allowed.
Is this useful if I know accessibility?
Yes, especially if you care about how accessibility survives inside real product teams. This list is less about technical instruction and more about the decisions, rituals and signals that help teams get accessibility right earlier.
What if you send me too many emails?
You will get 365 emails every year. This is a daily list. Some emails are only 50 words long. Others are closer to 500. I try to keep every email's reading time under 5 minutes.
What if you try to sell me things?
This is not a hard-sell list. I may occasionally mention my work when it is relevant, but you will not get pressure sequences, fake scarcity or third-party promotions. The list is free.
What if you sell my email to others?
I will never sell your email address or share it with anyone else.
What if I get bored? Can I unsubscribe?
Yes. Every email has an unsubscribe link.
Why subscribe if I can read the archive?
You can read every email in the archive. The inbox version is better if you want to reply, challenge an idea or send me a situation from your own team. I read every reply.
Who should not subscribe?
Do not subscribe if you want polished compliance guidance, technical tutorials or perfect answers. I write about messy product work, half-formed lessons, uncomfortable patterns and the occasional typo.
Want the next email?
Still not sure if it's worth your time? No worries, browse the archive first and decide later!