When polished designs hide uncertainty
Sep 12th, 2026
Polished designs can hide unanswered questions. Making those questions visible helps teams plan the work before development starts.
I started this newsletter on March 12th, 2024 and wrote every day for 945 days. These are the emails from that run, alongside anything I've written since. Browse by topic or search for something your team is dealing with.
Sep 12th, 2026
Polished designs can hide unanswered questions. Making those questions visible helps teams plan the work before development starts.
Sep 11th, 2026
An accessible component helps, but teams also need to check whether people can complete the task without unnecessary effort.
Sep 10th, 2026
Technical choices belong with the people doing the work. Choices that change who can use a feature need a wider conversation.
Sep 9th, 2026
Accessibility issues found late often start with earlier product decisions.
Sep 8th, 2026
Accessibility can belong to the whole team, but each decision still needs someone responsible for moving it forward.
Sep 7th, 2026
When accessibility depends on one person speaking up, product quality changes with every team and every release.
Sep 6th, 2026
In Issue 114 of Access Denied, Gary thinks opening tickets for accessibility is a good default.
Sep 5th, 2026
Teams make more consistent accessibility decisions when clear expectations and useful defaults are already part of their work.
Sep 4th, 2026
When accessibility problems keep returning, the pattern can tell product leaders where teams need better support.
Sep 3rd, 2026
When an accessibility issue appears, find the earliest moment the team could have caught it without adding another approval step.
Sep 2nd, 2026
Accessibility support should help teams make better decisions themselves, without waiting for an expert to approve every detail.
Sep 1st, 2026
Teams need clear expectations, useful defaults and support when choices get difficult.
Aug 31st, 2026
Listening helps me understand a decision.
Aug 30th, 2026
In Issue 113 of Access Denied, Gary first needs someone to blame before accessibility can be fixed.
Aug 29th, 2026
How I ask teams about inaccessible work without turning the conversation into blaming.
Aug 28th, 2026
Understanding why a team made an inaccessible decision helps me challenge it in a way that leads to better work.
Aug 27th, 2026
Why I try to understand a team's decisions before offering accessibility advice, even when I think I know the answer.
Aug 26th, 2026
Three questions that reveal where accessibility rework enters your product process.
Aug 25th, 2026
You can define done too early and not reduce any rework.
Aug 24th, 2026
How missing done definitions turn into release debate and accessibility rework.
Aug 23rd, 2026
In Issue 112 of Access Denied, Gary thinks fixing the same issue all the time signals success.
Aug 22nd, 2026
A short list of product metrics that can warn accessibility is becoming delivery risk.
Aug 21st, 2026
Accessibility can be both human impact and delivery risk.
Aug 20th, 2026
Some fixes need to live in patterns, not tickets.
Aug 19th, 2026
Accessibility debt often starts as small exceptions, unclear decisions and repeated fixes you learn to tolerate.
Aug 18th, 2026
Why finished needs a shared meaning before work can move forward.
Aug 17th, 2026
Silly mistake in Kit prevented any emails from sending.
Aug 16th, 2026
In Issue 111 of Access Denied, Gary pitches continuous accessibility coverage.
Aug 15th, 2026
Introducing the email course for digital health product leaders who want fewer late accessibility surprises and less rework.
Aug 14th, 2026
Repeated accessibility issues cost more than one fix.
I write about accessibility rework, product quality and the decisions teams make while building software.