Let People Build Their Own AAC Tools: Inside "Do-It-Yourself AAC" 💪🔨👷♂️
Most AI-powered AAC research so far has followed the same basic shape: researchers build a tool, hand it to people with communication disabilities, and see what they think. A new CHI '26 paper out of the University of Maryland flips that model entirely. Instead of asking "does our AI tool help you?" it asks a more radical question: "can we give you the raw AI building blocks and let you build your own?"
The paper — Do-It-Yourself AAC: Co-Designing User-Programmable AI Communication Tools with People with Aphasia, by Jong Ho Lee and Stephanie Valencia — tackles a problem that's been quietly underneath almost every AAC story we've covered this year: generic tools built for the average user tend to miss the specific user. Aphasia, a language disorder that affects roughly two million people in the U.S. alone, is a condition where "the average user" barely exists — severity, symptoms, and communication needs vary enormously from person to person. AAC technology, the researchers argue, is often difficult to customize and can overlook exactly the personal needs that matter most.
Their proposed fix borrows an idea from software development rather than speech-language pathology: end-user programming — giving the person who needs the tool the ability to build and modify it themselves, rather than waiting for a developer to anticipate their needs.
The study: two parts, eight participants, and a box of physical blocks
The researchers ran a two-part study with eight participants with aphasia.
Part one was a card-sorting exercise. Participants were given cards representing different AI functions and asked to sort them by how useful each would be for a conversation scenario they picked themselves. One clear signal came out immediately: participants consistently valued AI's ability to predict words and full sentences from brief or incomplete input — in other words, the AI's job was to fill in the gaps that aphasia creates, not to replace the person's intent.
Part two is where the paper gets genuinely novel. In in-person co-design workshops, participants built hypothetical communication tools using tangible, physical code blocks — not software, actual objects they could pick up, connect, and rearrange. Each block represented a single AI function or data operation, and its physical shape told you something about it: a triangular edge meant the block handled text, a square edge meant it handled images, and green blocks marked the end of a program. Participants snapped these blocks together into little programs matched to real communication situations from their own lives.
The reasoning behind this design choice is the heart of the paper: formulating a request in natural language — the normal way you'd ask a developer for a feature, or type a prompt into an AI chatbot — can itself be a barrier for someone with aphasia. Tangible blocks sidestepped that barrier entirely. Instead of describing what they wanted in words, participants could show it, piece by piece.
What happened when people with aphasia got to build their own tools
The results were encouraging on the central question: every participant who took part in the workshops was able to successfully assemble multiple working hypothetical programs. They could correctly identify what kind of data a block took in and put out, and combine blocks into sequences that matched their intended scenario. A few participants needed time to get comfortable with the mechanics at first — but all of them got there.
What's most striking isn't just that it worked, but how it worked. The researchers observed that manipulating physical blocks gave participants a concrete, shareable way to express ideas about what an AAC system should actually do for them — something that's historically very hard to extract through a standard interview when verbal and text-based communication is itself the thing that's impaired. The blocks became a kind of common language between participant and researcher that didn't depend on fluent speech or writing to work.
There's a second, subtler finding worth sitting with: the same block, given to different participants, got used in different ways depending on their personal communication needs. That's not a bug in the system — it's the entire point. A rigid, one-size-fits-all AAC tool can't flex to that kind of individual variation. A small set of composable building blocks, it turns out, can.
The trade-off the researchers are honest about
This paper doesn't oversell what tangible block programming can do. The researchers are explicit that constraining the system to a limited set of pre-defined blocks and data types necessarily limits what participants can express — you can only build what the available pieces allow. But they frame this as a deliberate trade-off rather than a flaw: that same constraint is what keeps the cognitive load low enough for people with aphasia to actually use the system without being overwhelmed by boundless options. In accessible design, less expressive power that's actually usable beats more expressive power that nobody can navigate.
The study also surfaced a broader pattern worth flagging for the whole AAC field: participants described needing flexible options in daily life badly enough that some of them were already using multiple apps — sometimes stretching an app well outside its intended purpose — just to cover their actual communication needs. That's a quiet indictment of how narrowly most AAC tools are scoped, and it's exactly the gap user-programmable tools are aimed at closing.
Why this matters beyond the prototype
The paper's contribution isn't really the specific block system — it's the demonstration that visual, tangible programming is a viable way for people with aphasia to directly shape their own AI-driven communication tools, without needing fluent natural language to do it. That has two layers of significance.
First, as a product direction: it points toward a future where AAC users aren't just consumers of whatever vocabulary set or AI feature a developer shipped, but active builders of tools tailored to their own lives — ordering coffee, talking to a doctor, chatting with a grandchild — using an interface that doesn't require the very skill their condition affects most.
Second, as a research method: the researchers note that physical blocks worked as well as they did specifically becausethey gave participants with aphasia an alternative channel to articulate needs that's independent of verbal or written communication. That's a methodological lesson other AAC and accessibility researchers can borrow, independent of whether anyone ever builds a commercial product from this exact system.
What's next
The authors are clear-eyed about the limits of an eight-person lab study: future work needs a larger, more diverse group of participants across different aphasia profiles and severities, further refinement of the physical blocks themselves, and — critically — testing outside the controlled workshop setting to see whether this holds up in the messiness of everyday computer-mediated communication. They also flag a genuinely open question for the field: how do you take an aphasia-friendly programming paradigm like this and actually deploy it inside real, everyday AAC systems, rather than leaving it as a research prototype?
That's the gap between a promising CHI paper and a shipped product — but it's a gap worth watching. If user-programmable AI tools make it out of the lab, they'd represent a genuine shift in who gets to decide what an AAC device does: not just the engineers who build it, but the person who has to rely on it every day.