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.
- Stack
- Vue 3 + Vite
- Compliance
- WCAG 2.1 AA / 508
- Data Update Rate
- Near real-time
- Users
- Federal analysts
The Problem
Disease surveillance at the federal level involves enormous volumes of data from many sources. During COVID, the velocity of that data increased sharply. Analysts who needed to make recommendations on disease spread had tooling that was genuinely in the way: dashboards that took 15 or more seconds to render, charts that conveyed no information to a screen reader, and layouts that collapsed completely on tablet-sized devices used in field settings.
The immediate ask was visual redesign. The real problem was architecture. A visual redesign on top of a synchronous, blocking data-fetch pattern wouldn't meaningfully improve anything for the people who had to use it under time pressure.
Constraints
Non-negotiable: 508 compliance
Section 508 compliance wasn't optional or aspirational. Federal systems face compliance reviews, and any accessibility finding blocks deployment. Every chart, every interactive control, every status indicator had to work with a keyboard and pass a screen reader audit.
Performance on limited connections
Not every analyst works in an office on a fast connection. The performance target had to account for field use: rural networks, VPN overhead, and older government-issued hardware. A solution that worked beautifully on a development machine and failed in the field wasn't a solution.
Dependency approval cycles
Introducing new npm dependencies into a federal system requires approval. That process takes time and limits the options available. The component library couldn't lean on third-party charting libraries that hadn't already cleared that process.
Existing data pipeline
The backend data sources weren't changing. The front-end had to consume what existed and present it well, not wait for an API redesign that would have taken months on a federal procurement timeline.
Key Decisions
Vue 3 + Vite, not a chart library
Rather than adopting a full charting library, the visualizations were built as SVG-based Vue components with full control over the accessible markup. Every chart had ARIA labels, a data table fallback, and keyboard-navigable data points. This eliminated the dependency approval problem and produced smaller, faster components than a general-purpose library would have.
Progressive data loading
Instead of blocking render on a full data fetch, the dashboard skeleton rendered immediately with loading states. Summary numbers appeared first, then charts filled in as data resolved. On a slow connection, analysts saw useful information within two seconds instead of waiting for a full page load.
Accessibility from the component API
Accessibility wasn't a pass at the end. The component API required accessible attributes as props. If a chart was rendered without a title and accessible description, the component threw a warning in development. Compliance was harder to skip than to include.
Outcome
- ▶Dashboards deployed and actively used by public health analysts during the period of highest operational demand.
- ▶Passed Section 508 compliance review with no findings.
- ▶Initial render time dropped significantly from the previous tooling on equivalent connections.
- ▶The SVG component pattern was adopted as the standard for subsequent data visualization work on the platform.
What This Reinforced
Accessible data visualization is engineering
ARIA on a chart isn't a tag. It requires understanding what a screen reader user actually needs from a dataset and building for that, which is a design problem before it's an implementation problem.
Progressive enhancement is a performance strategy
Building for the slowest connection in the room changes every architectural decision. The techniques that make a page usable with poor network conditions also make it faster for everyone else.
Constraint is useful
Not being able to reach for an off-the-shelf charting library forced decisions that produced smaller, more accessible components. The constraint wasn't just a limitation to work around.
Similar work on your radar?
Accessibility audits, data visualization, federal compliance, performance work. If any of this sounds like what you're dealing with, the contact form is the right next step.