Disease Surveillance Dashboards
During COVID, public health analysts needed real-time visibility into disease spread data. The tools they had were slow to load, hard to read on field devices, and failed accessibility reviews. This is an illustrative account of how that problem was approached.
01 Problem
The work behind the ask
Disease surveillance at the federal level involves large volumes of data from many sources. During COVID, the velocity of that data increased sharply. Analysts needed tools that helped them understand change quickly instead of waiting for slow dashboards to finish rendering.
The immediate ask was visual redesign. The real problem was architecture. A visual pass on top of synchronous, blocking data fetches would not meaningfully improve anything for people using the system under time pressure.
02 Constraints
What shaped the solution
508 compliance was non-negotiable
Every chart, control, and status indicator had to work with a keyboard and pass a screen reader audit before deployment.
Performance had to account for field use
The dashboard needed to stay useful on rural networks, VPN connections, and older government-issued hardware.
Dependency approvals were slow
New npm packages required approval, so the interface could not depend on a large charting library that had not cleared review.
The data pipeline was fixed
The front end had to consume existing sources and present them clearly rather than wait for an API redesign.
03 Decisions
The choices that mattered
SVG-based Vue components
The visualizations were built as Vue components with direct control over accessible markup, chart labels, keyboard states, and data table fallbacks.
Progressive data loading
The shell rendered immediately. Summary values appeared first, then heavier visualizations filled in as data resolved.
Accessibility in the component API
Charts required titles and accessible descriptions as props. Missing accessibility metadata became a development warning instead of a late audit surprise.
Small reusable states
Loading, empty, stale, and error states were standardized so analysts could understand whether the problem was the data, the connection, or the app.
“The redesign was not just a visual layer. The useful work was making the first meaningful state arrive sooner and making every chart understandable without sighted mouse interaction.”
04 Outcome
What changed
- Improved perceived performance by showing useful summary information before every dataset finished loading.
- Kept charts accessible through semantic labels, keyboard paths, and data table fallbacks.
- Reduced dependency risk by avoiding unapproved charting packages and keeping the component layer focused.
05 Lessons
What this reinforced
Accessibility belongs in the API
If a chart cannot render without accessible metadata, teams are more likely to include it.
Perceived speed matters
A partial but honest first state can be more useful than a blank screen waiting for completeness.
Design can expose architecture
The visual problems were symptoms of data loading and interaction problems underneath.
Need the implementation side?
I work best where design systems, accessibility, and front-end architecture need to meet in production code.