The Hidden Accessibility Problem in Every Data-Heavy Dashboard

Nielsen Norman Group published a piece recently on neuroinclusive design — designing around the executive-function, communication, and sensory challenges neurodivergent users face. Their core argument: simplicity, clarity, control, support, and co-creation help everyone, not just the population they were designed for. I recognized that list immediately, from a different door — it's close to how I've approached cognitive load on data-heavy dashboards for years, before I had a name for it.

‍

Most accessibility work I see stops at a specific checklist: screen reader compatibility, keyboard navigation, color contrast, alt text. All necessary. None of it optional. And all of it built to clear one bar — a legal or ethical one. What it doesn't touch is a much bigger failure mode: a product that's technically compliant and still exhausting to use, because it hands the user forty data points and expects them to work out which three matter.

That's not a compliance failure. It's a design failure, and it hits neurodivergent users hardest while quietly costing everyone else too. A user managing executive-function challenges has a harder time filtering signal from noise. A user without those challenges just gets tired faster and starts missing things. Same interface, same root cause, different severity.

‍

What this looks like on a real product

I've designed for a B2B vendor intelligence platform where the backend already tracked a wide range of signal types for each brand: site visits, social presence, sales movement, product launches. The obvious version of this feature is a single notification feed, newest first, and let the user scroll through it.

I didn't build that. Two user types drive this product: depth-first investors tracking a small, focused portfolio of brands, and breadth-first merchants and sales brokers managing large catalogs. A single mixed feed serves neither well — the investor drowns in noise from brands they don't hold, and the merchant can't tell a genuinely urgent signal from routine activity across hundreds of listings.

I separated monitoring alerts from general notifications into distinct architecture entirely, with each signal type carrying its own visual treatment tied to what it actually means for that user's decision. The goal wasn't more UI. It was removing the step where the user has to do triage the system already had enough information to do for them.

‍

Urgency is a variable, not a binary

On Elicejus, an AI-powered math platform used by tens of thousands of students and hundreds of teachers across Lithuania, part of my work involved a badge system showing students the status of assignment tests. The naive version is binary: done or not done, on time or late. Easy to build, genuinely unhelpful — a student with six hours left and a student with six days left are facing completely different situations, and a flat badge treats them identically.

I designed a six-state badge lifecycle instead, with urgency calculated proportionally to the size of the student's actual assignment window, capped so it never turned alarmist for a long-running assignment. A tight deadline reads urgent. A distant one doesn't shout at the same volume just because the system defaults to shouting. That distinction sounds small in a spec document. In practice, it's the difference between a badge a student can trust and one they learn to ignore because it's always red.

This is the same principle NN/g's piece points at, applied somewhere it doesn't usually get discussed: urgency and priority aren't things a system should broadcast at a single flat volume. Doing that isn't neutral. It's harder on anyone who struggles to filter constant high-signal noise, and it trains everyone else to tune the system out too.

‍

Even the empty state is a cognitive load decision

The smallest example I can point to is also the easiest to overlook. On a trends platform I designed alongside the vendor intelligence work above, the team was debating what to do when a user's search returns nothing. The instinct was to add a prominent search button and a generic no-results message.

I recommended removing the search button entirely, adding fuzzy partial-match suggestions as the user types, and building a real no-match empty state: curated fallback suggestions plus an AI Search option positioned as an escape hatch, not the default way to interact with the feature. The reasoning was the same one running through the rest of this piece: don't ask the user to do work — typing a full query, parsing a blank result, deciding what to try next — that the interface could have done for them by anticipating the miss before it happened.

‍

What this means if you're building a data-heavy product

None of this requires a neurodivergence-specific research program to act on. It requires treating cognitive load as a first-class design constraint, on the same level as accessibility compliance, not a soft nice-to-have that gets cut when the timeline tightens.

A few questions worth asking on any dense or data-heavy screen. Is the system asking the user to manually sort or prioritize information it already has enough context to sort itself? Does every alert or badge carry the same visual weight regardless of actual urgency, training people to ignore all of them equally? And when something goes wrong or comes back empty, does the interface hand the user a blank page, or does it anticipate the miss and offer a next step?

I don't think of this as an accessibility feature bolted onto a dashboard. On the kind of dense, data-heavy products I design for, it's most of the actual design job — and it happens to be the same job that makes a product genuinely usable for people managing executive-function challenges, not as a separate initiative, but as a side effect of doing the core work properly.

‍

Gytis Markevičius
Founder, GytisMark Studio — gytismark.com