Who was not in the room when the data was designed?
We built a reporting tool about disabled students that disabled people could not open, and nobody involved did anything wrong.
I keep running into a kind of failure that is easy to describe and hard to look at directly: a tool that holds information about a group of people and cannot be used by them.
It is not rare. It is close to the default in public-sector reporting, and once I had seen it I started seeing it everywhere.
How does a dataset end up excluding its own subjects?
Not through anyone's decision. Through a sequence of reasonable ones.
A requirement arrives: report on outcomes for students with disabilities. A team builds the reporting. The stakeholders consulted are the people who commission the reports: administrators, compliance officers, state agencies. They are legitimate stakeholders and their needs are real.
The people the data is about are not in that list, because the tool is not "for" them in any of the documents. So the interface gets built for a sighted analyst with a large monitor and a mouse, and nobody ever checks whether a blind educator, a parent using a screen reader, or a disabled student can open it.
Each step is reasonable. The outcome is a system that describes people who cannot read it.
We both believe UX professionals do not intentionally exclude people from their work. This is what exclusion looks like when nobody intends it: a room, a list of stakeholders, and an assumption about who is going to use the thing.
What changes when they are actually in the room?
We built the IDEA data reporting work at the Rhonda Weiss Center with around eighty stakeholders. That number included people with disabilities: the people the data is about, who had rarely been in the room when these tools were designed.
What struck me is not that it produced a more accessible product, though it did. It is what they asked about, which was consistently not 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. When the people who cannot read a chart are in the room, the question changes. It stops being "how do we add alt text to this chart." It becomes "what is this chart for, and what is the shortest way to that meaning for someone who is not looking at it?"
Those produce different products. The first produces a chart with a sentence attached. The second produces a table, a summary, a sorted list, often better for everyone, which is the pattern Microsoft's inclusive design work describes as solve for one, extend to many.
Is consultation enough?
No, and this is where I would push our field hardest.
Consultation at the end is a review. Consultation at the start is design. The difference is whether the person can still change the shape of the thing, or can only tell you what is wrong with a shape already decided.
Eighty stakeholders reviewing a finished system would have produced a long list of defects and a budget argument. Eighty stakeholders shaping it produced different questions early, while they were still cheap to change, which is the only moment accessibility is inexpensive.
What can we do on the next project?
- Write the excluded group into the stakeholder list explicitly. If the data is about a group, that group is a user of the tool, whatever the brief says.
- Pay them. Participation is work. Unpaid consultation selects for people with spare time, which is its own exclusion.
- Ask "who is not here?" at kickoff, out loud. It is a short question and it is much harder to ask once the wireframes exist.
- Check the chart against its own purpose. What is the single fact this visualization exists to convey? If a sentence conveys it, lead with the sentence.
- Test with assistive technology before the design is approved, not before launch. A finding at approval changes a design. A finding at launch changes a backlog.
- Alt text narrates, never labels. "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 the thing the chart is for.
The question underneath all of it
Our defaults encode an assumption about who is in the room. Usually: someone who works the way we do.
The correction is not a checklist. It is a habit of asking whose voice is missing before the shape of the thing is settled, and then doing the harder work of getting that voice into a position where it can still change something.
Look at what you are building this quarter and ask who it describes. If the answer is a group of people, ask whether any of them can use it. Let's stop building tools that talk about people behind their backs.