The Disability Tax: What It Actually Costs to Live in a World That Doesn't Plan for You

A woman at a DMV kiosk in Sacramento spends eleven minutes filling out a form that takes most people ninety seconds. The kiosk is touch-only. Her hands shake. The buttons are small, and when she misses one the form resets to the beginning. On her fourth attempt, a clerk finally comes out from behind the counter to help. By the time she leaves with her license renewal, she has been at the DMV for three hours. Her appointment slot was twenty minutes.

Everyone she passes on the way out thinks she had a long day at the DMV.

What she actually had was a tax bill, paid in minutes, fatigue, and dignity. The DMV did not charge it. Nobody at the DMV thinks of themselves as charging it. But it was collected all the same, by the gap between how the kiosk was designed and how her hands actually work. That gap has a name in the disability community: the disability tax. It is the cost of living in a world that defaults to a body and a mind that aren't yours.

Designers are not the collectors of this tax. But every product decision we make either raises the rate or lowers it, and most of the time, we don't know which we've done until a user tells us, and most of the time, they don't bother telling us because telling us is also part of the tax.

This piece is an attempt to itemize the bill.

What the tax actually looks like

The disability tax is not one thing. It is a hundred small things, none of which individually would ruin a day, all of which collectively can cost an hour, or a job interview, or a night of sleep. A partial list, from things I have watched happen or heard described carefully enough to write down:

Time. Every form that doesn't autofill, every CAPTCHA that rejects screen readers, every multi-step flow that can't be paused, every session that times out while the user is still reading the first sentence — each of those adds minutes. The minutes compound. A user who takes twice as long as average to complete a task isn't doing twice as much work. They're doing the same work while losing time that nobody gives back.

Money. A screen reader user who can't use the self-checkout line waits for a cashier. That is time, but if it means missing a bus, it is also a fare. A wheelchair user who can't use the stairs-only side entrance takes the longer ADA-accessible route, which in a lot of cities means paying for parking they wouldn't otherwise need. An autistic job seeker whose reading of a job description gets "nice-to-have" confused for "must-have" doesn't apply to a job they could do, and so loses the salary they didn't know they were eligible for.

Energy. This one is harder to see and it is the biggest of the three. Spoonies — people managing chronic illness — talk about energy as a literal finite resource, because for them it is. Every product that makes you hunt for the unsubscribe link, every form that makes you retype your address three times, every error message that makes you guess what you did wrong — each one spends a spoon the user cannot get back. The product didn't mean to. The user still pays.

Attention. Cognitive accessibility is the layer the industry funds the least and the layer that benefits the most people. A page with five things happening at once, with auto-playing video, with inconsistent navigation, with jargon the user has to decode — that page is not illegal under any accessibility standard, but it is unusable for a huge number of people with ADHD, anxiety, dyslexia, cognitive fatigue, or just a hard week. Those users are not getting stupider at your product. Your product is getting louder at them.

Dignity. The least measurable cost and the one that drives the most users away. Forms that ask for a "Mr/Mrs" title. Identity fields that require you to pick a gender from a dropdown of two. Date-of-birth pickers that assume every user was born in the last eighty years. Error messages that tell the user they're "invalid." Every one of these sends a tiny, unmistakable signal: this product was not built for you. After enough signals, the user stops trying.

Why the tax is hard to see from the inside

I have been in product teams where accessibility bugs got filed, triaged, deprioritized, and eventually closed as "won't fix, low impact." I have also been in the rooms where those decisions got made. The people making them were not bad people. They were people looking at the metrics they had, which told them the thing they were about to not fix was affecting "less than 1% of users."

Here is the thing about "less than 1% of users." It is almost never less than 1% of users.

First, a huge number of disabled users do not self-identify in product surveys, because the products don't ask, or because asking feels risky, or because the user doesn't think of themselves as "disabled" (temporary disabilities, situational disabilities, undiagnosed disabilities, aging). Second, the users the product most affects are the ones who bounce before they show up in the funnel at all. They can't get past signup. They can't get past the CAPTCHA. They were never a user in the first place, so they are not in the 1% or the 99%. They are off the chart entirely.

Third, the metric is the wrong metric. The question is not "what percentage of my users does this affect?" The question is "what percentage of my users would never be my users if this weren't fixed?" Those are wildly different numbers, and the second one is the one that actually tells you whether a thing is worth fixing.

There is a tool, 🪙skill-the-disability-tax-spotter, that I want to mention here specifically because it tries to answer the second question. It walks a flow and flags every moment where the product is quietly charging users a disability tax — not the WCAG violations, which a hundred other tools will catch, but the subtler moments where the product works but makes users pay to use it. The "enter your address" field that doesn't accept accented characters. The session timeout that's calibrated for a user who can read at 300 words a minute. The multi-step flow that can't be resumed tomorrow. None of these are accessibility bugs in the legal sense. All of them are tax. The skill's job is to itemize them.

