Case study 02  //  Logistics  //  9 weeks  //  2025

Orbital Freight

Two dispatchers had been working around the console on paper for a year. Nobody upstairs knew.

ASCII rendering of concentric orbital rings representing the Orbital Freight tracking console, drawn in green characters.
0WCAG 2.2 AA failures
−44%Dispatch error rate
Faster keyboard triage
214Regression tests added

01 // The brief

A compliance deadline, and a much worse problem underneath it

Orbital Freight books and tracks container shipments. A procurement contract required a VPAT, so the ask was narrow: pass the audit. During the first week of discovery I sat with the dispatch floor and found the actual situation.

Two of the eleven dispatchers use screen readers. Neither could complete a booking in the console. They had built a parallel process on paper and phone calls, and one of them had been quietly asking a colleague to do the final submit for eleven months. Their error rate was triple the floor average, and management had read that as a performance issue.

02 // The constraint

The console runs the business, live, all day

Nothing could ship as a big-bang release. The floor works 05:00–22:00 with a three-hour overnight gap, so every change went out in that window, behind a per-user flag, with the two dispatchers testing first thing the next morning.

Nine weeks, thirty-one deploys, one rollback.

03 // What shipped

Five workstreams

  1. A real keyboard model. The booking grid was 400 nested divs with click handlers. Rebuilt as a proper grid with roving tabindex, so arrow keys move between cells and Tab moves between regions.
  2. Focus management on route change. Focus was silently dropping to <body> after every navigation. Screen reader users had to Tab from the top of the page 60+ times to get back to work.
  3. Live regions for shipment status. Status changed in real time and announced nothing. Now a polite live region reads the delta, with throttling so a busy morning does not become a wall of speech.
  4. Names on everything. 180 icon-only buttons had no accessible name. The audit counted this as one failure. Users counted it as 180.
  5. 214 regression tests. axe-core in CI for the mechanical checks, plus Playwright journeys that complete a full booking using only the keyboard. The build fails if a booking cannot be completed that way.
fig. 02 — WCAG 2.2 AA failures by week
  w0  ████████████████████████████████████████████████████  61
  w2  ███████████████████████████████████████               47
  w4  ██████████████████████                                26
  w6  █████████                                             11
  w8  ██                                                     2
  w9                                                         0
      +----+----+----+----+----+----+----+----+----+----+
      0   10   20   30   40   50   60
          

04 // The result

The performance issue was never a performance issue

Both dispatchers now complete bookings unassisted, roughly three times faster than their previous workaround. Floor-wide dispatch errors fell 44% — the keyboard model turned out to help everyone, not only the two people it was built for. The VPAT was a by-product.

client

“The audit alone was worth the fee. Two of our dispatchers use screen readers and had been quietly working around the console for a year. That is fixed now, and the tests keep it fixed.”

— Dev Ramaswamy, Head of Operations, Orbital Freight

05 // What I would do differently

I should have insisted on the floor visit before quoting

I scoped this as a nine-week audit-and-fix from a screen share. The real scope only surfaced once I was sitting next to someone using the thing. I absorbed the difference. Now every accessibility engagement starts with a paid half-day of watching actual users, before any number goes in a proposal.


Do you know who cannot use your product?

An audit takes two weeks and tells you which of your users are currently working around you. Usually there are some.

Reply within 4 business hours, guaranteed.

Start a project Call