Global Mining & Metals Company · 2025 · Frontend developer
Making an internal data workspace usable on a tablet
Rebuilding a dense desktop-only data interface so it worked on the tablets it was actually being used on, in the field.
- Interaction latency
- −65%
- Rows rendered
- 10k+
- Audit issues closed
- 31
Stack
- React
- TypeScript
- Container queries
- Virtualised lists
- WCAG 2.2 AA
The problem
An internal workspace built for 1920px desktops was, according to analytics, mostly being opened on tablets. The layout was fixed-width, the primary data table scrolled horizontally into unusability, and rendering a large result set locked the main thread for seconds at a time.
The approach
The layout was rebuilt around container queries rather than viewport media queries. This mattered more than usual here: the same panels appear in a sidebar, a split view and a full-width view, and what they need to know is how much room *they* have — not how wide the window is. That removed a set of size props that were really workarounds for CSS not being able to ask the right question.
The table was virtualised so that only visible rows exist in the DOM, which is what took interaction latency from unacceptable to unremarkable at ten thousand rows. Filtering was moved off the interaction path with startTransition so typing stayed responsive while an expensive recompute ran.
Accessibility was treated as part of the rebuild rather than a follow-up. A full audit surfaced the usual suspects — div-as-button, icon buttons with no accessible name, error state communicated only by colour, skipped heading levels — and all of it was fixed by using the correct elements rather than by adding ARIA.
The outcome
The workspace became usable on the devices it was already being used on. The accessibility audit closed with 31 issues resolved and the interface reaching WCAG 2.2 AA, which also made the whole thing keyboard-navigable — an unplanned win that the power users noticed first.