Where AI lowers the tax for users

The frame I want to push back on is the one where AI is the hero that "empowers disabled users," because that frame is patronizing and it is also the frame that ends up selling useless products to disabled people for twice the price.

The honest frame is narrower and more useful. AI, when it works, absorbs tedium. Tedium is a huge chunk of the disability tax. Therefore, AI lowers the tax — not by doing anything heroic, but by removing the slow parts of things that were slow because they were fiddly.

Some places I have actually seen this work:

Reading and summarization. A medical form, a dense government letter, a school newsletter in three languages at once. 👁️soul-the-low-vision-co-pilot is the kind of companion I'd keep on a phone for exactly this — point the camera, have the AI read and summarize, ask questions about the thing in plain language. It doesn't fix the document, but it translates the document into something the user can act on in minutes instead of hours. The document wrote the bill; the co-pilot pays it for them.

Energy management. Spoonies have been running their own energy-budgeting systems for decades, on paper, in spreadsheets, in memory. 🥄soul-the-spoonie-energy-coach is not a replacement for that system — a system that took years to calibrate to a specific body does not get replaced by a chatbot — but it can do the part that everyone hates, which is re-planning the day when the plan falls apart. "I'm out of spoons, I still have three things to do, what can wait till tomorrow?" is a conversation an AI can have usefully, in five seconds, at the exact moment the user does not have the energy to have it themselves.

Decoding things meant to exclude. Job descriptions are written in a dialect nobody actually speaks. 💼prompt-the-job-description-decoder takes a job posting and tells the applicant which phrases are real requirements, which are "nice-to-haves" dressed up as requirements, and which are industry code for "we don't want applicants who need accommodations." The applicant then knows whether to apply. The tax here is not the minutes — it's the spent hope of applying for jobs you were never really eligible for, over and over, until you stop applying.

None of these replace accommodations. None of them replace policy change. None of them replace designers doing the work. What they do is give disabled users some of their time back, tonight, while the slower fixes are still waiting.

Where AI lowers the tax for designers building better

This is the part most articles about "AI and accessibility" skip, because it sounds less inspiring. But it is the part that compounds.

The reason designers don't fix accessibility bugs isn't that they don't care. It's that fixing them is slow and thankless and interrupts the work. Every tool that makes those fixes faster is a tool that gets more of them fixed, full stop. A designer who can run a quick contrast check in ten seconds fixes contrast bugs. A designer who has to open a second tab, type a hex code into a separate site, read a ratio, interpret it against WCAG, and come back — that designer fixes the contrast bug sometimes, when they remember, when they're not tired.

“The tax the user pays is set by the friction the designer experiences. Lower the friction on the designer and you lower the tax on the user, without the user ever knowing why their day got a little easier.

This is not glamorous. It is also the single highest-leverage thing a team can do. Every minute a designer saves on accessibility busywork is a minute they can spend on an accessibility decision that a machine cannot make. That is the trade we want.

The itemized bill, unrounded

If I could put one thing on every product team's wall, it would be a running tally, updated weekly, of the time the product is costing its users above and beyond what it costs the average user. Not "accessibility bugs filed." The actual minutes and dollars, estimated from real flows.

Nobody does this. It is hard to calculate and it is uncomfortable to read. But imagine it existed. Imagine a dashboard next to your MRR and your DAU that said, in large friendly letters: This week, users with motor disabilities spent 14,000 extra minutes on our site because of the checkout flow. Users using screen readers spent 3,200 extra minutes because of the search results page. Users with cognitive disabilities abandoned signup 4.3x more often than average. Estimated untaxed time: 29,000 minutes.

You would fix things. Everyone would fix things. You wouldn't be able to look away.

Until that dashboard exists, the closest thing to it is a weekly walk through your own product with the tax in mind. Pick a flow. Ask 🔍The Accessibility Auditor to walk it with you. Ask it what it would cost a user who is tired, who has one working hand, who is using a screen reader, who is reading at an eighth-grade level, who can't see color. Write down the answers. Those are the lines on the bill.

Do this tonight

• Pick one flow in your product — the one with the most traffic.
• Run 🪙skill-the-disability-tax-spotter over it. Read the whole output, not just the summary.
• From that list, pick the one thing that is costing users the most time per attempt. Not the worst bug — the costliest one.
• Fix it this week.
• Next week, do it again.

A year of this is fifty-two flows, fifty-two costs removed, a product that quietly collects less tax than it used to. Nobody will write you a thank-you note. The woman at the DMV won't know your name. She'll just have her license forty minutes earlier, and her day will be a little less expensive, and the bill she didn't know she was paying will be smaller than it was last year.

That is the whole job.

Written by a-gnt Community for the a-gnt accessibility series.