Accessibility as Architecture
Why accessibility must shift from checklists to adaptive, modality‑first systems where all learners thrive.
Opening
Many years ago at an accessibility bootcamp, I sat in a room listening to people from across the ecosystem: Department of Education officials, parents, learners themselves, and product managers from edtech companies. No engineers (at least not on the panel).
At that point I had already spent years building accessible learning systems and tools. I knew the standards and the checklists. I could quote the rules about contrast ratios, keyboard navigation, and screen readers. But in my mind, accessibility was still mostly a technical matter: follow the checklist, and you were done.
Then I heard the stories. A parent rewriting entire chapters at home so her son could keep up. A blind parent explaining she couldn't even check her children's school lunch menu without help. A university admitting it would take months to patch software so a blind student could use it, long after the semester would be over.
On paper those systems were "accessible." In practice they were broken.
It wasn't a deterministic realization so much as a revealing one—an eye-opener that built empathy not just for learners but also for their parents, who are tied inseparably to the learner's journey. That moment made it clear that accessibility isn't about compliance; it's about whether people can actually participate.
Why compliance feels like enough
Most companies stop at compliance. Partly because it's clear: there's a list, you check the boxes, you pass. And partly because it's cheaper: the market for accessibility-first products looks small. Only the giants with massive budgets go further. Everyone else settles for "good enough."
The result is a strange split. On paper, products pass. In reality, learners struggle. The gap between compliance and usability is filled by invisible labor with parents, tutors, and helpers propping up broken systems.
Accessibility is still treated as a separate track, an accommodation for a minority, something added after the fact rather than designed in from the start.
The shift we need
Accessibility has followed a predictable path. It began with compliance, where the goal was to meet the legal minimum. It then evolved toward a user-centric approach that brought real learners into testing and design, creating better but still limited results.
Now we're entering the adaptive stage, made possible by AI. Automation and intelligence allow us to build and maintain multiple modalities at scale. This turns accessibility from an afterthought into the foundation itself. Learners with disabilities are not a separate audience. They are part of the whole.
Modality-first doesn't mean building every experience in every mode from day one. It means architecting products so content and interaction can express themselves in whichever mode a learner chooses—visual, auditory, tactile, or textual. Choice isn't an accommodation; it's the core design principle.
This is not about enhancing accessibility. It is about reframing the product itself around choice for every learner.
Not about automated compliance
It's easy to assume that any discussion of AI and accessibility is about automated compliance — using AI to scan code and "make it WCAG‑compliant." That's valuable, and it's happening today. But that's not what this essay is about. My focus is deeper: reframing how we build products in the first place. Accessibility isn't an overlay or an audit outcome. It's the architecture itself, designed around choice for every learner. AI's role isn't just to pass the test faster — it's to make modality‑first systems viable at scale.
Why multi‑modality matters
Consider a piece of content: a 3D model of the human heart. For sighted students, it is powerful. For blind students, it collapses. The compliant fix is alt text: "This is a heart." Technically correct, practically useless.
The adaptive approach is multi‑modality. The 3D model remains for those who can see. A narrated, interactive voice version is generated for those who cannot. It is the same content, expressed in different ways. Both learners walk away with the same understanding.
For years the barrier was cost. Building multiple modalities for a small segment never made business sense. AI changes the math. Automated narration, dynamic simplification, and real‑time adaptation can now be created quickly and at scale.
Once you see it, you realize multi‑modality is not only for accessibility. It is for everyone: visual learners, auditory learners, language learners, and learners with limited time or attention. Accessibility dissolves into usability.
The deeper point
Accessibility has never been about a small group. It is the edge case that exposes the system. Build for it and you end up with something stronger: choice for everyone.
This is hard work. It requires a modality‑first mindset instead of add‑ons. But once you see the system, you cannot unsee it.
Closing
The future of accessibility is not about disability. It is about choice.
When every learner can choose their modality, accessibility stops being an afterthought. It stops being a checklist. It becomes part of the architecture of how we design.
The real question is not "Does it comply?"
The question is "Can learners thrive?"
As product design moves toward modality-first architecture,
accessibility checklists will give way to frameworks that measure how seamlessly every learner
can choose their mode of understanding.
Accessibility won't need to be proven; it will simply be felt.
From Standards to Systems
The shift isn't about more rules—it's about moving from rules → outcomes → systems.
This essay isn't an argument against standards. WCAG and similar frameworks gave the industry its first shared language for accessibility. Without them, we wouldn't even know what "inclusive" means in code. The problem isn't that the checklists exist — it's that we've mistaken them for the architecture itself.
Measuring outcomes is hard. It's far easier to audit contrast ratios than to evaluate whether learners can truly perceive, operate, and understand content across modes. Even the most forward-leaning guidelines today are still wrestling with that shift — from static, testable rules to evidence-based user outcomes.
Implementation will be messy. Building modality-first products means rethinking design systems, content pipelines, and component semantics so every element can express itself in multiple ways. It's an engineering challenge as much as a philosophical one — but it's solvable. The hardest part won't be technology; it will be unlearning our habit of treating accessibility as a feature instead of as structure.
Why Now · Cost Curve
For years, creating multiple modalities was prohibitively expensive. Producing audio descriptions, tactile graphics, and alternate text formats required manual scripting, studio time, and specialized expertise. Now, AI-powered tools can generate these adaptations automatically, making modality-first architecture economically viable for the first time.
How to estimate:
- List content types (readings, lectures, assignments, assessments) and count assets per course.
- Estimate current per-asset adaptation cost (script + voice + QA) vs AI-assisted (TTS + auto-caption + review).
- Apply reuse factor across courses and languages; model best-/base-/worst-case review time.
- Multiply by number of courses and refresh cadence to get annualized cost.
Then (manual): scripting, studio voiceover, and QA per asset ≈ $8k–$15k.
Now (AI-assisted): TTS narration, auto-captioning, language simplification, and human review ≈ $400–$1.2k.
At 250 assets: $2–3.7M → $100–300k. Savings depend on review depth and reuse across courses.
Real Use Cases · Candidate Problems
Course access delay
Blind students often wait weeks for alt-text patches. In a modality-first product, narration and interactive voice are generated from the same semantic core, so day-one parity is the default.
Interactive content collapse
3D models collapse for non-visual learners. Pair them with narrated exploration or tactile/line-art outputs driven from the same model to preserve the learning outcome.
Invisible parent labor
Parents retype or rewrite materials to keep kids in sync. Alternatives are generated automatically; parents support learning, not production.
Assessment friction
One item bank, many inputs: typed, spoken, switch-based, or gesture—identical scoring and feedback so performance reflects knowledge, not input method.