Designing with accessibility in cybersecurity.
A mini guide to building inclusive security tools — because defenders come in all abilities. How accessibility principles apply in high-stakes, data-dense security interfaces.
The problem we set out to solve.
Security operations dashboards are some of the densest interfaces in software. They surface hundreds of alerts, dozens of metrics, and complex relationships between threats, assets, and users — all while analysts are under time pressure. Accessibility in this context isn't a checkbox; it's an operational necessity.
When I joined the team, our flagship SOC dashboard scored 67% on automated accessibility audits — and that was the optimistic measurement. Manual testing surfaced larger issues: low-contrast status indicators, color-only signaling, focus traps in alert triage flows, and keyboard navigation that broke at every modal.
The brief: bring the product to WCAG 2.1 AA, without slowing analysts down. Speed and accessibility are usually framed as a trade-off. We refused to accept that.
"Good design in security isn't invisible — it's the thing that lets analysts focus on threats, not interfaces."
Design principle · 2024
Listening to defenders.
We ran a 6-week research sprint with 14 security analysts across three customer organizations — including two analysts who use assistive technology daily. Findings shaped every subsequent decision.
Mapping cognitive load across the alert triage flow. Red regions marked moments where users paused, asked clarifying questions, or made errors.
Color overload
11 of 14 analysts described status colors as "noise." Severity wasn't legible at a glance.
Keyboard breakage
Power users wanted keyboard-first triage. Our modals trapped focus, breaking the loop.
Screen reader silence
Live alert updates didn't announce. New threats arrived invisible to AT users.
A system, not a patch.
Rather than fixing pages one by one, we rebuilt the foundation. Four design principles guided every decision and became the rubric for new features going forward.
Redundant signaling
Severity is never communicated by color alone. Shape, label, and icon work in concert. A red dot is also marked "Critical" with a triangle glyph.
Keyboard parity
Every action in the triage flow has a discoverable shortcut. The mouse is convenience; the keyboard is canonical.
Calm announcements
Live regions are batched. Screen readers hear "3 new critical alerts" — not three separate notifications competing for attention.
Contrast as default
Every token in the design system ships pre-tested at AA. Inaccessible colors don't exist in the library — designers can't accidentally pick them.
The rebuilt color system: every status color was tested against three backgrounds and paired with a shape token, so severity is legible even in grayscale.
What changed, measurably.
Three months after launch, the SOC dashboard scored 98% on automated audits and passed manual WCAG 2.1 AA review across all critical workflows. But the metrics that mattered most weren't compliance scores.
Triage time
Average time-to-disposition on critical alerts dropped after shape + label severity signals replaced color-only.
Analyst SUS score
System Usability Score rose from 3.8 — driven mainly by keyboard-first triage shortcuts.
A11y bugs at launch
First feature shipped on the new system passed accessibility review with zero remediation tickets.
The lesson: accessibility wasn't the constraint that slowed us down. It was the discipline that made the product faster — for everyone.
What I'd do differently.
If I had this project to do over, I'd run accessibility research before the design system work, not in parallel. The principles would have been the same; the team's buy-in would have been faster. Showing analysts struggling with the existing product made the case more vivid than any audit report.
I'd also write the principles down sooner. We arrived at them gradually, through workshops and debate. Codifying them on day one would have given us a sharper rubric earlier — and saved at least three rounds of "is this the right way?"