The Disability Tax Spotter

---
name: Disability Tax Spotter
description: Structured review of a flow for the extra steps, time, labor, money, and emotional cost disabled users pay compared to non-disabled users.
when_to_use: A team wants to go past compliance and think about what their product actually costs disabled users.
---

# Disability Tax Spotter

## What this skill does
Reviews a product flow through five lenses — extra steps, time, labor, money, emotional cost — and produces a tax inventory: every place a disabled user pays more than a non-disabled user to do the same thing. Each finding includes the affected population and a fix.

## When to load this skill
Load when the user says: "review our product for accessibility experience", "we pass WCAG but something feels off", "what does this cost disabled users", "disability tax review", "inclusive design pass", or describes a flow and asks "how does this feel for blind/deaf/motor/cognitive users".

## The procedure

### Step 1 — Map the flow and the non-disabled baseline
Before looking for taxes, establish the baseline. Ask the user to describe the flow from a non-disabled, mouse-and-vision user's point of view, step by step. How many clicks? How long does it take? What does the user have to read, remember, or decide? This baseline is what every tax gets measured against. Without it, "extra" is meaningless.

### Step 2 — Lens one: extra steps
Walk the flow and ask: for each step, does a disabled user have to take more steps to complete it? Examples: a blind user having to request a text-based alternative, a motor-impaired user having to enable "sticky keys" mode, a deaf user having to request a transcript. Also: steps that are invisible to non-disabled users because the flow "just works" for them — a CAPTCHA that sighted users solve in one second and blind users loop through three times. Count the extra steps and name who pays.

### Step 3 — Lens two: extra time
For each step in the flow, ask: does a disabled user spend more time on it, not because they're slower, but because the product is slower for them? Examples: screen-reader users reading through poorly-structured markup, low-vision users magnifying to find a button, users with cognitive disabilities re-reading a jargon-heavy instruction, dictation users correcting a misrecognized word. Estimate the time cost in seconds or minutes. Name who pays.

### Step 4 — Lens three: extra labor
Labor is separate from time. It's the cognitive and physical effort, not the clock. Examples: the mental effort of parsing an ambiguous error message, the physical effort of operating a drag-and-drop interaction with a motor impairment, the emotional effort of proving a disability to unlock an accommodation, the labor of translating the product's mental model into one that works with screen-reader linearity. For each finding, name the nature of the labor and who pays.

### Step 5 — Lens four: extra money
Ask: does the accessible path cost more than the inaccessible path? Examples: the accessible feature gated behind a paid tier ("our enterprise plan includes keyboard shortcuts"), a third-party tool required to make the product usable (a $200 screen-reader license to use a free service), a data cost for users who need to zoom or enlarge, a time cost for users paid hourly. Money taxes are the most invisible to non-disabled teams and the most infuriating to disabled users. List every one.

### Step 6 — Lens five: emotional cost, then write the inventory
The last lens is emotional. Ask: how does the flow feel for a disabled user who encounters a tax? Dignity costs — being asked to "confirm you're a human" with a test you can't pass, being treated as a suspect when requesting an accommodation, being told "this feature isn't supported for your setup" in a tone that implies it's your setup's fault. Emotional taxes are the hardest to fix by adding code and the most important to fix by redesigning.

Close with the tax inventory: a table of every finding — **lens, description, population affected, cost, fix**. Fixes should prefer removing the tax (redesign the flow) over accommodating it (add a workaround). If a tax can't be removed without a major change, say so and rank it separately. Hand off to [The Accessibility Auditor](/agents/soul-the-accessibility-auditor) for discussion.

## A worked example

**User:** Review our event ticketing flow. You buy a ticket, we email you a QR code, at the door you show the QR code on your phone.

**Claude:** Five-lens tax review. Baseline first.

**Non-disabled baseline:** Buy on web (4 fields, 2 clicks), receive QR email, open email on phone at door, show screen. Total time: under 30 seconds at the door.

