A mobile application that eliminates the cognitive labor of writing accommodation requests — generating personalized, context-aware messages from four structured questions. Built with a blind co-designer. Tested with real assistive technology.
The invisible labor disabled people perform just to participate — before the meeting even begins.
Before nearly every meeting, workshop, or conference she attends, our collaborator Mary must write a personalized accommodation request. From scratch. Every time.
She described herself, unprompted, as "a broken record." This is what access computing scholars call the time tax — the invisible labor disabled people perform just to participate in environments not designed for them.
The problem, as Mary articulated it, isn't just repetition. It's the emotional and cognitive weight of having to repeatedly explain your needs, justify your presence, and hope the person on the receiving end actually acts on what you've asked for.
Fast. But impersonal — and impersonal requests get deprioritized. You save seconds while undermining the effectiveness of the very thing you're asking for.
Authentic and effective. But cognitively expensive, emotionally draining, and repeated before every event — regardless of how many times you've written something nearly identical.
Mary named this problem herself — unprompted — and then immediately questioned whether any tool could actually solve it. That question contained the entire design brief: can a tool produce genuinely personal output from structured input?
Co-design means the collaborator reshapes the brief — not just the button labels.
Mary is a domain expert. Six years of applied accessibility experience, professional screen reader certification, and contributions to JAWS and NVDA. We approached her accordingly.
Treating her as a traditional research participant would have meant validating our assumptions. Treating her as a co-designer meant her feedback could — and did — fundamentally reshape our understanding of what we were building. That happened twice.
After the first iteration critique, we faced a real constraint: any prototype intended for evaluation by a blind collaborator must be addressable by her assistive technology. A Figma prototype renders as a flat raster image. VoiceOver announces it as an unlabeled graphic. Evaluation would be theater.
We built a live React application instead. Not as a workaround — as a methodological commitment. This moved accessibility from a property we hoped the design had, to a property we could directly measure. It added significant complexity. It was completely the right call.
"I honestly think it probably would have been an equal amount of time — but where your prototype is helpful is that it lessens the cognitive load."Mary Stones — collaborator evaluation session, post-task interview
We had built a time-saving tool. Mary told us we'd built a decision fatigue reducer. The tool supplies a structured menu of accommodations that a user might otherwise have to recall under self-advocacy pressure — in a moment that is already emotionally demanding.
The value is mental, not temporal. This reframe changed the north star metric, the product strategy, and what "success" means. It would have changed the design too — if we'd understood it from the start.
The best design decisions are made with full awareness of what you're giving up. Each of these shaped the project's direction — and required the team to confront an assumption we hadn't examined.
Live React application, deployed to GitHub Pages. Usable with any screen reader, on real device hardware, with no setup required from the evaluator.
Figma prototype. Renders as a flat raster image. VoiceOver announces it as an unlabeled graphic. Any "evaluation" would be simulation, not research.
This was the move that separated our project. Accessibility cannot be evaluated in Figma. The medium is both the message and the method — and they have to match.
No pre-selected options on any radio group. Users make every choice explicitly. Recommended defaults preserved only on accommodation checkboxes, where they reduce burden without overriding a categorical decision.
Pre-selected "most likely" options (virtual, Zoom, first-time presenter). Felt like good UX. But screen readers announce the pre-selected state as "selected" — users hear a decision they never made.
This is a visual UX pattern that breaks for screen reader users. What sighted designers call a helpful default is an accessibility antipattern. The critique gave us language; the implementation gave us proof.
"I use screen reading software that reads information on the screen aloud." Describes the access need. Preserves user agency over disclosure. Name-specific AT is opt-in, unchecked by default.
"I use a screen reader called JAWS." Discloses both the disability category and a specific AT brand — as the default, for every user, in every generated message, without their consent.
Mary's accessibility office never names disabilities in accommodation requests. Some disabled people refuse to request accommodations rather than disclose. Disclosure is political. We had made that decision on behalf of every user without realizing it.
Every finding below revealed a design assumption we hadn't examined. Each became a code-level change in the final prototype.
The generated message opened with "I use a screen reader called JAWS" — disclosing both disability category and a specific AT brand. Mary's professional practice, developed over years advising others on accommodation language, is to focus on the access need. Some disabled people refuse to request accommodations at all rather than disclose. We had made an irreversible disclosure decision on behalf of every user.
The no-data-saved privacy notice was at the bottom of the welcome screen. Mary: "Disability disclosure is a high-trust action." Trust must be established before you ask for the cognitive and emotional commitment — not offered as a footnote after the fact. Moved to the top; now the first thing a user sees after the heading.
One of the most common accessibility gaps in meetings — videos shown without audio description — wasn't in our accommodation list at all. This wasn't an oversight in implementation. It was an oversight in our understanding of the problem space. A new checkbox and corresponding message language were added.
Recurring meetings with familiar colleagues don't require an accommodation request — those people already know your needs. The option created a false use case. Renamed to "Work meeting at a new organization," communicating the scope constraint at the exact moment of selection.
Recipients frequently interpret this as permission to send any PDF. Mary: they "often don't understand what accessible means." Changed to "Send accessible materials in advance" with helper text specifying "text with image descriptions, or Braille if available." Specificity generates compliance.
Mary missed the edit button entirely on her first pass. A message that appears visually as a passive display doesn't communicate its editability — especially when navigating by element type. Helper text now explicitly names the control: "Use the Edit Message button if you want to change anything before copying."
It's easy to describe design changes in the abstract. These are the concrete before-and-after pairs that show what changed at the language level — and exactly why each one matters.
"I use a screen reader called JAWS."
Names both a disability category and a specific brand — for every user, in every message, without their input. Disclosure without consent.
"I use screen reading software that reads information on the screen aloud."
Describes the access need. Preserves user agency. AT brand is opt-in — a toggle that regenerates the message immediately when checked.
"Send materials in advance."
Vague enough that recipients interpret it however they like — frequently sending inaccessible PDFs and considering the request fulfilled.
"Send accessible materials in advance — text with image descriptions, or Braille if available."
Specific enough to generate the behavior being requested. Accessibility only works when recipients understand what it requires of them.
"Work meeting"
Includes recurring meetings with familiar colleagues — situations where this tool adds no value and shouldn't be used.
"Work meeting at a new organization"
Narrows to the actual use case. Communicates when to reach for the tool — and implicitly, when not to.
What the prototype proves — and what the strongest version of this product actually is.
The deployed prototype is feature-complete for this project's scope. But "feature-complete" isn't the right success metric. What it proves is more specific.
It proves that a small, well-designed input form can produce a personalized accommodation request that reduces cognitive load — without sacrificing the authenticity that makes the message work. It also proves something methodological: accessibility can only be meaningfully evaluated with real assistive technology, in real conditions, by someone who controls their own setup.
The strongest deployment context — identified independently by Mary, the faculty, and the in-class critique — is a widget embedded in conference registration forms, where users currently face a blank text box and no guidance on what to request. AccessDraft slots into precisely that moment: supplying the structured prompts and the warm, personalized draft.
Mary described this exact experience from a leadership conference she'd recently registered for. When three independent sources converge on the same product vision, that's a signal worth acting on.
This isn't a list of excuses. It's an honest account of where the model was wrong — and what a stronger version of this project looks like with more time and less deference to our own assumptions.
A React application — not a prototype — evaluated with VoiceOver on real iPhone hardware, by someone who trains others on screen readers professionally.