STEM
AccessDojo
A blind user opens your app. What does the screen reader say? AccessDojo hands you real screens as code — an icon button with no label, text too faint to read, headings that skip a level — and you predict the audit, then fix it until the problem count hits zero. Run a real accessibility auditor on your device: VoiceOver order, contrast, labels, structure. Ages 15–18.
#0f766e Distributed-narrative cast
Meet the cast
AccessDojo is text-forward (R-OLDER-TEEN-DN-ADAPTED, ages 15–18) — no illustrated cast; the 'characters' are the four accessibility rules whose behaviour IS the lesson. NAME IT: every control needs an accessible name, because a screen reader reads the name, not the icon — an unlabelled button just says 'button'. CONTRAST IT: normal text needs 4.5:1 and large text 3:1, so the same faint grey can pass for a headline and fail for body text. STRUCTURE IT: headings are the document's outline, so levels must never skip (h1 → h2 → h3). QUIET THE DECORATION: a purely decorative image gets an empty alt so the reader skips it. Every audit is computed on-device by a real, deterministic WCAG checker — nothing is hand-waved, and nothing leaves the device. Illustrated portraits/chapters/audio are N/A for the older-teen band, not a follow-on.
Name It
Every button, link and field needs an accessible name — a screen reader announces the name, not the picture, so an icon-only control with no label is invisible (WCAG 1.1.1 / 4.1.2)
Contrast It
Normal text needs 4.5:1 and large text 3:1 against its background; a ratio that passes for a big headline can still fail for body text (WCAG 1.4.3)
Structure It
Headings are the outline screen-reader users navigate by, so levels must never skip — the step down from h1 is always h2 (WCAG 1.3.1 / 2.4.6)
Quiet It
A purely decorative image gets an EMPTY alt so the reader skips it — labelling decoration just reads pointless clutter to a listener
What's inside
Learning goal
A blind user opens your app. What does the screen reader say? AccessDojo hands you real screens as code — an icon button with no label, text too faint to read, headings that skip a level — and you predict the audit, then fix it until the problem count hits zero. Run a real accessibility auditor on your device: VoiceOver order, contrast, labels, structure. Ages 15–18.
Question kits
16 curriculum-aligned kits × 25 questions = 400 questions per app, mapped to recognized standards.
On-device AI mentor
FoundationModels-powered hints, feedback, and adaptive difficulty — all running locally.
How AccessDojo handles your kid's data
- ✅ All progress, settings, and AI-generated content stays on the device
- ✅ No analytics, no tracking, no third-party SDKs
- ✅ No ads, no in-app purchases — you pay once
- ✅ No personal information collected from children — in line with COPPA (updated by the 2026 FTC amendments)
- ✅ Parental controls + session limits + content filters built in
AccessDojo runs on ForgeKit — the open-source Swift Package Manager framework that powers every Spark & Anvil app. ForgeKit ensures consistent accessibility, COPPA compliance, and design language across the portfolio, so your kid's progress and preferences feel coherent across every app they touch.
Coming to the App Store
AccessDojo is in active development. Email us to hear when it ships — no marketing, no spam, just a one-shot launch announcement.
Email me at launch