Who was not in the room when the data was designed?

The requirement sounds harmless when it arrives: report on outcomes for students with disabilities. A team picks it up and does the sensible thing, which is to go and talk to the people who commission the reports.

Those are administrators, compliance officers and state agencies. They're legitimate stakeholders and their needs are real.

The people the data is about aren't on that list, because none of the documents say the tool is "for" them. So the interface gets built for a sighted analyst with a large monitor and a mouse.

Nobody ever checks whether a blind educator, a parent using a screen reader or a disabled student can open it. Every step was reasonable, and we still end up with a system that describes people who can't read it.

I find that easy to describe and hard to look at directly. It isn't rare, either. In public-sector reporting it's close to the default, and once I'd seen it I started seeing it everywhere.

We both believe UX professionals do not intentionally exclude people from their work. So when nobody intends it, exclusion has to come from somewhere duller, like a room, a list of stakeholders and an assumption about who's going to use the thing.

We built the IDEA data reporting work at the Rhonda Weiss Center with around eighty stakeholders.

That number included disabled people. They're the people the data is about, and they had rarely been in the room when these tools were designed.

It did produce a more accessible product, but that isn't what struck me. What struck me was what they asked about, which was consistently different from what anyone else asked about.

Data visualization is the sharpest example. Our standard forms (infographics, maps, charts) inherently favor sighted readers with above-average literacy. Put the people who can't read a chart in the room and the question changes.

We stop asking "how do we add alt text to this chart." We start asking "what is this chart for, and what is the shortest way to that meaning for someone who is not looking at it?"

The first question gets us a chart with a sentence attached. The second gets us a table, a summary or a sorted list, and those are often better for everyone.

Microsoft's inclusive design work describes that pattern as solve for one, extend to many.

Is consulting people enough, then? No, and this is where I'd push our field hardest. When we consult people at the end, we're asking for a review. When we consult them at the start, they're part of the design.

What matters is whether the person can still change the shape of the thing, or can only tell us what's wrong with a shape we've already decided.

If eighty stakeholders had reviewed a finished system, we'd have had a long list of defects and a budget argument.

Because they shaped it, we got different questions early, while they were still cheap to change. (That early stage is the only moment when accessibility is inexpensive.)

So on the next project I'd write the group the data is about into the stakeholder list, whatever the brief says, and I'd pay them. Participation is work, and unpaid consultation selects for people with spare time.

I'd ask "who is not here?" at kickoff, out loud, because it gets much harder to ask once the wireframes exist. And I'd test with assistive technology before the design is approved, since a finding at launch goes into a backlog.

The charts get the same treatment. If a sentence conveys the single fact a chart exists for, lead with the sentence, and write alt text that narrates. "Bar chart of outcomes" tells a listener nothing.

"Reading proficiency rose from 34% to 41% between 2019 and 2023, with the largest gain among students with IEPs" tells them what the chart is for.

Look at what you're building this quarter and ask who it describes. If the answer is a group of people, ask whether any of them can use it.

If they can't, let's get them in the room while the thing can still change.