💡 Accessibility-Native Voice Agent: Screen Reader, Motor, and Cognitive Accessibility Beyond WCAG AA

[github-actions[bot]]

Summary

Design TalkTerm from day one as an accessibility-native voice agent — with screen reader integration, motor disability support (full voice-only operation without any clicks), cognitive accessibility (simplified language modes, fewer options per screen, longer timeouts), and hearing impairment accommodations (rich visual feedback replacing audio cues). Go beyond WCAG AA compliance to make TalkTerm genuinely usable for disabled users.

Market Signal

GitHub Copilot CLI shipped accessibility-by-default in June 2026 — screen reader support on by default, colorblind modes, and high-contrast themes. No voice-first AI agent tool specifically targets disabled users as a first-class audience. The EU Accessibility Act enforcement began June 2025, making accessibility a legal compliance concern for desktop software distributed in the EU. Gartner projects 40% of enterprise applications will integrate AI agents by end of 2026 — enterprise accessibility requirements will follow.

User Signal

TalkTerm's PRD includes WCAG AA compliance (UX-DR16) as a minimum threshold — contrast ratios, 32x32px click targets, keyboard navigation, focus states. But the product's voice-first, non-technical-user focus naturally aligns with accessibility needs in ways the current spec doesn't exploit. Voice-only operation serves both non-technical users and motor-impaired users. The co-equal text input (FR8/NFR10) already mandates voice alternatives. The CaptionBar (UX-DR5) provides hearing-impaired alternatives. The accessibility opportunity is already architecturally present — it just needs to be elevated from compliance checkbox to design philosophy.

Technical Opportunity

The three-zone layout (UX-DR1) maps naturally to ARIA landmark regions (nav, main, complementary). ActionCards (UX-DR2) already specify role="option" and aria-label. The CaptionBar (UX-DR5) provides real-time text of avatar speech for hearing-impaired users. The STT/TTS abstraction layer can route to accessibility-optimized providers. Adding a cognitive accessibility mode (simpler agent language via system prompt, max 3 options per decision, extended timeouts) requires no architecture changes — it's a preference in electron-store that modifies prompt templates and UI constraints.

Assessment

Dimension	Score	Rationale
Feasibility	high	Most accessibility features build on existing architecture (ARIA roles, captions, voice input). Cognitive mode is a prompt + UI constraint toggle.
Impact	high	Underserved market segment with zero competition in voice-first AI agents. Potential differentiator for enterprise adoption. EU Accessibility Act compliance.
Urgency	high	Accessibility must be designed in from day one, not retrofitted. Should inform Epic 3 (avatar/voice) and Epic 5 (overlays) implementation.

Adversarial Review

Strongest objection: Voice recognition fails for users with speech disabilities (dysarthria, stuttering, heavy accents), making a 'voice-first accessible agent' potentially exclusionary for the very users it claims to serve.

Rebuttal: The co-equal text input (FR8) is the primary mitigation — every interaction works via text and keyboard. The accessibility proposal explicitly avoids voice-only: it adds motor accessibility (voice-only mode for users who CAN speak but can't click), screen reader support (for users who can't see), cognitive mode (for users who need simpler interactions), AND the existing text path (for users who can't speak). The point is multiple accessibility paths that cover different disabilities, not forcing everyone through voice. No single input modality serves all disabilities — the strategy is multimodal inclusivity.

Suggested Next Step

Audit the existing UX-DR specifications (UX-DR1 through UX-DR18) for accessibility gaps beyond WCAG AA. Define 4 accessibility personas (motor-impaired, visually impaired, hearing-impaired, cognitive/learning disability) and map each to specific design requirements. Integrate accessibility requirements into Epic 3 (Story 3.1-3.6) and Epic 5 (Story 5.1-5.4) acceptance criteria before implementation begins.