from the lab notebook —
A self-service shipping application for fertility specimen logistics, with real-time environmental tracking, multi-carrier labels, and a legally blind collaborator in the room from day one.
IVFCRYO replaced a manual, paper-based shipping process with a web application that handles shipment requests, label generation across multiple carriers, and real-time specimen tracking from integrated sensor data. The people using it are usually in the middle of something high-stakes and emotionally sensitive. Clarity and reliability aren't nice-to-haves here. They're features of the product, and accessibility is how that clarity reaches everyone.
Step one
Fertility logistics has a narrow margin for error. A mislabeled shipment, a missed temperature excursion, or an ambiguous status update isn't just a workflow annoyance. It can have irreversible consequences for someone's family. The people using this tool are often clinicians working under time pressure, or patients and couriers navigating a process they've never touched before, during one of the most stressful weeks of their lives.
That reframes what accessibility means here. It isn't a compliance checkbox to satisfy at the end of the build. It's part of how the product communicates at all: whether status updates reach the person who needs to act on them, whether form errors are recoverable, whether a screen reader user can trust what the page is telling them.
Temperature data, chain-of-custody details, carrier handoffs, all flowing through forms people may be filling out under duress.
A shipment that has moved, a label that has printed, an error that needs correcting. The app has to surface all of it, reliably, to every user.
Step two
The most consequential decision on this project wasn't technical. Instead of treating accessibility as an end-of-project audit, the team brought in a legally blind customer as an ongoing collaborator. He reviewed interface decisions as they were being made, tested with a screen reader while components were still being built, and kept offering feedback as features shipped.
That changes what you build, not just what you fix. Problems that would have surfaced as a long list of bugs at the end (the kind that usually get triaged, downgraded, and half-addressed) instead showed up as design conversations while the design was still cheap to change. The output wasn't a remediation report. It was different decisions.
Errors announced to a screen reader the moment they happen, not buried in a summary at the top of the page after submit.
Shipment state changes are announced automatically, so a user doesn't have to go hunting through the page to learn that something moved.
Consistent, predictable patterns across the app. The kind of thing a sighted user takes for granted and a screen reader user notices immediately when it's missing.
Accessible output at scale comes from accessible architecture, not from accessible intent.
Step three
Collaboration gave us the right instincts. Architecture made those instincts load-bearing. Interactive components were built with keyboard operability and ARIA as primary requirements, not post-hoc additions. Components that controlled visibility managed their own focus internally, so the user never lost their place. Dynamic content (the part of the app that changes while you're looking at it) announced itself to assistive tech instead of silently updating the DOM.
Every piece of information in the UI was expressed through more than one channel: text and icon and color, never color alone. That rule is small, almost boring, and it prevents an enormous class of failures that would otherwise quietly ship.
Step four
Once the component library has the right behaviors baked in, every feature built on top of it inherits them. A developer shipping a new shipment form doesn't have to remember to wire up live regions, or decide how focus should move when a dialog opens, or check contrast against the palette. Those decisions have already been made, correctly, once.
That's the structural benefit of putting accessibility at the architectural level: it stops being a discipline individual developers have to sustain, and starts being a property of the system they're building inside. The ceiling of accessibility in the product is no longer the ceiling of any one engineer's attention.
New features get accessible behavior without anyone having to remember to add it.
Status changes, errors, and recovery paths reach the person who needs to act on them.
No remediation backlog waiting at the end of the project, because the backlog was never created.
signed off —
What Josh did at IVFCRYO wasn't a typical build. He insisted we put a blind user in the room from week one, and that decision changed the product. We didn't pass an accessibility audit at the end — we shipped a tool that was accessible because it was built that way.
Don Fish
CEO · IVFCRYO
Start with a free scorecard, or grab 30 minutes on my calendar to talk through where accessibility is slipping out of your architecture.