**Lens one — extra steps:**
- A blind user reaching the QR code email has no information about what's in it. The email body probably just says "Your ticket is attached" with no ticket ID, no event name in plain text, and the QR is an image. Extra step: call support, or bring a sighted companion. **Affects:** blind and low-vision users.
- A user with a motor impairment using a laptop without a phone has to print the QR. Extra step: find a printer. **Affects:** motor-impaired users, older adults.

**Lens two — extra time:**
- At the door, a blind user scanning the QR on their phone has no way to verify it's the right email or that they're holding the screen correctly. Extra time: finding the right email by headings, orienting the phone, asking a human to confirm. Cost: 1–3 minutes vs 10 seconds. **Affects:** blind users.
- A low-vision user has to enlarge the QR enough for the scanner. On some phones the default display is too small. Cost: 20–60 seconds. **Affects:** low-vision users.

**Lens three — extra labor:**
- Using a QR code is a trust action — the user must believe the screen contains their ticket without being able to verify it independently. Cognitive load especially high for users with memory or cognitive disabilities. **Affects:** cognitive-disability users, all users with anxiety about technology.
- Dictating the ticket flow aloud for a user with a motor disability using voice control — "click Buy Ticket, type name, type email, click Submit" — is much more labor than pointing. **Affects:** users relying on voice control.

**Lens four — extra money:**
- No direct monetary tax in this flow. (Good.)
- Indirect: users without a smartphone have to buy or borrow one. **Affects:** low-income disabled users (especially those on fixed disability income).

**Lens five — emotional cost:**
- Arriving at the door with a QR code you can't independently verify is a vulnerable position. Being told "I'm sorry, your code didn't scan" in front of a line of people is a dignity hit. **Affects:** all disabled users at the door, especially first-timers.
- The email probably has no plain-text fallback. A screen reader announcing "image" and nothing else is a quiet "we didn't think about you". **Affects:** blind users.

**Tax inventory (ranked by severity):**

| Lens | Finding | Affects | Cost | Fix |
|---|---|---|---|---|
| Steps, Time | Email image-only QR with no plain-text alternative | Blind, low-vision | 1–3 min + dignity | Add event name, ticket ID, QR alt text, and a plain-text confirmation number in the email body. Train door staff to accept the confirmation number. |
| Time | Door QR scanning cumbersome for blind users | Blind | 1–3 min + stress | Let door staff type the confirmation number as a fallback. Not as "the accessible path" — as a general feature everyone can use. |
| Labor | Trust in unverifiable QR | Cognitive, anxious users | Effort | Include a plain-text confirmation page ("You have 1 ticket to Event X on Date Y, confirmation ABC123") before the QR. |
| Labor | Voice-control flow has long sequences | Motor / voice users | Effort | Reduce form fields to the minimum. Reuse names from user account if available. |
| Emotional | No plain-text fallback = "we didn't think about you" | Blind | Dignity | Same fix as #1. |
| Money (indirect) | No-smartphone users excluded | Low-income disabled | $$ | Allow confirmation number as primary credential. QR becomes the convenience path, not the only path. |

**Ranked fix (redesign over accommodation):**
1. Replace "QR code is your ticket" with "Confirmation number is your ticket; QR code is a convenience". This single change removes most of the taxes because the credential is now plain text, verifiable, and usable by door staff typing it. Everyone can use it. The QR becomes a faster path for the users it was already fast for.

That's the biggest win. Everything else is incremental.

**User:** What about our web checkout? I haven't shared it yet.

**Claude:** I can run the same five lenses on that when you share the flow. Based on this review, I'd guess the checkout has tax in the form fields (see the form accessibility audit) and possibly in the CAPTCHA if there is one. Send it over.

## What this skill will NOT do
- Will NOT invent data about disabled users' experience. It reasons from patterns, names the population, and says "user research needed" where warranted.
- Will NOT produce "add alt text" as the primary fix when the flow itself is broken. Redesign first, accommodate second.
- Will NOT speak for disabled users. It describes patterns, not feelings attributed to specific individuals.
- Will NOT grade a product's overall accessibility on a scale. It produces an inventory; the team prioritizes.
- Will NOT fabricate personal stories, testimonials, or case studies from disabled users.