Cognitive Accessibility First: How I Built AbleMakers

AI gave more people access to tools I use every day. I wanted people with Down syndrome and other intellectual disabilities to have that opportunity too, with clear steps, support when they want it, and work they can call their own.

That is why I built AbleMakers.

The unit of progress is a useful thing the learner makes, not time spent clicking through a lesson. The learner keeps the ideas, the choices, and the credit.

This is how I built it.

The initial AbleMakers build took about two and a half days. I kept the scope focused: a six-module curriculum, optional progress sync, generated read-aloud audio, certificates, and an adventure map. Tests made those implementation decisions reviewable, but did not prove the lessons were effective.

That describes the initial build, not evidence of learning outcomes. The fast part was implementation. Understanding where real learners need more support is ongoing work, and it matters more than the release stopwatch.

The original AbleMakers design doc planned a serious stack: Clerk for auth, Neon Postgres with Drizzle for the database, Sanity as a CMS for the quests, a live AI buddy on an AI gateway, and Mux for video. Almost none of it shipped.

It was a good plan for a funded startup. Here is what replaced it, and why.

Two of those swaps are instincts I keep landing on elsewhere. Serving quests through a CMS-shaped interface with no CMS behind it is the same shape-first bet as ResolveMesh, which launched with a deliberately empty catalog. And refusing to let a model improvise at the learner is the same call I made when I would not let AI write the itinerary in Ember Coast.

The lesson I keep relearning: the right architecture for a mission is the one that removes surprises, not the one that shows off.

Cognitive accessibility shapes AbleMakers' navigation, language, pacing, and recovery paths. W3C's supplemental guidance offers patterns beyond WCAG conformance, not a separate certification. I translate relevant patterns into product constraints and automated checks, then treat usability as a question those checks cannot answer alone.

CI can catch long sentences. Only a learner can show me whether the instruction actually makes sense.

These are design choices informed by accessibility guidance, not evidence that everyone in a diverse audience has the same needs. When the person on the other side is under stress or already under-served, interface friction stops being cosmetic and becomes the product itself, which is the same argument I made building DateSafe, where a visible loading state can undermine a duress flow.

AbleMakers generates every spoken line at build time instead of calling a text-to-speech API while a learner is using the app. A script walks the entire curriculum, renders one MP3 per spoken string in three voices, and commits the audio next to a manifest.

Learners see those voices as "Sunny," "Cozy," and "Storyteller." The filename is a hash of the voice and the text, so re-running only pays for strings that actually changed, and the OpenAI key is read by that one script and never touches the deployed app. The deployed player does not need a text-to-speech API key or a per-play generation request. If the audio ever fails, the browser's built-in speech takes over automatically.

Pushing the expensive work to build time and leaving the runtime dumb is the same pattern behind the mostly-automated newsroom I built for ViralVault.

Warm voices, one-time cost, no runtime secrets. That is the kind of trade I love.

The most important quest in AbleMakers teaches that the AI is sometimes wrong, and it does it by staging the failure. In the scripted practice chat, the assistant confidently says "Spiders have six legs."

The next step tells the learner: the AI said six, spiders really have eight, ask it again. The learner types "Are you sure? Please check again," and the AI replies, "Good catch. I was wrong." The quest ends with a line I think about a lot: "You are smarter than a mistake."

That one interaction is the entire philosophy. Give the learner practice questioning a confident answer, and make correction feel like progress rather than failure.

An early review found a more practical problem: the introduction promised a path that ended at a "quests are being built" notice. I needed to finish the next useful step before adding more polish to the first one. That is a product lesson I can test by following the same path a learner sees.

The Make and Sell module in AbleMakers is built on a study of fifteen real businesses run by people with intellectual disabilities, from John's Crazy Socks to Collette's Cookies. I refused to write those quests on assumptions, because getting them wrong could genuinely hurt someone.

Three rules came out of that research and shaped the whole module:

• The co-pilot model. Every step that touches money, accounts, or strangers explicitly says: do this part with a person you trust. The learner owns the product, the making, and the story. A trusted person helps with the risky edges.
• Never state benefits numbers. The disability benefits cliff is real and the numbers change yearly, so the curriculum always routes families to a free benefits counselor instead of quoting figures that could cause real harm.
• Scams are a designed-for risk. Ending a course with "now put your product on the internet" without a trusted-person checkpoint is creating exposure, so the online-shop quest sits last, behind a family gate, with a dedicated safety lesson before it.

The useful standard is a real outcome, not an inspiring story. A learner should finish with something they chose to make, and a clear, supported next step if they want to take it further.

AbleMakers is live, free for learners, and has grown from the initial curriculum into eight lands on the Maker Path, covering first AI conversations, creative projects, everyday tasks, and work. Guided practice comes before the handoff to a real AI tool.

It is not a registered nonprofit yet, so I say so plainly on every page that touches money: gifts are not tax-deductible, and until it has its own legal entity, this is my personal commitment, not a charity's. The 501(c)(3) is a decision for when donations are flowing steadily.

The next useful question is whether the practice transfers: can a learner repeat the skill in another tool with the support they choose? More features are only worthwhile when they help answer that.

Try a practice or explore the family and facilitator resources. The outcome I care about is one maker finishing something they wanted to make, with their name on it.