TANOOKI STUDIOS

How I Work

Accessibility Is A Priority, Not An Afterthought

I’m putting this in writing because apparently I know myself.

Every app I release will include every accessibility option that makes sense for that app. Not “on the roadmap.” Not “coming in a future update,” the traditional software-industry spelling of “never.” Built, tested, and included before I get to call the app finished.

This is not a values statement. Values statements are what companies frame and hang in a lobby while the actual product autoplays a video at you.

This is more of a threat. Mostly toward myself.

I’m autistic. I’m not saying that for sympathy. I’m saying it because it is the reason this promise exists.

If you’re not autistic, here is the short version: using software can feel like getting into fifteen tiny arguments before breakfast.

A video starts playing by itself. An animation you cannot disable makes the settings screen feel like a boat. A notification sound was chosen because somebody thought it was fun. One gray rectangle is apparently a button, while the nearly identical gray rectangle beside it is apparently decorative. You make the text bigger, and the layout responds by hiding the thing you needed to read.

None of this is usually malicious. It is simply exhausting.

I have spent my entire life adapting to software. I’m not going to make people adapt to mine.

When developers hear “accessibility,” they often think of screen readers. They should. My apps work with them.

But accessibility is also not making me flinch.

It is letting me turn off motion. It is not playing sounds I never asked for. It is a dark mode someone actually designed instead of one produced by reversing the colors and hoping nobody has eyes. It is an app that does not require me to be functioning at 100 percent, because I am a human person and that percentage is frequently unavailable.

I want to be precise here because “fully accessible” gets stamped on plenty of things that are not.

I’m not interested in treating accessibility like a box-ticking exercise. A checklist can help you test an app. It cannot tell you what using that app feels like.

So I sit down with each one and ask a less comfortable question:

Who is going to have a bad time using this, and why?

The answer changes with every app. That is the entire point.

  • Transcribbler turns speech into text. It is an accessibility tool by definition. If a transcription app does not work with VoiceOver from beginning to end, that is not an oversight. That is performance art.
  • Chewsy is built around swiping through restaurants. Swiping is a gesture. Some people cannot perform gestures, cannot perform them reliably, or use a switch instead. So Chewsy has buttons. There are always buttons.
  • Kirby is email, which means people may spend hours inside it. Everything needs to work from a keyboard. Text needs to grow without the layout having a nervous breakdown. Contrast needs to be real, not “looked okay on my monitor at 2:00 p.m.”
  • SpoonBudget is for people working with a limited amount of energy. If the app for tracking your spoons costs you several spoons to operate, I have created an exceptionally stupid little machine.
  • Eat Safely In Florida contains thousands of health inspection results. A screen reader needs an actual table with actual headers, not forty divs in a trench coat trying to get into a spreadsheet.

Some of these apps have shipped. Some have not. The standard applies to all of them either way. Accessibility is not the nice extra I add if development goes unusually well and nobody sets anything on fire.

I’m one person. There is no accessibility department waiting for me to hand this off. There is only me, usually late at night, testing my own app with the screen curtain on and saying, “No. No. Absolutely not,” to a button I personally built six hours earlier.

It is more work.

It is also the work I mind least, because it is part of what makes an app worth shipping. Nobody in the history of software has ever complained that something was too easy to use.

Here is the rule: if someone cannot use one of my apps, it is not finished.

I do not care if it is already in the App Store. The App Store is not a magical ceremony that transforms unfinished software into finished software. It is still unfinished, and I would rather ship late than ship something rude.

If one of my apps fights you, tell me. Genuinely. If there is a control you cannot reach, contrast that technically exists but has chosen not to participate, motion you cannot disable, or a sound that needs to shut up, raise a ticket.

It comes directly to me because there is nobody else for it to come to. I will be annoyed at the person responsible, discover that person is me, and fix it.

And if you use assistive technology of any kind and want access to early builds, I would love to have you on the beta crew. You will find things I cannot, and I would much rather hear about them from you than meet them for the first time in a one-star review.

← All posts