Responsible AI for Accessible Communication
AI can make accessibility dramatically better. It can describe a photo for someone using a screen reader, turn a GIF into words, or give a voice to someone who can't speak.
It can also make things worse if it's used carelessly. When users rely on AI to understand what's happening, an inaccurate description or an unpredictable behavior isn't just annoying — it breaks trust and can exclude people.
That tension is why I've come to treat responsible AI as a core part of accessible design, not an add-on.
When AI Mediates Understanding, Mistakes Cost More
In most product features, an AI hallucination is a glitch. In accessibility, it's a misrepresentation of reality for someone who has no other way to check.
A few patterns I've seen matter a lot:
Meaning distortion. When AI rephrases or describes images, small errors can change intent. "A person holding a sign" without the text on the sign is incomplete. A creative caption that adds context that wasn't there is misleading.
Inconsistency. If the same photo gets three different descriptions across devices or sessions, users can't build a mental model of how the system works. For screen reader users, predictability is not a nice-to-have — it's how you navigate.
Trust erosion. Messaging platforms are essential infrastructure for school, work, healthcare, and emergency alerts. Once an accessibility feature feels unreliable or opaque, users disengage. They revert to less efficient workarounds. Regaining that trust is hard.
I wrote about this in more detail in Accessibility-by-Design in Messaging Platforms — AI works best when it's constrained by core system guarantees like timing, message consistency, and state coherence, not when it's bolted on as an independent layer.
Why Treating Alt Text as Infrastructure Matters
A common failure mode is treating accessibility as a UI patch.
For example, descriptive text for images in chats:
If you add it only at the interface layer, you get inconsistent behavior — descriptions appear in one client but not another, or arrive too late for assistive technology to use. If you treat it as infrastructure — standardized content representation, predictable message flow, clear timing so descriptions arrive when assistive tech expects them — it works uniformly across platforms.
The same applies to animated images. They are fun for many users but invisible to others without a consistent pipeline for descriptive metadata that lives in core routing rather than at the edge. That architectural choice determines whether behavior is the same across mobile and desktop.
At scale, accessibility can't depend on manual captions alone. But automation has to be predictable, testable, and overrideable. Human-written text should win when it's available, and the system should be clear about when AI was used.
On-Device Processing Changes the Privacy Equation
Accessibility features often process sensitive data — private messages, health-related communication, family photos. Sending that to a server for description raises real privacy questions.
This is where on-device and edge processing became important in my work:
Privacy. Text never leaves the device.
Latency. Immediate feedback matters for screen readers — a 500ms delay disrupts navigation flow.
Availability. Core features still work offline or in low-connectivity environments. That's critical for emergency communication.
I explored this trade-off in On-Device AI for Accessibility and in the deeper dive on On-Device Speech Synthesis.
Two Open-Source Case Studies
Private by design isn't just a theory. Two projects I've contributed to show what it looks like in practice:
RHVoice. A lightweight, multilingual TTS engine. Porting it to iOS and macOS meant solving sandboxing, ARC memory management, and AVAudioEngine integration while keeping footprint under 50MB per language. Because it's offline, community colleges and libraries can deploy it without licensing or network requirements.
Piper. A neural TTS system built around ONNX Runtime. Extending it to Apple platforms required operator fusion, ring buffers for Core Audio callback, and replacing the heavy eSpeak-NG phonemizer with a small CNN-based G2P. The result is expressive voices that run entirely on device.
Both are documented in Bringing Offline Neural TTS to iOS and macOS. The point isn't that on-device is always better — it's that for accessibility-critical communication, keeping synthesis local removes a whole class of privacy and availability risks.
Principles I Use for Responsible AI in Accessibility
- Be transparent. Users should be able to tell when content was AI-generated, and what data source it used.
- Preserve predictability. Same input should lead to same outcome across devices. Version your models and test with VoiceOver, Spoken Content, and other assistive tech.
- Keep humans in control. AI should assist, not decide. Let people edit or override generated descriptions.
- Minimize data exposure. Prefer on-device inference for sensitive communication. Be explicit about where processing happens.
- Build for streaming. In speech systems, incremental low-latency output matters more than full-sentence quality. A screen reader user needs the first word now, not the perfect prosody later.
- Measure trust, not just accuracy. Beyond MOS or BLEU scores, track whether users keep the feature enabled, whether they report hallucinations, and whether behavior is consistent over time.
These aren't abstract ethics checklist items. They are engineering constraints that lead to different architecture decisions — from how you store voice models to how you schedule inference and how you expose state to accessibility APIs.
Closing
AI is now part of how we build accessible communication. The opportunity is to make it an extension of accessibility-by-design values rather than a shortcut around them.
When AI is predictable, privacy-preserving, and human-supervised, it expands who can participate fully in education, work, and daily life. When it's opaque or unreliable, it creates new barriers for the very people it was meant to help.
That focus on trust and on-device design is why I work on open tools like RHVoice and Piper — building accessible speech that runs locally and respects user autonomy.
If you work on speech or accessibility for Apple platforms, I'd love to compare notes: code is on GitHub, and setup details are in Piper Apple Support.